> I don't think it generates better results

It does if one is doing typesetting math-heavy documents. Nothing really matches TeX quality or flexibility in math typesetting, not even typst (yet, at least).

> And unicode is an evolving standard where this normalisation sometimes changes between standards

Unicode normalization is subject to its stability policy, and Unicode no longer allow adding new canonically equivalent code points.

https://www.unicode.org/policies/stability_policy.html

In some countries, legal documents are required to not have any paragraph breaks, so you can have a document with one paragraph spanning 100s of pages. OpenOffice has a hard limit of 65534 per paragraph, and it took LibreOffice quite some work to left it: https://bugs.documentfoundation.org/show_bug.cgi?id=30668

Why? Sounds ridiculous — intentionally making documents hard to understand in order to subsidize the administrative class.

So you can consistantly cite line numbers. Always the same number of lines per page. As with many legal writing rules, it probably made more sense back when journals were written with quills.

One reason that comes to mind, is to make sure no extra text is inserted in the empty space e.g. after a contract is signed.

Signing two copies solves that, or even making a copy after execution.

Does it solve it, or does it wind you up in court arguing over which copy is the "real" version?

Easy, just make three copies.

Who gets the third copy?

The government.

No pilcrows ?

The fix looks like a 5 line fix because it is a last step in a very long process of optimizing LibreOffice text layout that started years ago. This 5 line fix could not have been possible 10 years ago simply because the code it is fixing didn't exist back then.

This is still not rasterization, but a way to modify glyph outlines on the fly. How they are rasterized eventually should be mostly unchanged.

For some weird reason, printing defaulted to printing only selected text, but this is finally fixed https://bugs.documentfoundation.org/show_bug.cgi?id=139164

In Arabic, Mercury (planet) and mercury (element) are two different words (عطارد and زئبق), here the machine translation is using the wrong mercury for the context.

Photoshop relatively recently consolidated its text layout into a single layout engine (based on HarfBuzz) and Arabic support no longer an opt-in (which was the source of the trouble, you had to know you need to opt-in Arabic support before installing the application)

https://helpx.adobe.com/lv/photoshop/using/unified-text-engi...

There is 99% chance the software you are reading text on right now uses HarfBuzz to lay out the text, a library written mainly by a Persian person.

https://en.wikipedia.org/wiki/HarfBuzz

I believe that’s the specific guy that was referenced.

That is not the point I’m making, rather a single person is responsible for how most of software render text in most of the world writing systems and no one is wondering how 6 billion people on this planet so much depend on the work of “this one guy”. It is because text layout is something 99% of software developers can’t do right if their lives depended on it (same for anything that involves the irregularities of human nature, software developers are not cut for this).

> It is because text layout is something 99% of software developers can’t do right if their lives depended on it (same for anything that involves the irregularities of human nature, software developers are not cut for this).

Many can't even get the spaces before and after punctuation right, even though the correct way involves no irregularities.

Font usage on the web, 2022 edition.