Re: [Groff] Suggestion for images in groff/gpic, current state

[Egil Kvaleberg]

On Sun, 2002-12-01 at 06:58, Werner LEMBERG wrote:

> . The arguments to .image and \i should be changed to the following
>   IMHO:
> 
>     .image file [width [height [xoffset [yoffset]]]]
> 
>   This is two arguments less, and it fits better the idea of using
>   zero for padding arguments.

I like that, but I have one gripe: Does does four arguments provide
enough information for including PostScript items that lack a
%%BoundingBox? I fear it does not.

> . I'm not happy with the name of the `query' request.  For me this is
>   too general.  What about `imageinfo'? 

Fair enough. I thought about something similar, but thought it perhaps
was too long. But see below.

>  The same for the used
>   registers.  Note that \n[.color] is already in use, returning 1 if
>   colour support is active.
> 
>   Here my proposal, in analogy to the registers of \w:
> 
>     \n[imaget]
>     \n[imageb]
> 
>   These two registers should be r/w, so starting the names with a dot
>   is probably not optimal.

Agreed that this should be consistent, so no dot if r/w. But what about
namespace pollution? 

...
>   I don't see an immediate need to have registers returning the
>   natural height and width -- a call to `.image file' does the same.

Very good point - consider them deleted - I'll make a note of it in the
document.

>   This is implies internal caching of the information of the last
>   image (or images) to get reasonable speed.

The information for an image takes up probably less than 100 bytes,
anyway, so perhaps might even cache them all. That said, getting the
size information from most image formats is typically not very costly.

>   As you can see, I've dropped the width registers since you can get
>   the info with \w.

\w gives you the width, but also the top/bottom (i.e. height) for that
matter. 

I am sort of very divided wrt. the entire .imageinfo request. In many
ways it is pedagogically wrong to have a fancy command for this
function, since using it is for many situations the wrong thing. I have
not used it at all in my example document, for instance. I sort of
slapped it on as a last minute thing, anyway.

I think I will remove it altogether for the time being. Then complete
some of the "for further study" items, and then, when I learn more,
revisit the question.

> . There is no \n[.w] register, and I'm not sure that \n[.cdp] and
>   \n[.cht] are really appropriate for \i.  Images are not
>   characters...

There is a \n[.w], I just forgot to mention it. I have done no changes
to this functionality whatsoever, the .w as well as .cdp and .cht are
by-products of the existing implementation. This has in fact been an
important issue: that images should be handled analogously to existing
objects as much as possible. I think quite strongly that it is best to
keep it that way, but I will improve the documentation.

In a similar manner, the byproducts of \w are the same. I have two open
issues here: What should \[ct] be? It currently is set to 0. The other
is, what is the real difference between \n[rsb] \[rst] and \n[sb]
\n[st]? In my current implementation, they do not give the same values
for images (rsb and rst seem to be OK), and I think there may be
something fishy.

> . Having a \n[.image] register is probably too much.  Testing for
>   groff version 1.19 using the .x, .y, and .Y registers should do the
>   same.

I would much prefer checking the existence of a register than do magic
numbers. But we can just as well check the existence of another relevant
register. I'll remove .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/