Follow-up Comment #5, bug #59402 (group groff): [comment #3 comment #3:] > Unlike uconv, which can be asked to output NFD, preconv > always outputs NFC unicode.
It appears to me that preconv is equally willing to output NFC or NFD
depending on what its input uses.
$ printf "co\xF6perate\n" | LC_CTYPE=en_US.iso88591 uconv -f latin1 -x Any-NFD
| preconv -eUTF-8 -r
coo\[u0308]perate
$ printf "co\xF6perate\n" | LC_CTYPE=en_US.iso88591 uconv -f latin1 -x Any-NFC
| preconv -eUTF-8 -r
co\[u00F6]perate
(Since uconv's -f flag explicitly gives the encoding of the input, I'm not
sure why uconv fails without LC_CTYPE being set as above as well, but it's not
something I care to investigate.)
> 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.
Ah, thank you for shedding light on this important point. So this means
there's not a problem in the formatter at all, and the changes Branden
despaired of shouldn't be necessary even in the long term when groff is
chewing up Unicode input directly. We may just want better glyph coverage in
the default fonts that ship with groff by then.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?59402>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
