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

[Egil Kvaleberg]

On Sun, 2002-11-17 at 11:38, Werner LEMBERG wrote:

> As mentioned in another mail, moving some code to libgroff seems to
> be the right solution 

You're right, of course.

I've rid "class image" of gpic peculiarities and moved image.* to the
include and lib trees.

> -- we only need to get the bounding box and
> pass the image to the device driver.

My intention was that class image also should be able to produce a
digested image for those drivers that wants it.

>   Both gpic and gtroff should be
> able to do that independently.

Agreed.

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

I've tried to give a number of reasons why I don't think this is a 
good idea in another message. There is also one more:

7. Forcing pnm or pam format will make efforts to integrate www/html
image output in groff pretty futile. Unless there is some secret
conspiracy between w3c.org and cable manufacturers to abandon
JPEG/GIF/PNG and go for ASCII PNM instead.

That said, I'm sure there is no reason to re-invent the wheel in terms
of being able to support a variety of graphics images (gimp, for one,
has an impressive library for graphics). But I prefer to postpone such
implementation details until later.

>   Of
> course, the PAM format should be understood by all drivers.

Don't think so.

Drivers, unless they want to, should only have to address already
decoded graphics. Beside the special cases mentioned earlier, the format
used for the graphics image should be transparent for the driver. 

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

If you insist, but it must be called .bb or .imagebb and work for any
graphics format that groff supports. Since .bb seems to be unused, then
why not?

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

gpic needs to know it there and then - hence the need for "class image".

The .bb mechanism is if no use for gpic.

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

You're right of course.

Egil
-- 
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/