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

[Werner LEMBERG]

> > This is something I still don't understand yet.  While I fully
> > agree that adding image support to PIC is a very welcome
> > extension, I think that plain gtroff without gpic should be able
> > to do the same.
>
> Perhaps?
>
> But why is it important to manage without a preprocessor?

Just a feeling :-)  Imagine a preprocessor foo which can't work
together with gpic.

> To me, groff is as incomplete without gpic as it would be without
> tab or other preprocessors. I think I have almost never written
> something in groff that did not use tab and other preprocessors.
>
> So in my view, there should be one preferred way of importing
> images, and that should be via gpic. Both because that is the more
> flexible way, but also because all effort would be directed in the
> same direction.

As mentioned in another mail, moving some code to libgroff seems to
be the right solution -- we only need to get the bounding box and
pass the image to the device driver.  Both gpic and gtroff should be
able to do that independently.

> In the long run, I imagine that device drivers get presented the
> name of the image, the format, size and bounding box information.

Exactly.

> If the PS driver sees a PS image, it will handle it
> itself. Similarly for JPEG/PNG/GIF in the HTML driver. Otherwise,
> there is a generic way in which the drivers will invoke some
> function to generate a generic pixel array under constraints that
> the drivers sets (max DPI etc), so that the driver does not need to
> concern itself about what the format is.

Any reason why groff should do that?  Given the netpbm package,
virtually any image can be converted to PAM before starting groff.  Of
course, the PAM format should be understood by all drivers.

> > and it is up to the device driver to interpret this > correctly.
> The only necessary command would be a pendant to `.psbb', >
> e.g. `.pnmbb'
>
> Are you sure?

Yes.

> Working with the .psbb/X'ps: import...' mechanism and the .PSPIC macro
> was the one thing that really convinced me that gpic was the way to go.
> gpic needs to investigate the size of the image, and that is where it
> should be done.

Any preprocessor which likes to include an image needs to know the
bounding box.

> If you insist on a .PNMPIC, fine, but then what is wrong with this
> definition:
>
>       .de PNMPIC
>       .PS
>       image("\\1");
>       .PE
>       ..
>
> (adding options for indents etc. is easy)

Hehe.  gpic only recognizes .PS/.PE at the outer level, not within
macros.


    Werner