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
