Re: Font, layout units et al.

From: Tomas Frydrych (
Date: Tue May 28 2002 - 11:44:23 EDT

  • Next message: Tomas Frydrych: "Re: screenshot of ugly fonts"

    Hi Joaquin,

    > Ie, the non-linear scaling factor introduced by grid-fitting is only due
    > to rounding errors (visible when we pass from high-resolution to
    > low-resolution).
    > 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.


    ********************************************* /
    PGP keys:

    This archive was generated by hypermail 2.1.4 : Tue May 28 2002 - 11:49:45 EDT