Re: [RFC] Reading images

[Alexander Malmberg]

Pete French wrote:
> > When the device is not 72 dpi.
> 
> O.K., rephrase the question - when is a screen device ever assumed
> to be anything other than 72dpi ?

When is a screen device ever assumed to be 72 dpi? I don't assume that
it is, postscript doesn't, and dps doesn't. They were designed to be
independent of such things.

That said, most implementations do assume that a screen is 72 dpi. For a
long time, it has been a reasonable assumption. It hasn't really been
true, but it has been close enough that users haven't been bothered much
by it (with a few exceptions; text is often the first thing to cause
trouble, so in eg. windows and X, you can scale text (sortof), but
nothing else).

However, although the assumption is reasonable today, I don't think it
will stay that way. Thus, I want to warn people that they shouldn't
write code that assumes that a screen is 72 dpi. That assumption is not
part of the rendering "interface" we have, and if you write code that
way, it won't work on systems where the screen is not 72 dpi.


There has been some discussion in the GNUstep ml:s about extending some
of the backends to handle non-72 dpi rendering, but I don't think anyone
has done any serious work on it yet. back-art should be able to render
things ok, though, and a long time ago (early version of back-art, which
is why there are no images) I did hack the x11/ server part to scale
things:

before:
http://w1.423.telia.com/~u42308495/alex/backart/backart_scale_3.png
after:
http://w1.423.telia.com/~u42308495/alex/backart/backart_scale_1.png

Looked nice at 1808x1356 on a 17" screen. :) Event handling wasn't done
properly, though, so you had to guess when trying to click something.

> Though I think the bit below answers
> that... is this a GNUstep specific problem by the way ?

Screens that aren't 72 dpi? No. It seems that many other gui:s are
trying to shift to device independent/vector based/scalable rendering.
We're already there, we just need to be careful not to make invalid
assumptions.

> I am sure
> that under OpenStep it was stated that the screen was assumed to be 72dpi
> no matter what the actual screen resolution was

I can't find any mention of it in OpenStep after having a quick look at
it. It might have been stated for OPENSTEP. Either way, if it was
stated, I consider it an implementation limitation, fairly reasonable at
the time, that GNUstep has fixed.

> (which of course depends
> on the visible area fo the physical screen and the resolution, plus whatever
> monitor controls the user has tweask and is thus effectively unknown).

True. The user would have to configure it. Actually, strictly using the
real dpi of the screen isn't perfect either. Eg. a user with impaired
vision might want to scale things up beyond the real dpi of the screen.

> > In practice, most systems pretend to be 72 dpi for performance and
> > simplicity, and because they can still get away with it (although
> > screens are approaching resolutions where you really need to scale
> > things properly; one of our strengths is that we already have a device
> > independent rendering model, so as long as people stick to the
> > interfaces, we can easily handle the switch to non-72 dpi screens).
> 
> If thats true, then what do you think the correct behaviour of
> initWithFocusedViewRect:(NSRect)rect should be then ? The documentation
> doesnt specify it one way or the other.

Not explicitly. You might want to look at the documentation for the DPS
operators sizeimage and readimage, though.

> The easiest way is to do it in
> screen pixels I guess - but then how do I guarantee to create a 512
> square image under those circumstances ?

Depends. If you just want to use it to render back to the device, it's a
good thing that the image is in device resolution. If you want an image
with a specific size in pixels, you'll need to figure out the
transformation between user space and image space (that's the 'Matrix'
entry) so you know what size the original rectangle you draw in should
be.

- Alexander Malmberg