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

[James Deri]

> On Sun, 2002-11-17 at 20:28, Werner LEMBERG wrote:
> >  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 agree fully with your comparison with Tex/Latex. 
> 
> But Tex was afaik originally meant to be usable standalone. Ditto with
> -roff.

You may be right, but I assure you "raw" is used. I have a system which
produces a run of 100,000 pages of PS output per quarter from a dynamically
generated troff file. This file contains \X'ps: image ...' statements (so I
have to pre-convert all artwork to eps beforehand). Now if I could do
\X'image: ...' = heaven! Dealing with these sort of volumes running through
pre-processors/macros adds to the runtimes.

> Macros in troff cannot be considered totally hidden.
> 
> 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. 

and the raw speed of its typesetting abilities.
 
> So there is no reason to make things more low level then absolutely
> necessary. Especially so when the low-levelness does not bring any
> advantages for the user. 

Low Level = increased performance.

> 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.
> 
> > ... 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.
> 
> > ...
> > 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.
> 
> > > >  The device driver then calls the appropriate XXXtopnm external
> > > >  program in case it can't understand the image format natively.
> > > 
> > > 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.
> 
> I've had an opportunity to look behind the scenes at the 
> drivers, and I 
> agree with you. It really seems like everything that has any
> intentions of being rasterized as graphics do so via 
> postscript, so there
> is probably no need for rasterization in class image. All the better.
> 
> Egil
> 
> PS: Wrt. zero movement images for backgrounds, isn't that what \Z'' is
> for?
> 
> PPS: I must say the source code for groff really is a pleasure to work
> with! Really something for the text-books, as the saying goes.
> 
> PPPS: Trying to digest all the information, I will try to make a
> structured suggestion toward the end of the week,
> -- 
> 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/
> _______________________________________________
> Groff maillist  -  address@hidden
> http://ffii.org/mailman/listinfo/groff

Cheers

Deri


************************************************************************
The contents of this message and any attachments are confidential and
are intended solely for the attention and use of the addressee only.
Information contained in this message may be subject to legal, 
professional or other privilege or may otherwise be protected by other
legal rules. This message should not be copied or forwarded to any other
person without the express permission of the sender. If you are not the
intended recipient you are not authorised to disclose, copy, distribute
or retain this message or any part of it.

If you have received this message in error, please notify the sender by
telephone (+44-20-7002-4000) and destroy the original message.

We reserve the right to monitor all e-mail messages passing through our
network.
************************************************************************