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

[Egil Kvaleberg]

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

>   Implement a function in libgroff to recognize the type of *any*
>   image and to extract the bounding box. 

As long as "any image" means "any image format that gpic/groff", then
the ".bb", or whatever, becomes (in troff/input.cc):

/*EK*/
void bbox_request() 
{
  symbol nm = get_long_name(1);
  if (nm.is_null())
    skip_line();
  else {
    while (!tok.newline() && !tok.eof())
      tok.next();

    class image img = image(nm.contents());
    llx_reg_contents = img.bb_left();
    lly_reg_contents = img.bb_lower();
    urx_reg_contents = img.bb_right();
    ury_reg_contents = img.bb_upper();

    tok.next();
  }
}

(Assumes the improved version of class image)

Wasn't too hard. was it. It even worked at first attempt:

        .bb image.ps
        \n[llx] \n[lly] \n[urx] \n[ury]
        .br
        .bb image.pgm
        \n[llx] \n[lly] \n[urx] \n[ury]
        .br

Gave:
        20 20 575 802
        0 0 159 224

But boy, is this the wrong type of information to bring to the user
interface. Seriously.

What groff user cares (or rather, should care) an iota about internal
implementation detail of images like that? It is bad, and just one of
the reason I really would want to see images done via gpic. And groff is
really meant to be a user interface, macros notwithstanding.

The above bbox_request() is btw. a full replacement for the existing
ps_bbox_request(), since it will support everything .psbb does (the
appropriate error messages are done by class image).

Whatever happens, any mention of .bb and/or .psbb in the documentation
should be accompanied by a note saying that this is mostly for backward
compatibility, not for new designs. Or something like that.

>  I'm rather sure that such a
>   program already exists which code can be reused

Agreed, but again should be an implementation detail within class image.
>     \X'image: ...'
> 
>   without specifying the image type. 

Excellent!

But why call it \X'image: ...'? 

To me, the \X escapes seem to be more or less hacks that communicate
things to device drivers that really is meta-information as far as groff
proper is concerned. 

So I really think images deserve an escape sequence all by themselves. 

>  The device driver then calls the
>   appropriate XXXtopnm external program in case it can't understand
>   the image format natively.

Better.

But again, that should be behind the scenes of class image.

> Some graphics manipulation options are necessary to be added to the
> DESC file and to the command line of the device driver, e.g., how to
> convert colour to gray or which type of dithering.
> 
> It becomes really tricky...

I am not yet in a position to comment, since I haven't looked at the
troff device driver level. But presumably the device drivers "in the
package" can benefit from class image?

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/