Re: [Groff] unicode support - where to compose?

[Werner LEMBERG]

> > Currently, groff only recognizes a very limited set of
> > ligatures (fi, ff, etc.)
>
> Ah, good example!  This is already an precedent where groff combines
> adjacent input nodes.  When the user doesn't want the ligature, he
> can use \& as a separator between the two, right?

Correct.  On the other hand, ligature handling needs a rewrite to use
arbitrary ligatures, and to make it user-controllable.  Just think of
the old `st' ligature and the missing `fi' ligature in Turkish.

> So I imagine that noone will object if troff combines
>
>              x\[u0302]\[u0301]
> into
>              \[u0078_0302_0301]

I think this is OK.  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.

> > > In the second case into preconv (i.e. preconv would translate
> > > <U+0078><U+0302><U+0301> to \[x u0302 u0301] but would leave
> > > alone x\[u0302]\[u0301]).
> >
> > This would be perfect.
>

> Hmm?  Why do you qualify the second approach as "perfect", when the
> other one is more in line with the mechanics how ligatures work?
>
> I just wish to know which of the two is preferrable.

???  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.  For me, this separation of tasks looks reasonable, thus
my `perfect' comment.  The important case is the former one, and it
seems that it is really straightforward to.  The latter is quite
complicated -- the node merging code in GNU troff is, well, not easy
to understand -- and can be postponed without problems.


    Werner