Follow-up Comment #2, bug#65111 (group groff):
Hi Deri,
[comment #1 comment #1:]
> As I have documented elsewhere gropdf has to behave a little
> differently if a particular font does not define a space glyph.
That statement does sound familiar.
The idea of a "space glyph" is a difficult fit for *roff-descended
typography.
> This is because it can use a slightly more compact format if the font
> defines "space" or "u0020" as a glyph. In a "Hello World" example the
> difference is "(Hello World)" (glyph defined) and "(Hello) move
> horizontal (World)" (glyph undefined).
As you know, the latter is the only way a space is represented in *roff
internally and in device-independent output ("trout", "grout").
> The distance moved is set by troff, I assume this is the purpose of
> spacewidth in the groff font.
Yes.
> Some CJK fonts also don't have a space glyph. It is just a warning,
> and was useful in debugging, to know gropdf had switched to a slightly
> less efficient output format, the message could be removed, although
> knowing which mode gropdf was operating in if I am debugging a user's
> issue could be useful.
Since there is nothing the user normally needs to do, or even _can_ do
without undertaking a mild form of digital font development, I would
prefer that we demote this from a warning to debugging output.
It strikes me as somewhat similar to the erstwhile "can't write node in
transparent throughput" and the other diagnostic like that; the user
isn't asking for nonsense, and is powerless to do anything about the
diagnostic.
What do you think?
Regards,
Branden
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65111>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
