On Tuesday, March 26, 2002, at 02:00 AM, Richard A. O'Keefe wrote:

> I complained, nearly 2 weeks ago, about dramatic differences
> between what I see on screen and what I get with "save PS".

I must have overlooked the part of our support contract the specifies 
the guaranteed response times.

> Marcel Weiher <marcel at metaobject.com> replied:
> 	
> 	I don't think 'screen inches' are a very useful measurement.
>
> In the name of sanity, whyever not?

If you don't know why it is not a good measurement, then I am not sure 
if there is any point in continuing this.

>  It's what I *see*, after all.
> The screen resolution is 96dpi.

Well, on the Mac, the screen resolution is defined as exactly 72 dpi.  
This means that if your screen resolution is 96 dpi, you have a 
scaled-down view and cannot expect things to match 1:1 anyhow.

>  Does "approximately 192 pixels on a
> side" make it any better?

No.  The actual number of pixels would make it better.  This is because 
Squeak has no idea about inches, its only measurement for screen objects 
is PIXELS.  Squeak does not have a device independent imaging model.

>
> 	Can you produce a sample?
> 	It's kind of difficult to comment on rough descriptions.
> 	
> It's quite a precise description.

No it is not.  Do you want help or do you just want to bitch?

>   The effect is not sensitive to details.

Yes it is.  You may not be aware of the fact, but it is.

> 1.  Create a BookMorph.
> 2.  Drop a TextMorph in it.
> 3.  Make the font of the TextMorph New York 12.
> 4.  Stretch the thing so that it's about 2 inches (5 centimetres)
>     on a side.

Once again, 2 inches on a monitor is not a useful description, because a 
monitor is not a calibrated device.  Squeak has no way at all of knowing 
how large (in inches) something it draws will be on your monitor.  None 
at all.

> 5.  Type some text.

OK, the steps are easy to reproduce (apart from the "inches" part).

> 	>  Save PS in file, drop file onto MacGS.  The result is
> 	> nearly 4 inches on a side.
> 	
> 	So you're seeing a factor of 2?
> 	
> Yes.

Well, I checked, and found this:

	"Define initialScale so that the morph will fit the page rotated or 
not"
	savedMorphExtent _ morphExtent _ rotateFlag ifTrue: [psBounds 
extent transposed]
							ifFalse: [psBounds extent].

in DSCPostscriptCanvas>>writePSIdentifierRotated::

So the effect is, in fact, due to a scale-to-fit option.

A bit below that, you can see how to turn this off:

	initialScale _ (printSpecs isNil or: [printSpecs scaleToFitPage]) 
ifTrue: [
		pageExtent x/morphExtent x min: pageExtent y/morphExtent y
	] ifFalse: [
		1.0
	].

So it seems there is some kind of print-spec that can turn scale-to-fit 
on or off, with the default being on.  However, printSpecs is actually 
never written, so it looks like some functionality was intended here but 
not completed.

> I am using Squeak 3.0.1 on MacOS 8.6, as I believe I've said before.

Good for you!  I am using 3.2gamma on MacOS X.

> A better mapping would seem to be
>     pairs := #(
>         'Palatino'	'Palatino-Roman'
>         'NewYork'	'Times-Roman'
>         'NewYork-Bold'	'Times-Bold'
>         'ComicPlain'	'Helvetica'
>         'ComicBold'	'Helvetica-Bold'
>         'Atlanta'	'Helvetica'
>     ).
>
> I am free to do a lot of things, including reimplementing Squeak from
> scratch.  My freedom to flap my arms does not help me fly.  My freedom
> to fix bugs in Squeak is of little use when I don't know _how_ to fix
> them.

Well, I can help you there.

> I would point out that my screen SIZE is not at issue, my screen
> RESOLUTION is.

Yup.  And Squeak has no way of knowing your screen resolution.  Also, 
the way device-independent graphics work is usually not by working 
backwards from a particular screen resolution.

> I would also point out that putting in a fudge factor, while
> technically possible (if only I knew where and what), would not work.
> NEITHER of the very different machines I run Squeak on has a fixed
> resolution; both of them can be put into about a dozen different
> formats with different resolutions and effective sizes.

EXACTLY.  It seems you DO understand why "screen inches" is not a useful 
measurement.

> 	The problem is that the Squeak graphic routines are not device
> 	independent, meaning the mapping to device independent coordinates is
> 	always just a guess.
> 	
> For the life of me I can't see why that should be so.



> The X11 system has, since its introduction, made it easy for any 
> application
> that cares to discover the actual resolution of a display.

This is also just a guess, since there is no feedback channel back from 
the screen to the computer.

>     DisplayWidth(display, screen)
>     DisplayHeight(display, screen)
> 	provide width and height in pixels
>     DisplayWidthMM(display, screen)
>     DisplayHeightMM(display, screen)
> 	provide width and height in millimetres.
>
> In Windows, GetDeviceCaps(hdc, property) reports
>     HORZSIZE		width of display in millimetres
>     VERTSIZE		height of display in millimetres
>     HORZRES		width of display in pixels
>     VERTRES		height of display in pixels
>     LOGPIXELSX		number of pixels in logical inch along display width
>     LOGPIXELSY		ditto, along display height

Once again, all of this is just guesswork.

> I don't have my old Inside Macintosh handy, and Apple's on-line 
> documentation
> is not terribly easy to follow.

On the Mac, a pixel is defined to be precisely 1/72 of an inch.  If you 
have different dpi, you are, technically, out of spec.  and will get 
images that are proportionally shrunk.

>  Using QuickDraw you've been able to find out
> the gdRect of the screen (the width and height in pixels) for a long 
> time;
> the Display Manager is supposed to let you find out the resolution (and 
> to
> notice changes to the resolution &c), but I can't figure out how.
> Ah, found it.  Yes, this goes back a long way too:
> 	ScreenRes(hres, vres);
> returns the horizontal (hres) and vertical (vres) resolutions in pixels
> per inch.  And the GDevice record has a gdPMap (PixMap**) handle and
> the hres and vres info is in there.
>
> So in all three of UNIX-X11, Windows, and MacOS (7-X at least), it
> is perfectly possible for Squeak to find out for itself what is the
> screen size and what is the screen resolution.  I should NOT have to 
> tell it!

This all turns out not to be the case, for the reasons given above.

It is also irrelevant, since Squeak does not use a device-independent 
imaging model.  Meaning that when you specify dimensions in Squeak, they 
are in PIXELS, and will come out whatever the size of pixels are on your 
current display device.

[more bitching removed]

> I have shown above how easy it is to come up with a mapping that 
> preserves
> more (but still not enough) of the appearance that one wishes to 
> preserve.

This is what I suggested you do.  Why did you have to bitch about it 
instead of just doing it?

> If there is a better mapping used in 3.2, I'll be happy to patch my
> Squeak 3.0.1 image to match.

I have a better idea:  publish your improved mapping as an [ENH] to the 
list.

> The freedom to patch a system is a very nice freedom,
> but not half so nice as the freedom to use a system which doesn't
> need patching so much.

Well, then maybe Squeak just isn't for you...

Marcel