From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Tue Feb 18 2003 - 12:08:15 EST
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
This archive was generated by hypermail 2.1.4 : Tue Feb 18 2003 - 12:15:24 EST