>> 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 sources of input: Either a character code which
is implicitly or explicitly mapped onto a entity, or `\[...]' which
directly enters the entity. For your example, the entity name is
`u0430', and if there is no .trin request or something similar for
this entity, hyphenation won't work.
In case you are interested in implementation details: At the first
stage of processing (mostly the stuff in files `input.cpp' and
`env.cpp'), GNU troff handles object `u0430' as a character entity.
In phase two (mostly stuff in file `node.cpp'), object `u0430' is
handled as a glyph entity.
However, this is something the user shouldn't take care of. It should
be sufficient to know that after the input is broken into lines, we no
longer have input characters but glyphs, which means that certain
operations like applying .tr to the contents of a diversion are no
longer possible.
>> Well, yes, right. I would call it a feature, since no real-world
>> documents are affected in any way. Do you want to document it?
>
> Frankly, yes :) -- add a warning to the description of the .tr
> request. Especially so, because there are examples in the manual in
> which the mapping is changed and then "restored" back. The user
> should know the side effect of this operation.
Thanks in advance!
Werner
