Re: Font, layout units et al.

From: Joaquín Cuenca Abela (
Date: Mon May 27 2002 - 16:26:15 EDT

  • Next message: Pierre Abbat: "Re: de-De.strings file (fwd)"

    On Fri, 2002-05-24 at 18:46, Tomas Frydrych wrote:
    > Hi guys,
    > > > take in account that I want to extract the *linear*
    > > > metrics of the font. Ie, before the hinter touch the
    > > > glyph, and before it's scaled down.
    > > >
    > > > I have this field in my debug code in Xft, and I'm
    > > > seeing the right float value (as if it was with layout
    > > > precision) extracted from a font at 12 points
    > > > (freetype gives us this field).
    > This is not right and is not going to work. You need to extract the
    > metrics _after_ the hinter processes the glyph because the final
    > call to the drawing routines, whether the on screen graphics or the
    > PS interpreter, is going to use the proper, i.e., hinted, metrics and
    > hinted glyphs. If you do your calculations with unhinted metrics the
    > real hinted character drawn on the screen could be noticeably
    > wider than the slot you allocated for it, and if you advance by the
    > unhinted width it will be covered by the next character (we get this
    > very problem in the PS output).

    I'm not 100% sure Tomas, but I've always heard of "hinting" like the
    "grid-fitting" process.

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

    Am I missing something?

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

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


    Joaquín Cuenca Abela

    This archive was generated by hypermail 2.1.4 : Mon May 27 2002 - 16:26:54 EDT