5 ms·
> As you can easily tell, line breaks made at the beginning of the chapter affect the potential line breaks you can do later. Sometimes it is worth it to make a
by seanwilson 4y ago
> As you can easily tell, line breaks made at the beginning of the chapter affect the potential line breaks you can do later. Sometimes it is worth it to make a locally non-optimal choice at the beginning to get a better line break possibility much later. Evaluating a global metric like this can be potentially slow, which is why interactive programs like LibreOffice do not use this method.
Is there not a fast "good enough" algorithm for justifying text vs a slow optimal one? Is it really infeasible for HTML to have justified text that looks something like LaTeX? It's sad that justified text still looks bad on the web with no signs of it getting better even with all the computing power we have now.
- tannhaeuser 4y agoAccording to previous discussions [1], none that'd fit the constraints of text rendering in browsers AIU (eg dynamic programming approaches considered infeasible on the web, hyphenation not really a thing). But who knows, CSS is incredibly bloated already ... [1]: https://news.ycombinator.com/item?id=28537923 https://news.ycombinator.com/item?id=28537923
- chucky 4y agoI once discussed this with a coworker who had worked a lot on various things related to typesetting, and he claimed the main issue with doing good text justification for the web is the lack of good, free hyphenation dictionaries (or rules) for most languages. In order to do full paragraph justification in a way that makes sense and always looks good you need to be able to hyphenate words dynamically (and fairly aggressively). LaTeX does come with hyphenation libraries for some languages, but web browsers would need wider support. There's also the question of how to standardize this, because you would have to ship hyphenation dictionaries for every language, and you would need to standardize this across browsers so they render pages the same. LaTeX does ship with hyphenation libraries for a bunch of languages, but if you try to use it for any of the minor languages, you'll find the results are so-so and you need to manually hyphenate words to get decent results (this was my experience a decade ago at least). All of the above could be solved, but sadly I suspect it wouldn't be worth the cost for the players that would have to be involved in solving it.
- bombcar 4y agoThe biggest advantage LaTeX has is that the page width stays the same between various versions of your document, so you can improve it on the fly when you notice issues. The web tries to support every possible page width so some won't look great.
- thristian 4y agoFirefox does indeed come with hyphenation dictionaries for a bunch of languages, in order to support the CSS `hyphens` property: https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens If you look at the language support tables at the bottom of the page, though, other browsers don't support nearly as many languages.
- ksherlock 4y agoI set up my static site generator to pre-process text and insert soft hyphens (& shy ; ). That was based on Ruby Text::Hyphen which uses TeX hyphenation patterns.
- tomsmeding 4y ago> > [...] Evaluating a global metric like this can be potentially slow, which is why interactive programs like LibreOffice do not use this method. I suspect that another reason for a WYSIWYG office suite to not use such global optimisation, is to avoid unpredictable changes to layout in response to seemingly unrelated changes by the user. If you get full reflows with figures moving around and headings flipping between the previous and the next page while you're typing a sentence, users will probably quickly punch a hole in their monitor. In (La)TeX this is less of an issue because of the delayed compilation, I guess. Also *TeX users are probably more tolerant to that kind of mess.
- drfuchs 4y agoOn my 2015 Mac, using just a single core, TeX composes the entire 495-page TeXbook in under 0.2 seconds, or about 0.4 milliseconds per page. That includes reading the 1.3Mb input file, evaluating all macros and such, doing all line-breaking and page-breaking, and writing the entire 1.9Mb dvi file. So, I don't know where the "too slow" meme is coming from. Is there a browser that can open and scroll to the end of an HTML page that's 500 screen-fulls long in 0.2 seconds?
- delta_p_delta_x 4y ago> So, I don't know where the "too slow" meme is coming from Perhaps the parent commenter is executing `pdftex` on Windows. Like all Windows ports of UNIX/Linux-first software, LaTeX experiences the double whammy of the NT kernel being slow with small files + Windows Defender scanning. NTFS is not at fault, oddly enough: it works fast enough in Linux with the recent in-kernel NTFS3 driver. I use the same distribution (MiKTeX) on both Windows and Linux, and Linux is easily 10× as fast as Windows when compiling complex files (TikZ graphs and diagrams, `.bib` files, internal hyperlinks, etc).
- beej71 4y agoI'm building through Pandoc and LaTeX, and just the LaTeX part on my modern computer is orders of magnitude slower than your numbers, ~20 ms per page. Is that a normal difference between plain TeX and LaTeX? Or more to do with the output of Pandoc?
- svat 4y agoSee similar discussion from a couple of weeks ago where I too mentioned "about a millisecond a page": https://news.ycombinator.com/item?id=32204910 https://news.ycombinator.com/item?id=32204910 — yes some overhead comes from LaTeX, and even more from heavyweight macro packages that one may be using. Some people even end up with several orders of magnitude worse than your 20ms per page :/
- kragen 4y agoThe HTML standard mandates a shitty layout algorithm with respect to things like floats, but I don't think it actually mandates shitty line-breaking.