> So - we now get a new converter, not iconv, but a special-purpose
> gpreconv filter. It knows that it is converting things that will
> later be fed to groff. Pity. Where is my beautiful Unix?
Uh, oh, let me try to explain again: gpreconv won't have any effect if
your document is already converted to UTF-8, and if you explicitly set
groff's input encoding to utf-8.
> This converter may change the sequence of symbols in the file, not
> only the representation of these symbols. Ach.
Well, I don't think that converting to \N'...' will be in the final
version. This is Bruno's current solution to overcome groff's
restriction of 202 input characters.
> Does gpreconv also know whether groff will be called with the -C
> option?
Of course.
> Is it not far simpler to document that groff must be called with a
> file coded in ASCII or Latin-1 or UTF-8?
This is far too simple. We like it more complicated.
Werner
_______________________________________________
Groff mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/groff
