Hacker News Reader

Comment by vextea | Hacker News Reader

So unfortunate that justified text in browsers looks awful compared to documents generated with LaTeX (usually)....

I had a crack at a solution to this problem recently. It's pretty basic in terms of what it can do and not the most performant.

Code: https://github.com/tdjsnelling/microtype Demo: https://tdjsnelling.github.io/microtype/test/from-cdn/

Even better, there is the new CSS `hyphens: auto;`. Browser & language support is not yet 100% though.

https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens

Try to make a LaTeX document that automatically reflows based on screen size and you’ll see why it’s difficult.

That is not what a latex document is for.

It's like talking about reflowing a physical page.

Instead, you change the document page size and render multiple versions and switch it out based on zoom level.

That’s the point. HTML has to support arbitrary screen sizes whereas LaTeX doesn’t, so the layout algorithms have to be more accomodating.

But the width of a PDF is still arbitrary isn't it? Can you just, recalculate for bigger widths?

Not really. It's fixed at "compile time". Eg "A4" or "Letter". I guess it "changes" according to zoom level, but that's just enlarging or shrinking - no reflow required.

You could apply the LaTeX algorithm to each rendering. The rendering might jump and it would be a change from before but it can be done.

How long does a fast latex renderer take on a large document? It's been a few years since I worked with latex, but it's on the order of multiple seconds, right?

For a book, it can take minutes. For a short document, seconds.

Texpresso looks promising though, but I haven’t tried it yet.

The Knuth-Plass line-breaking algorithm is applied per paragraph; performance is typically not going to be an issue at all.

If you apply it to all paragraphs, yes, you will get pathological performance on some extreme cases—the algorithm is quadratic, if I recall correctly. But there’s nothing preventing you from trying to apply it in general, and giving up if the input is too long. So your five or ten line paragraphs get KP, and longer paragraphs get greedy.

There is absolutely nothing stopping browsers from applying Knuth-Plass. In fact, Firefox has had a bug about implementing it for 14 years <https://bugzilla.mozilla.org/show_bug.cgi?id=630181>, and there’s some useful discussion of things there. And CSS itself is finally actually going ahead with `text-wrap: pretty`, which encourages such things. Long ago, IE apparently even had it via `text-justify: newspaper` <https://news.ycombinator.com/item?id=5189258>.

You can’t ask the user of a website to fix overfull hboxes for you after they resize their browser window.

A good example of this is Bertrand Russell's _Introduction to Mathematical Philosophy_:

https://courses.umass.edu/klement/imp/

which is available in a number of sizes _and_ has the LaTeX source available showing how the various sizes are arrived at.

It’s still just a few different sizes. A HTML website has to support every possible width.

The LaTeX source may be easily edited to impart any size/proportion desired --- not quite as straight-forward as re-sizing a browser window, but the same ultimate effect.

The HTML version is quite nice. Do you know how they did the LaTeX to html conversion?

No idea. Ask the folks who manage that page?

For want of a "real" H&J algorithm, and having problematic lines identified as "overfull boxes" which need to be fixed.

All the print books on my bookshelf use fully justified text. In contrast, my preference for ebooks are to render them as left-justified. So I think I intuitively arrived at a practice that matches your conclusion about justified text in browsers.

Reply on news.ycombinator.com