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 _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
