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

[Pete French]

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

I think I understand whats going on now - basically the problem is that the
layout system has to assume that the hints scale "properly" whereas in
actual fact they dont have to, and it has no access to the actual hinting
information which will be used right ?

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

...because its assuming that because the hint for the 4.2 'A' was 5 then
the scaled version will have a hint for an 8.4 'A' of 10.

> Well, most persons draw unscaled, unrotated text with integer sizes. :-)

Peseumably because most text is drawn using the text objects in the GUI
rather than directly as I am doing. This problemt only rears its head
for people trying to draw diagrams really doesnt it ? Thats where my
problems come from - I am drawing plots of antennae, cross-sectional
profiles of maps, verctor bearings etc, etc - and then trying to lable
these in an intelligent (and readable) way.

here is a thought - if tthe text system positioned it glyph by glyph then
you wouldnt get the huge gaps as the errors would be spread across the
whole line of text. But, as you said, this might cause performance
problems. Would it be possible to detect whether or not the ctm is scaled
or rtated, and (if so) reduce the "chunk" size from 16 to 1, just in that
case. That would give you no slowdown for the text that most people draw,
whilst still fixing the problem for those of us who want to draw diagrams.
given the amount of text on a diagram is usually failry small then the
performance hit shouldnt be an issue.

[this is assuming it cant be fixed by getting the actiual sccaled hint
information, which I gather isnt posssible from your comments]

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

I'll make up a test-case for you that demonstrates it. I see it when
using alert panels to pop-up error messages from things. Its a very
specific errror message which shows it up, I'll try and reproduce it at work
tomorrow.

> 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 can easily dig out some code to show the NSBrowser problem too if I can.
Again, as its data dependent then I'll have to run an app until I see it
and try and extract the necessaries.

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

That actually looks a whole lot better. But having thouhgt about it some
more I think it might be better to stick with the screen fonts and go
for the positioning of each glyph idea maybe ? Would that be difficult
to implement just to try out ? I can do some benchmarking to see what
happens....

thanks for the help so far,

-bat.