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

[Egil Kvaleberg]

On Sat, 2002-11-16 at 20:35, Werner LEMBERG wrote:

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

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. 

> Hmm, A new escape sequence is probably not needed; I can imagine that
> e.g.
> 
>   \X'pnm: import ...'
> 
> will do the trick

Fair enough.

I have not really started digging into groff yet, so I will have to wait
a while before entering into that discussion. 

In the long run, I imagine that device drivers get presented the name of
the image, the format, size and bounding box information. 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 invoce 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.

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

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. 

Via gpic, groff and macro packages get the information yhey need on a
silver tray via the .PS, and similarily the device driver gets all the
image information it needs via \X'pnm ...' or whatever.

> , to get the bounding box of the image.  The appropriate
> macro would be then called `.PNMPIC'.

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)

Egil
PS: I am not arguing to remove .psbb, because that is needed for
backward compatibility.
-- 
Email: address@hidden  
Voice/videophone: +47 22523641 Voice: +47 92022780 Fax: +47 22525899
Mail:  Egil Kvaleberg, Husebybakken 14A, 0379 Oslo, Norway
Home:  http://www.kvaleberg.com/