Re: [Groff] User Problem with grops's Import.

[Ralph Corderoy]

Hi Stewart,

> > For instance, with my original w.ps figure gs reports
> > 
> >     %%BoundingBox: 301 357 311 405
> >     %%HiResBoundingBox: 301.679991 357.479989 310.319991 404.519986
> > 
> > I'm coming to the opinion that %%BoundingBox is worse than useless
> > unless you can engineer %%BoundingBox to equal %%HiResBoundingBox.
> 
> not so -- looks like you are hitting aliasing problems. Your EPS file
> is only 10pt wide, and with Bounding Box parsing being limited to
> integers, it won't ever import correctly. %%HiResBoundingBox has
> patchy support, even if gs does the right thing.

I agree that it is an aliasing problem.  However, if I really did have a
10pt square picture that I wanted to `blow up' to fill the top half of a
book page I wouldn't be able to position it accurately thus my comment
about needing %%BoundingBox to equal %%HiResBoundingBox, i.e. that there
be no aliasing.

> I prefer to have EPS files about page size, natural size, and use the
> including application to scale them to desired size.

In my case the natural size isn't page size.  I agree that starting with
a big picture and scaling it smaller works a treat (apart from the
horizontal offset).

> If you thought %%BoundingBox support/implementation was bad, OPI is
> much worse! Each application has its own interpretation of the
> standard.

I don't want to know  :-)  I'm thinking of ditching .psbb and doing my
own calculations using `gs -sDEVICE=bbox' and %%HiResBoundingBox to
generate more accurate figures for `ps: import'.

Cheers,


Ralph.