Re: layout patch - transform handling needed

From: Patrick Lam (plam@plam.lcs.mit.edu)
Date: Mon Feb 17 2003 - 11:36:54 EST

  • Next message: Mark Gilbert: "RE: I can't build from source. Could anybody help?"

    Hi Tomas,

    I was in a bit of a rush when explaining things, so I may have given
    the wrong description of changes.

    On Mon, Feb 17, 2003 at 11:13:44AM -0000, Tomas Frydrych wrote:
    >
    > ::getDeviceResolution handling the zoom is not right; device
    > resolution is a constant that has nothing to do with zoom, and doing
    > the zoom by pretending that the device resolution has changed is a
    > potential source of layout bugs similar to those we experienced in

    As dom explained, my explanation wasn't quite correct wrt actual code
    implemented. In any case, no one's supposed to call
    ::getDeviceResolution. If anything, you're only supposed to call
    ::getResolution.

    Note that getDeviceResolution() is only used once, for images. The
    original intent was to make it protected, but that can't happen unless
    we can come up with a story for images. I'll put it on my todo list.

    > the past. What we need, is to have proper transform functions in the
    > gr_Graphics class and zoom by changing the scaling factor of the
    > transform. Then the draw functions do not need to do any internal
    > conversions due to zoom (see pseudo code below).

    ::tdu and ::tlu are virtual-transform functions that use the zoom
    percentage to transform the layout units they are given into device
    units. The end result is that the code for ::drawChars() is just as
    you propose.

    > > Finally, we did some work on fixing up fonts in Unix (where xft is
    > > mandatory now). What we wanted was to get two fonts, one
    > > corresponding to the current zoom, and one for 1440dpi,
    >
    > This is again not right; we should get the font for the 1440 dpi only,
    > and for screen processing tell the system to apply a tranform to it
    > (which would include the zoom scaling factor). Under xft this should
    > not be too difficult, since FT2 has a neat transform handling
    > mechanism.

    Yes, well, if you could tell me how to get a 1440dpi font from
    FontConfig, we'd be much obliged. For us, FC was rather stubborn
    and uncooperative.

    > > ::drawGlyph needs to draw a font at ::getDeviceResolution (you may
    > > find it easier to request a 'screen font' of the appropriate size
    > > multiplied by getZoomPercentage()).
    >
    > Again, this is not right. In particular, requesting screen font at
    > real_size = size*zoom results in incorrect scaling (because font
    > metric does not scale linearly with size). This seems to me to be
    > precisely what we have done in the past, and what does not work.

    Currently, we are using two fonts. One font should be at 1440dpi (we
    can't actually get this to be the case), but the important thing is that
    it is independent of zoom -- it never changes. This font is not drawn,
    only measured. On the other hand, we have a font that's size * zoom.
    This font is never measured, only drawn. We use Xft to make sure that
    the placement of chars is as if it was the canonical font.

    Because of the way FontConfig is giving us fonts, we seem to be unable
    to get away with anything but size * zoom in terms of getting glyphs to
    be drawn on the screen. I think that's OK, because we never measure the
    drawn font.

    If you try the code that's committed, you'll see that it does the right
    thing, something we've been unable to do in the past. In particular,
    it passes the 'l' test, where you put a bunch of l's interleaved with
    spaces, and hope that everything linebreaks OK. This does not change
    when you change the zoom, and I don't think it changes when you print either.

    pat



    This archive was generated by hypermail 2.1.4 : Mon Feb 17 2003 - 11:41:34 EST