layout patch - transform handling needed

From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Mon Feb 17 2003 - 06:13:44 EST

  • Next message: Johnny Lee: "[PATCH] Fix bugs 3550, 3845 (win mousewheel bugs)"

    Hi Pat,

    Excellent, this is a major step forward, and I greatly appreciate all
    the work you have put into this -- just in case the following might
    suggest otherwise :). I have not had a chance to look at the code
    yet, but the message sparked a few thoughts.

    > ::getResolution() now returns
    > a constant 1440, while ::getDeviceResolution() returns something
    > consistent with the zoom. [The graphics class is exclusively
    > responsible for zoom scaling now.]

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

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

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

    The following is a pseudo-code outline of how the graphics class
    should be handling zoom (and anything to do with transforms we
    might want to do in the future):

    gr_Graphics::setTranform(transform)
    {
            system_set_transform(transform);
    }

    gr_Graphics::changeTranform(change)
    {
            new_transform = getTransform() + change;
            system_set_transform(new_transform);
    }

    gr_Graphics::zoom(z)
    {
            if(is_screen_context())
            {
                    changeTransform(z);
            }
    }

    editmethod_zoom(z)
    {
            pGR->zoom(z);
    }

    the drawing would then simply be done by

    drawChars(text, size)
    {
            device_size = tdu(size);
            system_draw_text(text, device_size);
    }

    This approach would ensure correct scaling of text between screen
    and printer once for all, and also remove the responsibility for
    making any zoom adujustments from the gr_Graphics draw
    functions.

    I have started working on the transforms a while back, and there is a
    very basic GR_Transform class and getTransform() and
    gr_Graphics::setTransform() functions in gr_Graphics.h. The
    tranform class needs some more methods, for now at least
    setScale(double s), and the the virtual gr_Graphics::_setTransform()
    needs to be implemented in platform code. Once this is done, the
    zoom edit method needs to be hooked in, and the zoom handling
    removed from the drawing functions, and that's basically it.

    Tomas



    This archive was generated by hypermail 2.1.4 : Mon Feb 17 2003 - 06:20:48 EST