[BUG?] Postscript generation

Yoshiki Ohshima ohshima at is.titech.ac.jp
Thu Feb 24 09:50:18 UTC 2000


  Hi,

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

  Yes.

  If the bounding box is the only problem, is it possible to
calculate the width and height using PS font metric?  The PS
font metric (Helvetica, for instance) is same all over the
world?

  Anyway, I agree that more integrated and clean solution is
the way to go.

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

  Sorry again, but I was talking about completely "in
Squeak" problem for this one.  Just browse the method and
many other ones.

  Ok, I think I understand what is needed.  I believe
Display PostScript is one example to attack this problem,
and we need our way to attack the problem for implementing
WYSIWYG Squeak.

  -- Yoshiki





More information about the Squeak-dev mailing list