Follow-up Comment #6, bug #59402 (group groff): On Tuesday, 3 November 2026 01:22:39 Greenwich Mean Time Dave wrote: > Follow-up Comment #4, bug #59402 (group groff): > > [comment #3 comment #3:] > >> The problem is that any unicode normalisation can lead >> to duplicate font entries, since the normalisation is only >> concerned with identifying input characters which are the same >> (i.e. they are both iota) and takes no account that the actual >> glyph shape is different in regard to the context in which >> the iota appears, but the user who knows the context rules >> will carefully use the correct input code and be surprised >> that troff has ignored the difference. > > So, how is this handled by other software that uses Unicode and a font that > has duplicate font entries for some glyphs? Surely there's a mechanism to > ensure the user's deliberate code point selection is properly reflected by > the choice of glyph in the font. That process doesn't seem like it would > be troff-specific. Is there some infrastructure groff is missing, perhaps > as a result of being limited to Type 1 fonts (bug #40717)? >
Hi Dave,
It is the groff font which has duplicate entries, the type 1 fonts are
keyed on the postscript name of the glyph which are unique (ttf/otf
fonts are keyed by a numerical glyph id which again is unique, they also
contain a mapping table between the unicode number of input characters
to the glyph id).
Groff fonts (e.g. TR) are keyed either by their character (ascii), a
groff name (e.g. \[:o]), or an NFD normalised unicode number (e.g.
uXXXX(_XXXX). It is the normalisation which can cause duplicates. Each
entry in a groff font includes an entry for the postscript name which is
used to locate a particular glyph in the font. If there are duplicate
entries, i.e. u03B9, there are two different postscript names ("iota"
and "uni1FBE") with no way of knowing whether the input character was an
iota or a prosgegrammn (U+1FBE).
Groff has mapping tables between unicode and groff names, and unicode
and postscript names, so it is theoretically possible to use the unicode
number as the key for groff fonts, converting groff names on input to
their unicode number (rather than the other way round as at present) and
using the unicode number for everything else, no normalisation. This
would mean there is always a 1:1 relationship between the input
character and the font. Other programs which deal with fonts are storing
the unicode of the input character and either using that to access ttf
type fonts or converting to a postscript name to access glyphs in a type
1 font, of course they also hold text in normalised NFD for sorting and
searching but whenever accessing the font the original unicode number is
used.
You can see this for yourself. In libre-writer copy/paste these two
characters 'ιι', they should look different (they don't in troff,
assuming you are using a font which has both characters), now do ctrl-f
and search for 1 of the characters - it will find two occurrences - this
shows it is using normalised NFD for the search (it finds two iota) but
not when displaying the character, otherwise the glyphs would look the
same as each other, as they do in groff.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?59402>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
