On Wed, Dec 28, 2022 at 07:33:27PM -0500, Thomas Guyot-Sionnest
<derm...@aei.ca> wrote:
> Also worth nothing, with Fira Code under VS Code, ligatures normally
> always end up as the same length, so even though === can be ligatured to
> ≡ it's still taking 3 chars length (Fira makes some glyphs longer and
> may also increase the free space around them so they fit better).
Sure, but are these three characters exactly as wide as three i's and
three M's? and eactly 1.5 timnes as wide as 日? in all fonts used?
because that is required by urxvt).
> For all the tested Arabic chars in the previous email, all end up with a
> slightly shorter width in VS Code so I presume it's using a substitute font
> and doesn'T care as much about alignment, so we lose the fixed width
> property. This would be bad for rxvt (besides losing alignment, I presume
> lines are folded based on char count not rendered length). I think the
> ligatured version would probably also look quite ugly in a word if it took
> the width of two characters, so even if we could get the ligatures working.
There is no standard for character widths - urxvt uses the locale data, so
should be compatible with other programs running on similar systems using
it, but it is very common for both terminals and applications to hardcode
their own internal width table. That's not wrong, but of course all these
can differ, causing layout problems, as terminal programs generally need
to know the width of characters.
> And then, another issue would be line wrapping - how do you render a 2-3 char
> ligature across the border? Unless you can wrap "ahead", meaning some lines
> would wrap before the terminal width, the end result would be un-ligatured
> characters on the near edges of both line! (In any case, please don't break
> line warping, it works flawlessly in rxvt-unicode and I love it).
Since (western) ligatures are generally optional, it'Äs trivial to render
them, as it must be correct to not render them. With complex scripts such
as arabic, I don't think there is a correct solution, or even a good
solution. And even if there were, most applications would likely miscount
the width of strings, causing layout issues.
Frankly, I think this is the fault of those scripts, they simply were not
designed for the terminal world, and cnanot be forced in an acceptable
way, either. I do think there would be compromises (better called "hacks")
that make these somewhat usable for simple cases, but I don't think there
can ever be "correct" asrabic support in terminals, unless readers will
adjust to the broken shapes urxvt sometimes outputs.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
rxvt-unicode@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
