The experience of rendering Arabic typography and its technical debt
1–10 of 87 posts
Re: The experience of rendering Arabic typography and its technical debt
#2very interesting, arabic is a good reminder that text rendering is mostly solved for the scripts that shaped the defaults.
The hard part is that typography, shaping, bidi behavior, font fallback, search, and the editor model all leak into each other.
You cannot fix one layer cleanly when the assumptions are wrong in all of them.
Re: The experience of rendering Arabic typography and its technical debt
#3A more academic treatment of justifying Arabic-script text can be found in https://quod.lib.umich.edu/j/jep/3336451.0023.104?view=text;...
Re: The experience of rendering Arabic typography and its technical debt
#4A more academic treatment of justifying Arabic-script text can be found in https://quod.lib.umich.edu/j/jep/3336451.0023.104?view=text;...
awesome article! i appreciated the alternatives and misc. workarounds to OT/unicode typesetting toward the end, very helpful :D (go blue!)
Re: The experience of rendering Arabic typography and its technical debt
#5[flagged]
Re: The experience of rendering Arabic typography and its technical debt
#6[flagged]
[deleted]
Re: The experience of rendering Arabic typography and its technical debt
#7[flagged]
Same, and it is a shame. Reading it is wearisome.
Re: The experience of rendering Arabic typography and its technical debt
#8I'd like to see some more mainstream usage of disconnected fonts for Arabic, for example like these: https://www.arabaddigital.com/en/article/2100-Quarantining-o...
Re: The experience of rendering Arabic typography and its technical debt
#9Very interesting. I just implemented a text shaper and renderer from scratch with support for complex scripts like Arabic, Nastaliq and Indic (will soon post about it here on HN). Now that you write about it, the lack of stretching really is a deficiency in the OpenType spec.
If you want a solution for this it has to happen in the rendering step, not the shaping (which is HarfBuzz's main task). The shaper has no information about the available space, but when rendering you could stretch individual glyphs to the desired width, similar to adjusting the width of whitespace in Latin, but more complex, because you actually have to modify the glyphs with a scale transform. I am not an expert on Arabic script by any means, but this should be possible IMO. It would at least be an interesting experiment. Of course the JSTF table would be the right way to do it, but there seems to be a lot of confusion around it. Maybe in the age of LLMs we can give it another shot.
Re: The experience of rendering Arabic typography and its technical debt
#10Is this a small typo?
> The relevant rule, W2 of UAX #9, reclassifies a digit as an ARABIC NUMBER if any of the previous strong characters in the paragraph were Arabic letters, and as a EUROPEAN NUMBER otherwise. Both render their internal digits left-to-right, which is correct: numbers everywhere on Earth are read most-significant-first.
Does the author mean most-significant-on-the-left? The statement as written is a statement about the order in which one reads or perhaps thinks the number, whereas I think the author is discussing how numbers, including collections of numbers delimited by hyphens and such, should be laid out on the page.