Re: [Groff] folding preconv into soelim?

[Keith MARSHALL]

Werner Lemberg wrote:
> After some thinking I now believe that it is better to fold the
> preconv preprocessor into soelim.  The reasons are obvious: Any `.so'
> request should be handled by preconv too ...

If I may play Devil's Advocate here -- for my knowledge and understanding
of internationalisation issues is, for all practical intents and purposes,
nonexistent -- but will that be sufficient?  How will the conversion be
handled, for a .so request, or indeed even for the top level input file,
if the user then doesn't specify preprocessing with soelim?  Will the
requirement to specify preprocessing with soelim, to achieve encoding
conversion, appear as an intuitive requirement to the end user, as
would a preprocessor dedicated to that function?

As I understand the issue so far, the conversion process may be achieved
by the preconv preprocessor, and any .so'd inputs would also need to go
through preconv.  Thus, the filter pipeline would need to include both
soelim and preconv, perhaps recursively, before the input reaches troff;
this is somewhat analogous to the case where soelim is required prior to
pic, for example, where pic code is embedded in a .so'd input file, yet
we don't consider folding pic into soelim.  Of course, the pic example
doesn't suffer on the horns of the dilemma of recursion -- preconv is
required before soelim, so soelim can recognise the .so requests, pulling
in the .so'd input files, which then must go through preconv -- which I
guess is the motivation for combining the two preprocessors.

I don't have a problem with this concept: I simply wonder if it would
not be more intuitive, from the end user's POV, to keep the two as
separate preprocessors, in spite of the increased difficulty in
providing a robust implementation.  Maybe, fold a soelim into preconv,
but still retain a standalone soelim, for the cases where there is
no requirement for preconv?  Then, within groff, share the soelim
pipeline slot with preconv, which would have precedence when required?

Just thinking aloud...

Best regards,
Keith.