> > 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 _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff