18 ms·

You aren't wrong; but I stand by my claim. For one, plenty of things are actually difficult optimization problems that people don't give any passing thought to

by taeric 2y ago

You aren't wrong; but I stand by my claim. For one, plenty of things are actually difficult optimization problems that people don't give any passing thought to. But, more importantly, the amount of cycles that would be needed to text-wrap most websites is effectively zero. Most websites are simply not typesetting the volumes of text that would be needed for this to be a concern. Happy to be shown I'm flat wrong on that. What sites are you envisioning this will take a lot of time for?

NoMoreNicksLeft 2y ago
Won't this end up in Apple iBooks or whatever it's called now? Most novels can be a megabyte or more of text, pretty much all of it needing to be wrapped.
- CharlesW 2y ago
  It seems more likely that Apple would've adapted this from the proven technology that they currently use for Apple Books and everything else, TextKit (which first appeared in OpenStep). https://developer.apple.com/videos/play/wwdc2021/10061/ https://developer.apple.com/videos/play/wwdc2021/10061/
  - addaon 2y ago
    > Apple Books and everything else Can't speak to Apple Books, but at least Pages.app (and iWork in general) use a separate text engine from TextKit, focused on higher fidelity at the cost of performance -- optical kerning, etc. (Terminal.app also does not use TextKit.)
  - alwillis 2y ago
    Doubtful. OpenStep used Display Postscript and was written in Objective-C; WebKit is written in C++. Rendering text on the web is a different animal all together.
    - NoMoreNicksLeft 2y ago
      I was under the impression that when we got new css in Safari, in the next software cycle those same features ended up in Books. It wouldn't make sense to give it a different rendering engine... but then I've never been able to find much in the way of which epub readers used which rendering engines anywhere.
- taeric 2y ago
  I mean, not wrong. But optimizing over a megabyte's worth of text is almost certainly not going to take a lot of time. Especially as there will be chapter stops. Such that we are down to, what 100k of text per chapter to layout? Again, I won't claim it is absolutely free. It is almost certainly negligible in terms of processing power involved with any of the things we are talking about.
binaryturtle 2y ago
With the current state of Websites and how much resources they waste any text wrapping is probably not an issue at all. :) I hardly can open any website w/o some anti-bot check burning my CPU to the ground for 1/2 minute or something (if it doesn't manage to entirely crash my Firefox in the process like cloudflare). I rather would wait for 0.2s text wrapping than that, that's for sure. :)
cobertos 2y ago
Any page with dynamic text. If the calculation takes a moderate amount of time, that will accumulate if the page layout reflows a lot.
- taeric 2y ago
  Only if the entire text has to be optimized as a whole? Which, most dynamic text sites do not have to do this. Most dynamic sites will be a series of individual "card" like things that could be justified internally, but are not justified with regard to anything else on the page.
contact9879 2y ago
Quick example would be https://standardebooks.org/ebooks/mark-twain/the-innocents-abroad/text/single-page https://standardebooks.org/ebooks/mark-twain/the-innocents-a... Try zooming in and out with text-wrap: pretty vs text-wrap: wrap
- taeric 2y ago
  I... uh, wouldn't consider a text dump of a full novel getting completely typeset as a good example to consider when talking about sites?
  - contact9879 2y ago
    sure, but html isn't only used in a browser context. I have a severely under-powered ereader that I use to read epubs (html). It already takes ten seconds to paginate on first open and font size changes. I can't imagine how long it would take to non-naively wrap lines
    - taeric 2y ago
      I don't know why you'd expect an ereader to do a full text optimization of a book, though? Pick the starting line and layout to the next screen's breaking point. If needed, consider if you left an orphan for the next page and try to adjust that into the current screen. Are there ereaders that have to typeset the entire text of what you are reading? What is the advantage of making the task harder?
      - tjader 2y ago
        KOReader typesets the whole book at once. It is needed in order to get page counts right, for example.
        taeric 2y ago
        Even if that is the case, it has to redo this how often? If the page counts are to be stable, I'm assuming so are page numbers? At which point we are back to this not being something I would expect to slow things down appreciably on the vast majority of actual uses. Still, I should acknowledge you provided an example. It surprises me.
pcwalton 2y ago
> But, more importantly, the amount of cycles that would be needed to text-wrap most websites is effectively zero. I've measured this, and no, it's not. What you're missing is the complexities of typesetting Unicode and OpenType, where GSUB/GPOS tables, bidi, ruby text, etc. combine to make typesetting quite complex and expensive. HarfBuzz is 290,000 lines of code for a reason. Typesetting Latin-only text in Times New Roman is quick, sure, but that doesn't cut it nowadays.
- taeric 2y ago
  Apologies, the additional cycles to do justified text is effectively zero compared to the rest of the stack for most sites. Clearly, it is work, so not actually zero. And, yes, proper text handling is huge. I would wager you can find scenarios where it is a large number. My question is if there are sites people use? Seriously taken, these would all be reasons not to do many of the things Unicode does. And yet here we are. That all said, if you have measurements, please share. Happy to be proven wrong.
  - rhdunn 2y ago
    Some complexities: - handling shy hyphens/hyphenation when splitting long words -- working out where to hyphenate so it is readable, then how that affects the available space takes time to compute to ensure that justified text doesn't result in large blocks of whitespace esp. for long words; - handing text effects like making the first letter large, or the first word(s) larger, like is done in various books; - reflow due to any changes resulting from text rendering/formatting (e.g. if applying kerning or hyphenation results in/does not result in text wrapping); - impact of things like kerning and digraphs (e.g. ffi) on text width -- including determining if a word can be split in the middle of one of these or not; - combining characters, emoji (with zero-width non-joiners), flag Unicode character pairs (including determining valid pairs to determine if/where to split on), etc.; - mixed direction text (left to right and right to left) handling and positioning; - the mentioned Ruby text (e.g. https://www.w3.org/International/articles/ruby/styling.en.html https://www.w3.org/International/articles/ruby/styling.en.ht...) -- dealing with both the main text wrapping and the above/below text wrapping, both of which could happen; - for Chinese/Japanese/Korean ensuring that characters within a word don't have extra space, as those languages don't use spacing to delimit words; - other things affecting line height such as sub/super script text (mathematical equations, chemical symbols, references, etc.).

by taeric 2y ago

NoMoreNicksLeft 2y ago

Won't this end up in Apple iBooks or whatever it's called now? Most novels can be a megabyte or more of text, pretty much all of it needing to be wrapped.

CharlesW 2y ago
It seems more likely that Apple would've adapted this from the proven technology that they currently use for Apple Books and everything else, TextKit (which first appeared in OpenStep). https://developer.apple.com/videos/play/wwdc2021/10061/ https://developer.apple.com/videos/play/wwdc2021/10061/
- addaon 2y ago
  > Apple Books and everything else Can't speak to Apple Books, but at least Pages.app (and iWork in general) use a separate text engine from TextKit, focused on higher fidelity at the cost of performance -- optical kerning, etc. (Terminal.app also does not use TextKit.)
- alwillis 2y ago
  Doubtful. OpenStep used Display Postscript and was written in Objective-C; WebKit is written in C++. Rendering text on the web is a different animal all together.
  - NoMoreNicksLeft 2y ago
    I was under the impression that when we got new css in Safari, in the next software cycle those same features ended up in Books. It wouldn't make sense to give it a different rendering engine... but then I've never been able to find much in the way of which epub readers used which rendering engines anywhere.
taeric 2y ago
I mean, not wrong. But optimizing over a megabyte's worth of text is almost certainly not going to take a lot of time. Especially as there will be chapter stops. Such that we are down to, what 100k of text per chapter to layout? Again, I won't claim it is absolutely free. It is almost certainly negligible in terms of processing power involved with any of the things we are talking about.

binaryturtle 2y ago

