groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Egil Kvaleberg
Subject: Re: [Groff] Proposal for raster graphics extensions to gpic
Date: 18 Nov 2002 14:16:26 +0100

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.

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. 

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. 

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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]