discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Slight problem w/ fonts


From: Fred Kiefer
Subject: Re: Slight problem w/ fonts
Date: Sun, 06 Jan 2002 23:48:23 +0100

Jeff Teunissen wrote:
> 
> Gregory Casamento wrote:
> >
> > I am having a bit of trouble w/ GSFontAntiAlias after my latest update.
> > It seems as though the fonts are being rendered about 2 times larger
> > than normal.
> 
> The graphic shows that your fonts are being rendered to their point size
> instead of their size in pixels, which is how GNUstep (incorrectly) used to
> handle fonts.
> 
> pixelSize = round (pointSize * (dpi * (1/72)))
> 
> On X, typically, the pixel size and the point size are _almost_ the same.
> That's because the default configuration sets a DPI of 75, and a point is one
> seventy-secondth of an inch., approximately 0.01389 inches. On a 75DPI screen,
> a 10-point font is approximately 10.4167 pixels in height, rounded down to 10.
> 
> However, most displays in recent years are no longer 75DPI. On my system,
> which is calibrated to 100 DPI, the same 10-point font should be 13.8889
> pixels in height, rounded up to 14.
> 
> There is a bug somewhere in the code, in that the font ascent (maximum
> distance from the baseline to the top of a glyph in the font) and descent
> (maximum distance from the baseline to the bottom of a glyph in the font) are
> causing problems with clipping. The glyphs shouldn't have their tops hacked
> off like that. I think that perhaps the baseline isn't being positioned
> correctly, because the ascender and descender code seems to look right.
> 
> I found that this bug existed when I switched GNUstep to use point sizes
> instead of pixel sizes, but I wasn't able to find the cause of it.

Thank you Jeff for the good explanation of pixel and point sizes. So now
all of us should accept that the changes I did make here were needed and
mostly correct. But what is causing the new strange behaviour is not
just simply a bug somewhere in the way we compute sizes for strings. Our
problem is that in GNUstep we don't care about the transition from an
abstract font to the screen display. 
I think that for the NSFont object all the measures should be in points,
as this is the natural measure for a font. But what measures should
methods like [NSString sizeWithAttributes:] and [NSAttributesString
size] return?
Should they work in the destination coordinate system or at least in the
context resolution? So for the screen we could expect them to return
pixels?
The OpenStep specification is not clear on this and we will have to
decide about our own solution here.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]