Hi Pat, I have been using the term 'transform' in a fairly narrow sense, as a reference to a 3x3 matrix that defines a transformation that is applied to user space before things are output to the device (the PS docs on Adobe website have quite a good intro to this; PLRM.pdf, section 4.3). This allows much more generic transformations to be handled than proportionate scaling, and it is the way go.
> > 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. This is precisely what I am concerned about: the zoom factor being used to scale the device units. This is not right because it leaves us with the problem that 8pt font at 500% zoom will result in requesting a 40pt font from the system. Metrics for 40pt font can be substantially (non-lineary) different from that for an 8pt font. The correct thing to do is to request an 8pt font from the system but tell it to scale it 5 times when rendering on the device. This is done by defining a transform that is to be used on the device, and there is no other way that this can be accomplished. > 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. I do not doubt this is a major improvement. Tomas
