Andries Brouwer wrote: > The very long pipeline contains invocations of > refer, ideal, pic, tbl, eqn, ditroff > but also lots of preprocessors of my own. If the groff version of refer > or tbl decides to turn my Latin-1 into UTF-8, then my own preprocessors > later on in the pipeline will no longer be able to handle the input. > On the other hand, if they turn stuff into \[...] or \N[...] escape > sequences, then again my preprocessors are confused since this syntax is > not traditional troff syntax, and unexpected in the input.
Don't worry here: we don't plan to change 'refer' or 'tbl' to convert Latin1 input to something else. The plan is that when a user invokes groff, the constructed pipeline contains an invocation to 'gpreconv'. A pipeline that you construct by yourself will continue to work. > Now you say "tough luck", and I don't mind, but if the idea is that groff > has a compatibility mode ... The compatibility mode is made for compatibility to AT&T UNIX troff. At that time, Latin1 as an encoding didn't exist. Therefore it's hard to argue that -C should imply interpretation of non-ASCII input as being Latin1. > > 2) We would have low acceptance from the people who produce man pages > > in EUC-JP, with the consequence that these "-Tnippon" hacks in groff (or > > equivalent hacks in "man" in some distributions) would need to stay > > forever. > > But you talk as if you are forced to change groff in ugly ways because > man is set in stone. But it is very easy to change man. It is not easy to change the opinion of many Japanese people, regarding the issue of EUC-JP vs. Unicode. Bruno _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
