Re: Text drawing bug - gaps after 16th character in scaled view

[Alexander Malmberg]

Pete French wrote:
> 
> > Then you would have many small gaps, so it wouldn't be as noticeable. It
> > would probably hurt performance, but I haven't done much benchmarking of
> > it.
> 
> It might be interesting to try - arre the cumulative errors cause by
> errors in the hints or rounding errors as it moves along the line ? If its
> the latter then maybe it could be fixed by moving to using doubles instead
> of floats ?

They are caused by differences between the width of the hinted metrics
and the width of the scaled outlines. Eg. if you have a glyph for 'A' at
10 points, the real outline might have an advancement of 4.2 points, and
the hinted outline might have an advancement 5 points. 16 'A':s in a row
would have a total width of 80 points. If you scale this up by 2, the
real outline would have an advancement of 8.4 points, which might be
hinted to 9 points.

Thus, drawing 16 'A':s in one PSshow calls will draw the glyphs across
16*9=154 points, but the layout information says that the 16th 'A'
starts at 5*16*2=160 points. Hence a gap (or overlap, depending on
whether the hinting made the glyph wider or narrower).

> I also notice that PSshow() does the correct thing - this is what I was using
> until this week, but as I want OSX portability I am moving away from it, which
> is proving a little fraught!

PSshow always uses the exact metrics of the glyphs it draws. It can do
this since it knows the exact sizes and fonts and ctms that are active.
The text system can't know what ctm you will use when you draw the text.

> I'd be interested to hear what other people do to get around this - I cant
> be the first person to actually try drawing text on the screen after all :-)

Well, most persons draw unscaled, unrotated text with integer sizes. :-)
Thus, the testing has been heavily biased.

> -bat.
> 
> PS: preseuably this is also the cause of other oddities - like missing the 
> last
> character of messages in alert panels,

I don't recall seeing this, and I haven't had any reports of it before.
What do I need to do to see it?

> or the missing of the last character of
> a name in an NSBrowser ? I see those quite regularly too.

It seems not to draw glyphs that would be partially clipped, which is
correct in some line wrapping modes. I'll have a closer look at it.


I've added automagic changing of usesScreenFonts to NSStringDrawing now,
so the drawing methods won't use screen fonts if you current ctm is
rotated or scaled (but note that -size always returns the size using
screen fonts). I've also fixed an inconsistency in the handling of
screen fonts with non-integer sizes in back-art.

- Alexander Malmberg