> From: Yoshiki Ohshima <ohshima at is.titech.ac.jp>

>   Suppose there is a short text in a TextMorph, and I resize
> the TextMorph as small as possible to enclose the entire
> text.  Then I generate the PS file.  I expect the resulting
> PS is something like
>
>   -----------
>   |test test|
>   -----------
>
> but what I get is
>
>   -------------
>   |test test  |
>   -------------

OK.  Are you sure it is the text box that is bigger, and not the  
text that is smaller?  The problem is that Squeak font metrics and  
Postscript font metrics do not match, even if the font is the same  
(it may have gotten mapped to something entirely different).

In Squeak, font metrics (such as character widths) are expressed in  
whole pixels, for the Postscript printer fonts they are floating  
point numbers.  If I were to use the screen font metrics in the  
Postscript output, text using the high quality built-in fonts would  
look really strange.  The only solution for now would be to download  
Squeak's bitmap fonts with the Postscript file and use those, but  
that would mean low-quality text output, comparable to a screen-shot.

An optimal solution employed by DTP programs is to always use  
printer metrics for overal line layout of text, even on screen, but  
use the screen metrics (integers) for character-spacing.  The  
difference is made up by adjusting inter-word spacing.

It would be nice if any re-working of the Squeak graphics engine  
were to take something like this into account.

> > >   * Related methods tend to not have spaces after the colons
> > >     of keyword methods.  Browsing them is quite tough:-)
> >
> > ?
>
>   For example, the definition of
> PostScriptCanvas>>fillColor: is
>
> fillColor:aColor
> 	self rect:clipRect; fill:aColor.
>
> not
>
> fillColor: aColor
> 	self rect: clipRect; fill: aColor.

This could be related to the problem above.  Additionally,  
tab-handling and other spacing tricks are not handled correctly by  
the Postscript context, because the way they are currently handled is  
tied very much to the MVC/BitBlt based text-handling primitives.   
Once these are overhauled for Morphic, text-handling for output  
should be easily adaptable.  Right now it would mean re-implementing  
most of the text-handling features, which is probably not a good  
idea.

Marcel