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 _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep