I did ~this in the 200X’s for a C# todo list, not nearly as polished but it was still So Much Work. Filed under things that should just work already.
Pretext: TypeScript library for multiline text measurement and layout
51–60 of 76 posts
Re: Pretext: TypeScript library for multiline text measurement and layout
#52This thing is very impressive. The problem it solves is efficiently calculating the height of some wrapped text on a web page, without actually rendering that text to the page first (very expensive). It does that by pre-calculating the width/height of individual segments - think words - and caching those. Then it implements the full algorithm for how browsers construct text strings by line-wrapping those segments usi…
> It does that by pre-calculating the width/height of individual segments - think words - and caching those.
From the description, it doesn’t calculate it, but instead renders the segments in canvas and measures them. That’s still relatively slow compared to what native rendered-text-width APIs will do, and you have to hope that the browser’s rendering will use the identical logic in non-canvas contexts.
Re: Pretext: TypeScript library for multiline text measurement and layout
#53Earlier quoted context omitted.
> This thing is very impressive. Agreed! Text layout engines are stupidly hard. You start out thinking "It's a hard task, but I can do it" and then 3 months later you find yourself in a corner screaming "Why, Chinese? Why do you need to rotate your punctuation differently when you render in columns??" This effort feeds back to the DOM, making it far more useful than my efforts which are confined to rendering multilin…
Why do you bring up Chinese cornes if the basic Latin text in the Pretext demo is deficient? (by the way, in your cool demo the wheel template can have some letter parts like the top of L or d extend beyond the wheel)
> the wheel template can have some letter parts like the top of L or d extend beyond the wheel
Yeah - I use the template (in that case, a circle) to calculate line lengths, then I run 2d text along the 1d lines. Even if I tried to keep all of the glyphs inside the wheel I'd fail - because some fonts lie about how tall they are. Fonts are, basically, criminals.
Re: Pretext: TypeScript library for multiline text measurement and layout
#54I get the feeling this is an AI hallucination. It uses the canvas to render the text to be measured, which doesn't bypass the browser layouting. The only potential performance to be gained here is rendering straight to a canvas instead of building a dom node, but it's not clear that it's actually faster. I can't imagine the cost of a single
is that large, and I'm not certain that it's slower than whatever steps the canvas API uses to turn text into pixels.
Re: Pretext: TypeScript library for multiline text measurement and layout
#55This thing is very impressive. The problem it solves is efficiently calculating the height of some wrapped text on a web page, without actually rendering that text to the page first (very expensive). It does that by pre-calculating the width/height of individual segments - think words - and caching those. Then it implements the full algorithm for how browsers construct text strings by line-wrapping those segments usi…
I mentioned this elsewhere, but it's not actually doing any of what you describe. It's rendering the text to a canvas and then measuring that. I don't see any benchmarks that indicate it's faster than just sticking it in a
tag, and not any clear indication that it would be. It's certainly not implementing the full algorithm for text rendering in a browser.
It certainly seems to provide an API for analysing text layouts, but all of the computation still goes through the browser's native layout system.
Re: Pretext: TypeScript library for multiline text measurement and layout
#56This thing is very impressive. The problem it solves is efficiently calculating the height of some wrapped text on a web page, without actually rendering that text to the page first (very expensive). It does that by pre-calculating the width/height of individual segments - think words - and caching those. Then it implements the full algorithm for how browsers construct text strings by line-wrapping those segments usi…
> It does that by pre-calculating the width/height of individual segments - think words - and caching those. From the description, it doesn’t calculate it, but instead renders the segments in canvas and measures them. That’s still relatively slow compared to what native rendered-text-width APIs will do, and you have to hope that the browser’s rendering will use the identical logic in non-canvas contexts.
I recently battled this and reverted to using DOM measurements. In my case the measurement would be off by around a pixel, which caused layout issues if I tried rendering the text in DOM. This was only happening on some Linux and Android setups
Re: Pretext: TypeScript library for multiline text measurement and layout
#57Earlier quoted context omitted.
i wrote something similar for this purpose, but much simpler and in 2kb, without AI, about a year ago. uWrap.js: https://news.ycombinator.com/item?id=43583478 . it did not reach 11k stars overnight, tho :D for ASCII text, mine finishes in 80ms, while pretext takes 2200ms. i haven't yet checked pretext for accuracy (how closely it matches the browser), but will test tonight - i expect it will do well. let's see how cl…
uWrap demo has text extending beyond text boxes all other the place on Safari, is that the price of simplicity?
i don't have a mac to test this with currently, so hopefully it's not the price but a matter of adding a Safari-specific adjustement :)
internally it still uses the Canvas measureText() API, so there's nothing fundamentally that should differ unless Safari has broken measureText, which tbh, would not be out of character for that browser.
Re: Pretext: TypeScript library for multiline text measurement and layout
#58Earlier quoted context omitted.
uWrap demo has text extending beyond text boxes all other the place on Safari, is that the price of simplicity?
i don't have a mac to test this with currently, so hopefully it's not the price but a matter of adding a Safari-specific adjustement :) internally it still uses the Canvas measureText() API, so there's nothing fundamentally that should differ unless Safari has broken measureText, which tbh, would not be out of character for that browser.
Chrome is no different, for example, "RobertDowneyjr" is out of the box, so does "enthusiastic" in a couple of places.
Re: Pretext: TypeScript library for multiline text measurement and layout
#59Earlier quoted context omitted.
correct, it was meant for estimating row height for virtualizing a 100k row table with a latin-ish LTR charset (no emoji handling, etc). its scope is much narrower. still, the difference in perf is significant, which i have found to be true in general of AI-generated geenfield code.
I've worked with text and in my experience all of these things (soft hyphens, emoji correction, non-latin languages, etc) are not exceptions you can easily incorporate later, but rather the rules that end up foundational parts of the codebase. That is to say, I wouldn't be so quick to call a library that only handles latin characters comparable to one that handles all this breath of things, and I also wouldn't be so…
no disagreement. i never claimed uWrap did anything more than it does. it was not meant for typography/text-layout but for line count estimation. it never needed to be perfect, and i did not claim equivalence to pretext. however, for the use case of virtualization of data tables -- a use case pretext is also targeted at -- and in the common case of latin alphabets, right now pretext is significantly slower. i hope that it can become faster despite its much more thorough support for "rest of the owl".
Re: Pretext: TypeScript library for multiline text measurement and layout
#60Earlier quoted context omitted.
i don't have a mac to test this with currently, so hopefully it's not the price but a matter of adding a Safari-specific adjustement :) internally it still uses the Canvas measureText() API, so there's nothing fundamentally that should differ unless Safari has broken measureText, which tbh, would not be out of character for that browser.
Chrome is no different, for example, "RobertDowneyjr" is out of the box, so does "enthusiastic" in a couple of places.
ack, see my reply to sibling comment: https://news.ycombinator.com/item?id=47572206