Re: [Groff] folding preconv into soelim?

[Keith Marshall]

On Friday 06 January 2006 10:27 pm, 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?
>
> 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.

Ok.  Sounds good.  No problem from the groff user's perspective then :-)

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

I don't see a problem, as such, but see below.

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

I hadn't appreciated this behavioural distinction in .so processing;  thanks 
for pointing it out.

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

Good.  We are on the same wavelength then :-)

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

>From a classical troff user's perspective, where the user himself specifies 
the preprocessor sequence as a command pipeline, it might seem more intuitive 
that a charset encoding converter would have a name reflecting its function;  
`preconv' just seems better suited than `soelim', as a name to reflect this 
intent.  Not a major issue, I know, but I thought it worth a mention.

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

After further consideration, I believe we could have both, yet only require 
*one* common preprossor program.  Here's how:--

* Create the composite soelim/preconv filter, as you have proposed; let it be 
called soelim, and invoked as `soelim -k' to activate the preconv mode where 
required, or without the `-k' flag, for normal soelim operation.  This is 
exactly as you have planned to do it.

* Make a trivial addition to the code, such that if the program were renamed 
to `preconv', and subsequently invoked under that name, the `-k' option is 
forced `on', whether specified or not.

* Install this as ${bindir}/soelim, just as you normally would, but then also 
symlink, hard link or copy it to ${bindir}/preconv;  (choice of which of 
these options is most appropriate will be system dependent).

This way, groff could always invoke the preconv filter as `soelim -k', as you 
have planned, but the classical troff user, or script writer, would have the 
option of using the alternative `preconv' name in his command pipeline, if he 
prefers, and this...

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

...would be unnecessary.

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

Neither can I :-)

Best regards,
Keith.