Device Independent Squeak Imaging (Re: Real printing plugin?)

Marcel Weiher marcel at metaobject.com
Fri Mar 29 12:37:37 UTC 2002


On Thursday, March 28, 2002, at 07:42 AM, John M McIntosh wrote:

> Mmm I've been watch this discussion with some interest and I guess I 
> add a few points.
>
> 1) I bet on the mac people think Squeak works in 72 dpi
> 2) I bet on windows people think Squeak works in 96 dpi
>
> Squeak isn't resolution dependent.

Shouldn't that say:  "Squeak isn't resolution *in*dependent?"  Meaning 
that it specifies sizes in pixels, meaning that the actual image-size 
depends on the resolution.

[reasons]

> So really if there is a scaling problem, it's more likely you need to 
> ask the user what he thinks the resolution is, then deal with it via 
> Smalltalk code.

 From years of working with device-independent imaging models, I'd think 
the first thing you'd have to do is assign a meaning to units of size in 
Squeak that does not depend on pixels.  An obvious candidate for this is 
the "Postscript point", which is defined to be precisely 1/72 of an inch.

Once you've defined what Squeak means with a certain size, you can then 
translate it to other units, such as pixels on a display screen.

Without this step of defining the meaning of Squeak size units, I don't 
see how you can possibly do any translation (from what?).

If you keep the units as 'screen pixels' and translate that back to 
physical dimensions, you lose the ability to actually do portable paper 
documents.  Here's why:  let's say you've done a paper called "Back to 
the Future" in a Bookmorph.  You wrote this on a Mac with 72 dpi display 
and made it fit a Letter page.  Now if you were to print this on a 
Windows box with 96 dpi, it would be scaled down significantly on the 
page.  The other way around would be even worse, because a paper done on 
a 96dpi system would not fit on the page when printed from a 72 dpi 
system.

Also, I would like to point out that scaling objects to maintain 
physical dimensions on monitors is, at present, highly unusual and 
probably unexpected behavior.  I am not aware of any operating system 
that actually does it as a matter of course.  Even ones that probably 
could do it reasonably well (Mac OS X's pervasive anti-aliasing makes it 
a good candidate) do not.

The usual (and expected) behavior when you increase monitor resolution 
is that objects get smaller and your screen real-estate increases, not 
that objects stay the same size but become better defined.  It is also 
very often the desired behavior:  when I inrease the resolution on my 
17" monitor, I expect to get more screen real-estate.

This situation is bound to change as high-definition LCDs ( 150dpi+ all 
the way to 300dpi) start becoming more common, but we aren't there yet.

> Writing this support into the VM, although it's been mentioned as 
> *easy* might not be as straight forward as you think.
>
> a) Mac system 7.5.5 thru OS 10.1.3 have different viewpoints on the 
> ability and how to get at this stuff.
> b) It's C code that only a few of us work on.
> c) Vendors make unpleasant changes in the API, or introduce bugs.

What exactly are the VM changes you are suggesting?  Detecting screen 
resolution?  Or something more comprehensive?  To me that sounds a bit 
more involved...

> Therefore tackling the issue just requires a bunch of programming, 
> hopefully in Smalltalk. I wouldn't consider it difficult, but since I 
> don't need it, then well it's doubtful I'd do it, unless someone twists 
> my arm, but then who will do the windows work?



> I'll note of course the thread title was really on macintosh printing 
> via forms, the reason I choose that is because many printers don't 
> support postscript and this was a way to enable printing without having 
> to deal with correct postscript generation, which is at the heart of 
> this issue.

'Correct' Postscript generation is difficult only because the Squeak 
imaging model is completely screen/pixel oriented.

> If you need postscript printing it would seem there is lots of work to 
> do to make it work.

Huh?  All you need to do is take the generated Postscript and dump it to 
the respective printer.

>  Also enabling it so that you can do proper postscript escape work 
> within the macintosh printing architecture would be nice too.

?

I think making Squeak's base imaging model device-independent is a 
worthwhile task and would gladly contribute to it.  Once that is in 
place, issues such as adjusting for display resolution and printing 
become pretty straightforward.

Regards,

Marcel


--
Marcel Weiher				Metaobject Software Technologies
marcel at metaobject.com		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.




More information about the Squeak-dev mailing list