Live data from Hacker News

Pretext: TypeScript library for multiline text measurement and layout

github.com

61–70 of 76 posts

Re: Pretext: TypeScript library for multiline text measurement and layout

#61

I 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 c…

What you're missing is that each segment (typically a word) only needs to be measured once, in the setup phase. The canvas gets thrown away after that, and subsequent layout passes all reuse the cached measurements.

If you only perform layout once, it doesn't save any work. If you need to reflow many times, it saves a lot.

Re: Pretext: TypeScript library for multiline text measurement and layout

#62

Has someone ever found a good solution for long / infinite lists / grids virtualization not breaking browsers native text search? Maybe for this we need a new web "Search" API instead of JS. Not sure it can be done otherwise without browser's help.

[flagged]

Re: Pretext: TypeScript library for multiline text measurement and layout

#63
post #40

Love this. I especially liked shape based reflow example. This is something I've been thinking for ages and would love to add to Ensō (enso.sonnet.io), purely because it would allow me to apply better caret transitions between the lines of text. (I'm not gonna do that because I'm trying to keep it simple, but it's a strong temptation) Now a CSS tangent: regarding the accordion example from the site ( https://chenglou…

> Regarding the text bubbles problem [...], you can use `text-wrap: balance | pretty` to achieve the same result. No, neither solves the problem. And even if `balance` did work, it's not a good substitute because you don't usually want your line lengths to all be the same length. See also, related CSS Working Group issue: https://github.com/w3c/csswg-drafts/issues/191

Ha, I didn't know about that, I stand corrected, thanks!

Re: Pretext: TypeScript library for multiline text measurement and layout

#64
post #52
post #12

This 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 count using an off-screen canvas as a form of "calculating" here.

Re: Pretext: TypeScript library for multiline text measurement and layout

#65
post #12

This 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 layou…

How would you explain what it's doing here and why the author bothered to create the library?

Re: Pretext: TypeScript library for multiline text measurement and layout

#66
I was just writing a long comments about how the "const prepared = prepare('AGI 春天到了. بدأت الرحلة ', '16px Inter')" example makes no sense, as the font name is weirdly split across both arguments, but theres some right-to-left stuff going on. The font is "16px Inter", and the arabic and emoji are part of the first argument

Re: Pretext: TypeScript library for multiline text measurement and layout

#68

Has someone ever found a good solution for long / infinite lists / grids virtualization not breaking browsers native text search? Maybe for this we need a new web "Search" API instead of JS. Not sure it can be done otherwise without browser's help.

Lol improving the DOM and HTML instead of just tossing it into JS? WHATWG will be rolling on the floor for days.

Re: Pretext: TypeScript library for multiline text measurement and layout

#69
post #12

This 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…

Even when it is rendered... I have my text/zoom level pretty close to maxed out on Android as my issues are mostly retinal, not correctable with glasses... and so many apps will completely scroll my long inputs off screen while I'm trying to input... or otherwise make it impossible to see/edit after I've entered a handful of lines. It's infuriating to say the least.

Re: Pretext: TypeScript library for multiline text measurement and layout

#70

I 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 c…

What you're missing is that each segment (typically a word) only needs to be measured once, in the setup phase. The canvas gets thrown away after that, and subsequent layout passes all reuse the cached measurements. If you only perform layout once, it doesn't save any work. If you need to reflow many times, it saves a lot.

Are you sure the browser doesn't similarly cache it's own layout calculations?
Post reply on HN