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