> > Currently, there is a single non-spacing glyph used in groff
> > (`slashnot' in devdvi; the other non-spacing glyphs from the
> > various DVI fonts have no names), and this has to be placed before
> > the base character. Additionally, it isn't a valid Unicode
> > character so there is no conflict.
>
> Does the separator need to be a glyph?
No.
> I haven't looked yet how exactly \& works, but for most devices I
> expect it to be an input node, but not a glyph.
`\&' is converted to a `dummy_node' in the output node list,
effectively representing a zero-width space. It avoids merging of
glyph nodes to both ligature nodes and to kerning nodes.
> > I've thought that you suggest to handle
> >
> > <U+0078><U+0302><U+0301> -> \[x u0302 u0301]
> >
> > in preconv, and
> >
> > x\[u0302]\[u0301] -> \[x u0302 u0301]
> >
> > within groff.
>
> Actually I want to do one _or_ the other. If it's done inside troff,
> there is no need to do it in preconv as well.
OK.
> > The latter is quite complicated -- the node merging code in GNU
> > troff is, well, not easy to understand --
>
> I'll try to put it there nevertheless, because composed characters
> in Unicode are a concept similar to ligatures; I would like to avoid
> implementing two similar things in two very different ways.
Please be careful! Unicode gets extended from time to time, and there
are high chances that new non-spacing diacritics are added.
Consequently, a solution within groff must be based on
user-controllable data.
I suggest to (re)use
.composite foo
(just a single argument) to register `foo' as a Unicode composite. At
startup, `composite.tmac' is loaded, make the registered Unicode
composite characters `active' (in the TeX sense).
Werner
_______________________________________________
Groff mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/groff
