Re: [Groff] Proposal for raster graphics extensions to gpic

[Werner LEMBERG]

> As long as "any image" means "any image format that gpic/groff", then
> the ".bb", or whatever, becomes (in troff/input.cc):
>
> [...]

Exactly.

> But boy, is this the wrong type of information to bring to the user
> interface. Seriously.

It isn't IMHO.  Here, I compare groff with TeX: .psbb (and the
not-yet-available .imagebb) is a low-level primitive which should be
hidden by an appropriate macro.  I think it makes no sense to provide
a higher-level command.

> What groff user cares (or rather, should care) an iota about
> internal implementation detail of images like that?

Noone.  It is the job of the macro package (or the preprocessor) to
provide better syntax.

> And groff is really meant to be a user interface, macros
> notwithstanding.

I disagree.  TeX is not LaTeX, and raw gtroff is not ms or mom.

> The above bbox_request() is btw. a full replacement for the existing
> ps_bbox_request(), since it will support everything .psbb does (the
> appropriate error messages are done by class image).

Yes.

> Whatever happens, any mention of .bb and/or .psbb in the
> documentation should be accompanied by a note saying that this is
> mostly for backward compatibility, not for new designs. Or something
> like that.

It will mention that it is a low-level request.

> >  I'm rather sure that such a
> >   program already exists which code can be reused
> 
> Agreed, but again should be an implementation detail within class
> image.

Of course.  But we should make life as simple as possible by searching
for a simple implementation right now.

> >     \X'image: ...'
> > 
> >   without specifying the image type. 
> 
> Excellent!
> 
> But why call it \X'image: ...'? 
> 
> To me, the \X escapes seem to be more or less hacks that communicate
> things to device drivers that really is meta-information as far as
> groff proper is concerned.

Hack?  I don't think so.  gtroff shouldn't be aware of the image at
all!  It is just an information for the device driver to insert some
data at a specified place (for example, consider a background image).
So \X is the proper interface IMHO.

> >  The device driver then calls the appropriate XXXtopnm external
> >  program in case it can't understand the image format natively.
> 
> Better.
> 
> But again, that should be behind the scenes of class image.

I don't think so.  We need to be able to control image conversion
somehow.


    Werner