Follow-up Comment #5, bug #66980 (group groff): [comment #4 comment #4:]
> The same set of knowns and unknowns may apply to devhtml as well; I'm not
> familiar with it. For instance, if groff already writes HTML using UTF-8
> encoding, it's probably best to output a U+2026 and let the renderer worry
> about it from there.
I'm thinking the, uh, epistemes in question don't apply to the HTML device.
For one thing, HTML is frequently rendered using proportional faces, so if the
renderer supports an ellipsis code point at all, it's likely to be a "good"
width (this observation might not be strictly on point for this ticket), and
kerning adjustments by HTML renderers are beyond our control ("Problem 1: Two
of these characters next to each other will be set badly.").
_grohtml_(1):
grohtml writes output encoded in UTF‐8 and has built‐in HTML
entities for
all non‐composite Unicode characters. In spite of this, groff may
issue
warnings about unknown special characters if they can’t be found
during
the first pass. Such warnings can be safely ignored unless the
special
characters appear inside a table or equation.
One day, I hope to kill off that "first pass".
(Also, the man page should probably say "outputs" or "writes out" instead of
"has". And qualify "all" with "non-Basic Latin".)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66980>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
