>> Well, \N'...' is kind of a glyph-only object, but by its very
>> definition you can't hyphenate it.
>
> What about a \[u0430] coming from a UTF-8 file processed by preconv?
> What corresponding input character does it have provided no
> character translations were used?
There are two possible
Werner LEMBERG:
> This is not possible. How shall come a glyph-only
> object into existence? I don't count ligatures
> and similar things here since they also need input
> characters to exist.
> [...]
> Well, \N'...' is kind of a glyph-only object, but
> by its very definition you can't hyph
>> OK, but the reference to the input character is allowed to be
>> 'null', then?
>
> This is not possible. How shall come a glyph-only object into
> existence? I don't count ligatures and similar things here since
> they also need input characters to exist.
Well, \N'...' is kind of a glyph-onl
> Now that I have acquired more understanding, I don't have problems
> reading the manual. But I had had a hard time before!
The standard documentation problem of developer vs. user...
>> Actually, it's the same object, containing a ref- erence to both
>> the input character and the corre- spon
Werner LEMBERG:
> Yes, this is a mess, introduced long before I was
> involved in groff. However, this affects the ter-
> minology but not the documentation itself. AFAIK,
> I've fixed all places in the doc files to make a
> clear distinction between input characters and
> output glyphs.
>> However, please avoid the term 'AGL compatible'. We are not
>> talking about glyphs but about characters!
>
> Maybe this confusion is not only my fault also the manual's:
>
> The distinction between input, characters, and output, glyphs,
> is not clearly separated in the terminology of
Thank you for the kind and patient explanation,
Werner.
> However, please avoid the term 'AGL compatible'.
> We are not talking about glyphs but about charac-
> ters!
Maybe this confusion is not only my fault also the
manual's:
The distinction between input, characters,
and o
