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

[Werner LEMBERG]

> The concept of e.g. troff/ms only functions when the macros are so
> simple that people has a fair chance understanding and modifying
> them.  The flexibility and power of troff/ms lies in the ability to
> adjusr the macros for specific purposes.

Well, it depends on what you mean with `adjust'.  I don't think that
users should modify macros (except in certain, well defined
circumstances) but only parameters to influence the layout.

> As a groff user I am concerned about the actual height/width of the
> image, yes, but Postscript internal technicalities like bounding
> boxes I would very much like to not have to worry about, please.

Tell me a better solution.  You need height, width, x-offset and
y-offset -- this is four parameters.  Where's the difference to
returning the coordinates of the lower left and upper right corner of
the image?

> > ... But we should make life as simple as possible by searching
> > for a simple implementation right now.
> 
> Yes. But including foreign libraries, for instance, tend to create
> problems with packages that are user over a large variety of
> platforms.  I would think it would be easier to do a stand-alone
> proof-of-concept version initially, and then do something more
> generic as a second step.

I mean exactly that!

> > gtroff shouldn't be aware of the image at all!
> 
> Can't say that I really agree - IMHO groff should know as much about
> the images produced as other text and vector graphics.

Perhaps a misunderstanding.  After a call to .imagebb, groff can take
or leave the coordinates of the bounding box from the four bounding
box registers, but the image itself is completely ignored.

> PS: Wrt. zero movement images for backgrounds, isn't that what \Z''
> is for?

Basically yes, but in this context I dislike \Z'\X'...''.


    Werner