Improve readability about lkmpg HOT 15 CLOSED

@fennecJ Hi sorry, got busy with unrelated development. I took a look at the cfg and also the result of the generation. The website scores quite poorly on performance, which is unusual for plain text sites, I am unfamiliar with make4ht, but on mobile especially my phone seems to struggle to load the page. Making the website dark would be a pain due to code syntax highlight, but making the website sepia and ofc make the changes to sizing like I proposed should still be a big improvement, so i will get on pull requesting that so that you can take a look and judge it.

from lkmpg.

Hi @Kellegram , thanks for informing us about themes and SEO issue.
Currently the css file is generated automatically via make4ht with a configuration
file html.cfg , and you can check css file in branch gh-pages.

See #20, #43, #45 for css related PR.

from lkmpg.

I see, I will take a look at those.

from lkmpg.

After #96, the text with hyperlinks would look slightly larger than plain text, at least in Chrome web browser. Is there any effective tweak to make all text more consistent?

from lkmpg.

After #96, the text with hyperlinks would look slightly larger than plain text, at least in Chrome web browser. Is there any effective tweak to make all text more consistent?

They are set to have the same scaling, which means there is manual size set for them elsewhere. All i can really understand is the html.cfg, anything else done by make4ht I don't really get. I set both p and a to 1.2em which means 120% of parent. So the parent for a has bigger size set in pixels than p and that does not happen in the html.cfg. I will try and figure out where this happens, unless you know. Ideally the size per device size should be 100% consistent when it comes to pixels and only modified using em. It's common for mobile to have base size of 16px, 18-20 for laptops/tablets and 22 for desktop, roughly. For that one can use media queries and the entire site will adapt accordingly thanks to using responsive units.

One workaround would be to set a smaller em value for a in html.cfg, but that is a workaround, not a solution.

from lkmpg.

I think using rem instead of em might work here, because the LaTeX conversion seems to apply css to every single paragraph separately, so using the parent element causes inconsistencies. Using rem instead will use the root element and that seems to make it consistent and it computes the same size value. Will investigate a bit more.

Edit: Just verified that using rem does indeed work and make the p and a consistent. Will PR for now so the document looks clean.
Edit: See #100

from lkmpg.

Going back to Manrope, there is two ways to add it. We can ofc access it remotely or we can serve it locally. I think the latter is ideal. While the font would not be grabbed from a CDN, using remote fonts comes with other potential problems, especially since I think Manrope is hosted on google fonts and people might block that. If you are interested in using Manrope let me know, I would just need to figure out where the font file should be located. Based on what I can see it would be simply located at the root in the gh-pages branch correct?

from lkmpg.

I think it would be good to use Manrope for our page.
To put the font file in the root of gh-pages branch, you have to configure the html target in Makefile.

from lkmpg.

Alright, I will try to do it then, do make sure I do it right though, as I am kind of guessing how this is supposed to be done based on current contents of the makefile.

from lkmpg.

As far as I understand, the OFL license does not require crediting, or rather including full license text, although since we are adding the font locally instead of remotely, the font file is distributed, so I am unsure how to interpret the OFL license in this case. Worst case scenario, the license text has to be included somewhere, OFL does not require attribution.

Do be sure I did it correctly, this is still very unfamiliar to me, should the @ symbol be escaped? It might be better to set manrope in html/body instead of p/a as I think the pre tag forces monospace font to be used, so I may have been wrong in assuming that manrope would have overwritten the font in codeblocks, although that would be easy to change if that's the case, I will test that soon, need to leave for the moment.

from lkmpg.

Do be sure I did it correctly, this is still very unfamiliar to me, should the @ symbol be escaped?
It's ok to use @ in the configuration file.

By the way, I just noticed that explorer cannot load the font file correctly due to security reason (it prevents you from reading parent directory, so you cannot access the file linked to parent directory's file)
Perhaps we need to copy the font file into /html.

As for the license issue, let me consult @jserv

from lkmpg.

Huh, I thought I made it go to html/ but maybe I should have put those lines in the html: section instead of creating font: in the makefile, that's probably what's wrong, or maybe the symlink makes no sense and it should just be moved there?

from lkmpg.

I have tested if explore can read the soft linked font file well, and just as I mentioned before.
It seems like explore cannot read parent directory without permission.
So I think even if you put those after html: target, it might still fail to load the font file.

from lkmpg.

I see. I guess I will modify it to copy it there then.

from lkmpg.

Ok, now that new font and some styling is added, it exposed a problem that I guess wasn't visible before since the styling was basically almost browser default.

This screenshot shows the problem: https://i.imgur.com/DfCYBhA.png
I imagine this is a result of the latex to html conversion, something must be wrong with the configuration, but that I don't know how to help with, styling html would technically do something but it would be bad practice and would just cause a different problem, so probably a separate issue to file. I think this issue can now be closed, this is all I wanted to discuss readability wise, I think I will open an issue about missing meta tags, as they are significantly worsening SEO/PageRank score.

from lkmpg.