Real printing plugin?

Richard A. O'Keefe ok at cs.otago.ac.nz
Tue Mar 26 01:00:26 UTC 2002


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

	On Thursday, March 14, 2002, at 12:33 AM, Richard A. O'Keefe wrote:
	
	> I mean "larger".  Bigger.  Dramatically bigger.
	> Take a specific case.  A BookMorph with one page, containing text in
	> New York 12, the area holding the text being approximately 2 inches
	> on a side.

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?  It's what I *see*, after all.
The screen resolution is 96dpi.  Does "approximately 192 pixels on a
side" make it any better?

	Can you produce a sample?
	It's kind of difficult to comment on rough descriptions.
	
It's quite a precise description.  The effect is not 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.
5.  Type some text.

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

	>  Also the text is some sans-serif font (on looking in the PS file, I 
	> see it is Helvetica).
	
	The font-mapping is done in
	PostscriptCanvas>>postscriptFontInfoForFont:  with helpf from a
	mapping table initialized in
	PostscriptCanvas>>initializeFontMap.  If you can find better
	mappings using commonly available Postscript fonts, that would
	be a very good contribution.
	
I am using Squeak 3.0.1 on MacOS 8.6, as I believe I've said before.
There *isn't* any postscriptFontInfoForFont: method anywhere in the
system.  There is, however, a postscriptFontNameForFont: method
written by someone who positively hates putting spaces after colons.

Postscript Level 1 has 13 "standard" fonts.
Postscript Level 2 has 35 "standard" fonts.
Postscript Level 3 has 136 "core" fonts, and that came out in 1997.
If we stick to the 13 original fonts, we should be on pretty safe ground.

That is,
    Courier, Courier-Bold, Courier-Oblique, Courier-BoldOblique
    Helvetica, Helvetica-Bold, Helvetica-Oblique, Helvetica-BoldOblique
    Times-Roman, Times-Bold, Times-Oblique, Times-BoldOblique
    Symbol

Ideally, a font mapping should obey the rules
1. Target fixed pitch IFF Source fixed pitch.
2. Target sans-serif  IFF Source sans-serif.

The font mapping in PostscriptCanvas>>initializeFontMap is
    Palatino 	 -> Palatino-Roman
    NewYork	 -> Helvetica
    NewYork-Bold -> Helvetica-Bold
    ComicBold	 -> Helvetica-Narrow-Bold

This mapping has a number of defects, which have no doubt been
remedied by now.
(a) Halo-Font lists
	DefaultTextStyle
	Atlanta
	ComicBold
	ComicPlain
	DefaultFixedTextStyle
	NewYork
    most of which are not in the font mapping table.
(b) Palatino-Roman and Helvetica-Narrow-Bold are not in the old
    Level 1 "core" fonts.

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

	>   When I print it, the
	> text area is about 5 inches on a side.
	>
	> 	The Morphic Postscript routines assume 1
	> 	pixel = 1 point ( 1/72 inch ).
	>
	> Well, it shouldn't assume that, because 1 pixel = 1/96 inch on my 
	> screen.
	
	You are free to include a scale factor to adapt it to your screen size.  

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.

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

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.

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

I don't have my old Inside Macintosh handy, and Apple's on-line documentation
is not terribly easy to follow.  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!

	> 	you can scale it to your needs, though I don't know if there is any
	> 	Squeak front-end for doing this.
	> 	
	> EPS files are easy to scale, but PS files?  How?
	
	'<x-factor>  <y-factor> scale' before the parts you want scaled.  You 
	would probably want to do this in the page-setup code.
	
I see.  So 'easy to scale' means "first learn a new programming language,
and then hack the Postscript with a text editor."  This is __easy__????

	> I've now made several experiments, and I _never_ get W x H, or P-point.
	
	What *do* you get?

It's in my previous message.

	Are you sure Ghostscript isn't doing some scaling of its own?
	
I've printed the files to check.

	> And I would have hoped that a serif font would get a serif font as 
	> substitute
	
	As I said above, you are free to put better mappings in place.
	
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.
If there is a better mapping used in 3.2, I'll be happy to patch my
Squeak 3.0.1 image to match.

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.



More information about the Squeak-dev mailing list