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

[Egil Kvaleberg]

On Sun, 2002-11-17 at 13:12, Ralph Corderoy wrote:

> I'd echo that.  netpbm exists so programs don't have to attempt to
> understand the image formats that are out there today, or tomorrow.

I must very seriously disagree.

Implementing pnm, or pam, first is fine, and that is what I have
intended to do. As a proof of concept, and also something that can be
used for many purposes.

But a proposal should definitely NOT be limited to postscript and pnm -
it should be far more general - allowing support for a range of formats
as required.

> Understand PAM and let make(1) or whatever, do the work of building 
> the required pixmaps using netpbm

Some reasons why this limitation is not a good idea in the long run is:

1. Pnm (or pam) images are in many ways unsuitable for publishing work.
Pnm leaves important issues like gamma as an untrackable "variation",
and pam, where at least there was a chance to correct the issue, leaves
gamma unmentioned and presumably undefined.

2. When material is prepared for publishing on paper, CMYK is the by far
preferred method for colour coding. Many printers won't touch anything
else. Pnm has no support for CMYK colour coding whatsover. Again, pam
could have corrected this, but so far I've seen nothing.

3. The formats mostly used by printers are TIFF and JPEG, both normally
in their CMYK versions. The formats mostly used in the web is JPEG, GIF
and PNG, always in RGB. Why on earth should we then settle in something
that no-one else uses? The pnm formats and programs are super for all
sorts of conversion tasks, but I fail to see their value as means of
storing and exchanging images.

4. Dealing with uncompressed images in publishing quality in 
formats like pnm is at best grossly inefficient. Each image would easily
be more than 10 megabytes large, and a publication can contain many,
many images.

5. The make-concept introduces quite unnecessary hindrances in the use
of groff for non-programmer users. As long as I write and maintain
suitable macros, my father is very happy to write and maintain groff
documents. If he had to learn about the concepts behind make, I'm afraid
that would have been a big NO.

6. The make-concept for converting images is a nuisance for any user. It
forces you to maintain lists of images used in the publication in
Makefiles. Which is IMHO unnecessary duplication of information. Yes,
one can always write tools to automate such tasks, and I'm quite sure
than one would easily get a grant from the Department of Silly Walks to
undertake such a task. 

It probably boils down to this: Who is more important, the groff user or
the groff programmer? 

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/