With the current state of Websites and how much resources they waste any text wrapping is probably not an issue at all. :) I hardly can open any website w/o some anti-bot check burning my CPU to the ground for 1/2 minute or something (if it doesn't manage to entirely crash my Firefox in the process like cloudflare). I rather would wait for 0.2s text wrapping than that, that's for sure. :)

cobertos 2y ago

Any page with dynamic text. If the calculation takes a moderate amount of time, that will accumulate if the page layout reflows a lot.

taeric 2y ago
Only if the entire text has to be optimized as a whole? Which, most dynamic text sites do not have to do this. Most dynamic sites will be a series of individual "card" like things that could be justified internally, but are not justified with regard to anything else on the page.

contact9879 2y ago

Quick example would be https://standardebooks.org/ebooks/mark-twain/the-innocents-abroad/text/single-page https://standardebooks.org/ebooks/mark-twain/the-innocents-a... Try zooming in and out with text-wrap: pretty vs text-wrap: wrap

taeric 2y ago
I... uh, wouldn't consider a text dump of a full novel getting completely typeset as a good example to consider when talking about sites?
- contact9879 2y ago
  sure, but html isn't only used in a browser context. I have a severely under-powered ereader that I use to read epubs (html). It already takes ten seconds to paginate on first open and font size changes. I can't imagine how long it would take to non-naively wrap lines
  - taeric 2y ago
    I don't know why you'd expect an ereader to do a full text optimization of a book, though? Pick the starting line and layout to the next screen's breaking point. If needed, consider if you left an orphan for the next page and try to adjust that into the current screen. Are there ereaders that have to typeset the entire text of what you are reading? What is the advantage of making the task harder?
    - tjader 2y ago
      KOReader typesets the whole book at once. It is needed in order to get page counts right, for example.
      - taeric 2y ago
        Even if that is the case, it has to redo this how often? If the page counts are to be stable, I'm assuming so are page numbers? At which point we are back to this not being something I would expect to slow things down appreciably on the vast majority of actual uses. Still, I should acknowledge you provided an example. It surprises me.

pcwalton 2y ago

> But, more importantly, the amount of cycles that would be needed to text-wrap most websites is effectively zero. I've measured this, and no, it's not. What you're missing is the complexities of typesetting Unicode and OpenType, where GSUB/GPOS tables, bidi, ruby text, etc. combine to make typesetting quite complex and expensive. HarfBuzz is 290,000 lines of code for a reason. Typesetting Latin-only text in Times New Roman is quick, sure, but that doesn't cut it nowadays.

taeric 2y ago
Apologies, the additional cycles to do justified text is effectively zero compared to the rest of the stack for most sites. Clearly, it is work, so not actually zero. And, yes, proper text handling is huge. I would wager you can find scenarios where it is a large number. My question is if there are sites people use? Seriously taken, these would all be reasons not to do many of the things Unicode does. And yet here we are. That all said, if you have measurements, please share. Happy to be proven wrong.
- rhdunn 2y ago
  Some complexities: - handling shy hyphens/hyphenation when splitting long words -- working out where to hyphenate so it is readable, then how that affects the available space takes time to compute to ensure that justified text doesn't result in large blocks of whitespace esp. for long words; - handing text effects like making the first letter large, or the first word(s) larger, like is done in various books; - reflow due to any changes resulting from text rendering/formatting (e.g. if applying kerning or hyphenation results in/does not result in text wrapping); - impact of things like kerning and digraphs (e.g. ffi) on text width -- including determining if a word can be split in the middle of one of these or not; - combining characters, emoji (with zero-width non-joiners), flag Unicode character pairs (including determining valid pairs to determine if/where to split on), etc.; - mixed direction text (left to right and right to left) handling and positioning; - the mentioned Ruby text (e.g. https://www.w3.org/International/articles/ruby/styling.en.html https://www.w3.org/International/articles/ruby/styling.en.ht...) -- dealing with both the main text wrapping and the above/below text wrapping, both of which could happen; - for Chinese/Japanese/Korean ensuring that characters within a word don't have extra space, as those languages don't use spacing to delimit words; - other things affecting line height such as sub/super script text (mathematical equations, chemical symbols, references, etc.).