Real printing plugin?

Richard A. O'Keefe ok at cs.otago.ac.nz
Wed Mar 27 03:31:04 UTC 2002


I replied to Marcel Weiher, noting FOR CONTEXT that
	> I complained, nearly 2 weeks ago, about dramatic differences
	> between what I see on screen and what I get with "save PS".
	
Marcel Weiher <marcel at metaobject.com> continues his attack.

	I must have overlooked the part of our support contract the specifies 
	the guaranteed response times.
	
I do not expect any support from Marcel Weiher.
In fact, I don't expect any practical help from him at all.

The point is that it is relevant to a discussion to note a two week gap.
In particular, I had to reconstruct some of my examples.

	> 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.
	
What _is_ the point of this ad hominem attack?

My problem is PRECISELY that there is a dramatic size discrepancy
between what I see on the screen and what I get on the paper, and
there seems to be no direct way to control this.

The fact that N screen inches turn into KN paper inches (K > 1)
is precisely my problem.

I am *not* attempting a diagnosis.

	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.
	
This isn't exactly true.  *Parts* of MacOS assume exactly 72 dpi, but
parts do *NOT*.  This is quite clear in Apple's documentation.

The physical reality is that the resolution is 96 dpi.
The computational reality is that SQUEAK CAN EASILY FIND THIS OUT.

	>  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.
	
Yes, but I am not TALKING about Squeak's imaging model.
I am talking about observable physical phenomena.
I make no pretence of understanding what the heck is "really" goin
on inside the box.

I went to some pains to show that on each of the three main platforms
Squeak *COULD* know what the physical dimensions are.

Many people have complained in the past about the tiny, hard-to-read,
nature of Squeak's default fonts, which assume 72 dpi.  That's another
area where Squeak SHOULD take physical dimensions into account, and
select font sizes appropriately.

By the way, I note that Ghostscript comes with commercial-quality
versions of the 35 "standard" Postscript Level 2 fonts.  It should
be possible to automatically derive StrikeFonts from these, no?

	> It's quite a precise description.
	
	No it is not.  Do you want help or do you just want to bitch?
	
Is every request for help to be attacked?
Is every self-defence to be constructed as bitching?

	>   The effect is not sensitive to details.
	
	Yes it is.  You may not be aware of the fact, but it is.
	
I have tried it repeatedly, and for me, it is NOT sensitive to details.
I think the burden of proof is on someone who says it is sensitive to
details.  In what way is this effect sensitive to details?

	> 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.

It IS a useful description, because it is a measurement to be applied
BY A PERSON, not by Squeak.  It simply doesn't matter whether Squeak knows
what the size is or not.  If you set your screen resolution to 96 dpi,
then follow the steps I listed, you will end up quite reproducibly with
the situation I described.

	Squeak has no way at all of knowing how large (in inches)
	something it draws will be on your monitor.  None at all.
	
As I went to some trouble to point out, this isn't even close to true.
Squeak may not *ASK*, but the information is *THERE* to be had.
(OK, not to micron accuracy, but close enough to be useful.)
Not that it's relevant here, because the measurement is a measurement
to be made by a person, not by Squeak.

	> 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.
	
Great.  The important thing is that this is a scaling THAT I DID NOT REQUEST.

When you choose "Print PS to file" you are prompted
 - for file name (sans suffix)
 - for orientation
but not for scaling.

	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.

Not in 3.0.1 there isn't.

	However, printSpecs is actually never written, so it looks like
	some functionality was intended here but not completed.
	
Ah.  So I'm not the only one to want this feature, and I'm not the only
one to spend half a day getting lost trying to plug it in.

	> 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.

It can do a lot better than it does do.

	EXACTLY.  It seems you DO understand why "screen inches" is not a useful 
	measurement.
	
Not at all.  Screen inches is not only a useful measurement, it is the
MOST useful measurement in this context.  Because that's what I care about.
Pixels are only a means to an end.  I have no way of counting pixels for
myself, but I _can_ put a ruler up against the screen.

	> 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.
	
(a) Are you really sure about that?
    What law of physics says that NO screen can have a feedback channel
    to ANY computer?

(b) xdpyinfo seems to come up with the right number.
    Call it a guess if you like, but it's a *heck* of a lot better than
    guessing 72 all the time.

(c) I note that the screen resolution is electronically controllable.
    Whether there is a feedBACK path or not, there is a feedFORWARD path,
    and the computer can know what resolution it last told the screen to use.

	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.
	
Not true.  Some MacOS components use 1/72" *as their logical unit*.
The desk accessory that sets the screen resolution is one provided
by Apple, and it is quite explicit in the Apple Developer web pages
that users are _intended_ to use that desk accessory and applications
are _intended_ to respond to it.

	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.
	
That's the problem.  Someone may kvetch that the methods I described for
finding physical resolution are "only guesses", but they are BETTER guesses
than 72dpi-all-the-time.

	[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?
	
FOR HEAVEN'S SAKE!

He tells me how to do something.
I *do* it, showing that I paid attention,
and offer the result for general use,
and he calls such a response "bitching"!

It looks very much as though anything I say will be interpreted
by Marcel Weiher as "bitching".  I could praise Squeak to the sky,
and it would be "bitching".

I wish this MUA understood kill-files.

	I have a better idea:  publish your improved mapping as an [ENH] to the 
	list.
	
	Well, then maybe Squeak just isn't for you...
	
In short, only test pilots are allowed to use Squeak.
Nobody is allowed to ask for help.
	
Gosh, this character has made me angry.

Look, I am not a Squeak expert.  I don't pretend to be.
I like Squeak very much.  I tell people how wonderful it is.
But sometimes I need help, and I really don't appreciate
being stomped all over when I do that.
	



More information about the Squeak-dev mailing list