Re: [Groff] folding preconv into soelim?

[Werner LEMBERG]

> > 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?

I say yes.

> 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?

My plan is to use groff's command line option `-k' to activate
encoding handling.  Selecting `-k' automatically selects `-s', while
the opposite isn't true.

> 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?

I don't see a problem here.

Note that it actually is possible to have files included with `.so'
which are *not* handled by .soelim:

  .so foo     \" handled by soelim
  . so bar    \" ignored by soelim, handled directly by GNU troff

If -k is specified, the encoding of the top-level file and `foo' is
converted but not that of `bar'.  This feature is rarely used.

> 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.

Yep.

> 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.

Exactly.

> 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.

Intuitive?  I don't think so.  Please elaborate.

> Maybe, fold a soelim into preconv, but still retain a standalone
> soelim, for the cases where there is no requirement for preconv?

Without option `-k', soelim will behave as usual.

> Then, within groff, share the soelim pipeline slot with preconv,
> which would have precedence when required?

Encoding conversion always happen before handling .so requests.  If
you insist to do it the opposite way, you can do

  cat foo | soelim | soelim -k | ...

but I can't imagine any situation where this should be necessary.


    Werner