From: Tomas Frydrych (firstname.lastname@example.org)
Date: Tue May 28 2002 - 11:44:23 EDT
> Ie, the non-linear scaling factor introduced by grid-fitting is only due
> to rounding errors (visible when we pass from high-resolution to
> The non-scaling factor that you're speaking about here is due to the
> changes that each glyph suffers when it goes from a high size to a low
> size, even when you keep it at high resolution (usually making the
> characters wider to make them more easily readable).
I am no expert on these things at all, but Leonard is, so it is worth
seeking his comments on whatever way we decide to handle this. I
have struggled with this whole problem on Win32 about 6 months
back, and I have observed then that the discrepancies between the
layout and screen metrics cannot be explained as the result of
rounding errors, the differences are way to big and vary from glyph
to glyph -- they can only be reasonably explained as the result of
seriously non-linear scaling of the glyphs widths according to a non-
linear algorithm which is built into the font.
> I was only speaking, as you point out, of the metrics extracted from the
> font at 12 points (ie, the real physical size) at high resolution,
> scaled down to the resolution of the screen.
OK, I misunderstood that. That's what I have been on about.
> > The real answer to our problem is _not_ to request fonts at
> > incorrect physical sizes as we do at moment. Instead of scaling
> > the physical font size from say 12 to 240 points (72 -> 1440 dpi)
> > we have to request a font of 12 points but tell the rasterizer to apply
> > a transform of 1 point to 20 device uints. With FreeType this is
> > done by call to FT_Set_Transform(). I think if we do this then we
> > will not need to advance by characters to fix this
> I don't understand that. Why that will help us to draw each character
> at the right position?
I can only speak for the win32 situation, but there the regular calls
to the drawing API draw the characters at the right position as the
font author intended. The problems we are having are of our own
making, caused by the fact that we use incorrect metric to do
_our_ layout calculations. So if we stop doing that, the screen
output will correspond to what we assume it will be. The basic
problem we have is the assumption that 240pt at 72 dpi will give us
glyph shape identicall to 12pt at 1440 dpi; it does not. The removal
of this assumption has to be the first step in fixing the problem.
When we do this, only then it makes sense to talk about more
precise ways of doing the layout, if the results are still not to our
liking, but I suspect that they precission should be entirely
I also think that we have to explicitely request the metrics from the
rasterizer for 12pt at 72 dpi and for 12pt at 1440 dpi. I do not think
that requesting just the metrics for 12pt at 1400 dpi and then
scaling it ourselves down 20 times is a good idea; if we let the
rasterizer to do the scaling, we will have a guarantee that the
rounding errors that will affect the drawing will be the same as the
rounding errors in our metrics. If we scale it ourselves, we could
(will?) again end up with incorrect metrics.
> > (which I am pretty
> > certain would result in in a very poor drawing performance).
> ??? Why? The layout code will not draw each character individually,
> but drawChars will draw the whole string taking in account high-res
> metrics. And drawChars will draw the whole string in a single operation
> (as now).
My appologies, I must have misunderstood what Martin and you
were talking about -- I thought you meant to draw each character
individually by a separate call to the system API.
email@example.com / www.frydrych.net
PGP keys: http://www.frydrych.net/contact.html
This archive was generated by hypermail 2.1.4 : Tue May 28 2002 - 11:49:45 EDT