Follow-up Comment #3, bug #59402 (group groff): Unlike uconv, which can be asked to output NFD, preconv always outputs NFC unicode. Also, this bug is incorrectly named, troff does recognise the preconv output, it is just telling you that the decomposed character requires a combining diaeresis which is not available in the selected font. If you have a font which contains u0308 troff would not complain. The attached shows the example but using the DejaVuMathTextGyre as a special font. The second example is using \[u00F6], which is what preconv emits on receiving a "ö". To my eyes the second version looks better, a combining diaeresis has to be taller than any glyph it may be used with. It is _always_ better to use a combined glyph rather than building with multiple glyphs.
In the example if uconv asked to output NFC all is well since preconv outputs
\[u00F6] which troff converts to \[:o] which exists as a glyph in font TR.
Even "\[u006F_0308]" works since preconv leaves it alone and troff recognises
it as ":o".
I'd love to know why groff uses NFD at all, Branden does not know. The Unicode
FAQ says:-
Q: Which forms of normalization should I support?
The choice of which to use depends on the particular program or system. NFC is
the best form for general text, since it is more compatible with strings
converted from legacy encodings. NFKC is the preferred form for identifiers,
especially where there are security concerns. NFD and NFKD are most useful for
internal processing.
By "internal processing" it means searching and sorting, neither of which we
do. In particular for most large fonts the majority of glyph IDs we use are
derived from the NFD form (when there is no groff name for the glyph), i.e.
the decomposed form. The problem with this, and why it is not recommended for
"IDs" is because different input characters can have the same decomposed form
which leads to duplicate entries in a groff font.
In the Tinos font there are two entries for the ID u03B9:-
derij@pip:~/.groff/fonts/devpdf $ grep -i "u03B9 " TinosR
u03B9 269,459,10 0 541 iota -- 03B9
u03B9 333,0,217 1 2385 uni1FBE
U+03B9 = "ι", U+1FBE = "ι"
Let's see what troff does with these 2 different input characters:-
derij@pip:~/.groff/fonts/devpdf $ echo 'ιι'
ιι
derij@pip:~/.groff/fonts/devpdf $ echo 'ιι' | preconv
.lf 1 "-
\[u03B9]\[u1FBE]
derij@pip:~/.groff/fonts/devpdf $ echo 'ιι' | preconv | groff -Tpdf -fTinos
-Z |grep "^C"
Cu03B9
Cu03B9
Both have been converted to U+0389, which is the glyph for small letter iota
which is the much more common glyph I believe but because it is a duplicate
entry in the groff font there is no guarantee which glyph is actually used.
Grops and gropdf differ, gropdf selects the first matching entry while grops
uses the last matching entry. So in postscript you will see the tiny adscript
iota if u03B9 is requested.
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.
(file #59173)
_______________________________________________________
Additional Item Attachment:
Name: bug#59402.pdf Size: 17KiB
<https://file.savannah.gnu.org/file/bug%2359402.pdf?file_id=59173>
AGPL NOTICE
These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.gnu.org/source/savane-8c6c341578ed1ff525dc746b94af9a11d30d7444.tar.gz
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?59402>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
