[cairo] Re: Cairo font size should be in units

[Owen Taylor]

On Wed, 2004-09-29 at 15:46 -0400, Carl Worth wrote:
> On Wed, 29 Sep 2004 15:16:43 -0400, Owen Taylor wrote:
> > On Tue, 2004-09-28 at 18:49 -0700, Bill Spitzak wrote:
> > > On Tuesday 28 September 2004 06:25 pm, graydon hoare wrote:
> > >
> > > > well, no, actually that's not true; cairo builds its CTM in terms of
> > > > physics. when you start up a cairo program, you have no reason to believe
> > > > that 1 user unit == 1 pixel. if you want that to be true, the first thing
> > > > you need to do is ask about DPI and reverse the physics-based
> > > > transformation. cairo's supposed to support writing
> > > > (semi)resolution-independent clients, after all.
> > 
> > I consider this a misfeature of Cairo:
> 
> I should point out that Graydon's description of the default CTM in
> cairo is missing one important aspect. For display-devices[*], the
> default CTM is computed by computing 1 unit == 1/96 inch, and then
> rounding that to the nearest pixel size.

I think I've characterized this in previous mail as a nasty suprise
awaiting developers as soon as the first user's screen goes above
the threshold for 2-pixels-per-unit.

> >  - Pixels matter at screen resolutions
> 
> Absolutely. That's why we did the rounding described above. This way, by
> default, integer user-space units map to integer numbers of device-space
> pixels.

But in the two-pixels-per-unit world, do people really only want 
2 and 4 pixels, or do they also want 3 pixels?

> >  - People who work in pixel coordinates should have an easily accessible
> >    "base length" - something other than reverse-engineering the
> >    CTM of the default transformation.
> 
> What do mean by "base length" exactly? And how easily accessible do you
> want it? Is a single call to cairo_transform_point good enough? Or do
> you really want a literal value for your code?

It's a pretty fuzzy concept. But you might imagine that a program might
work with two yardsticks:

 - A "shadow thickness" (GtkStyle has xthickness, ythickness fields)
 - Font size; a good metric for padding, icon sizes, so forth.

> I'm not sure exactly what you're getting at here, but I am prepared to
> argue that the CTM as currently constructed helps to reduce the
> situations in which this base length would be needed.

You can perhaps use it to eliminate one of the above "yardsticks", but
I don't think you actually simplify things, because the user then
has to worry about the other in both pixels and "default CTM units".

> > So, say I have a 100dpi screen that I sit 3 feet from and like 12-pixel
> > fonts and 1-pixel lines. You sit at the same distance from your 150dpi
> > monitor. and like 18-pixel fonts. Do you want 1.5 pixel lines?
> 
> Perhaps not, but how about 2 pixel lines? And the cairo CTM certainly
> isn't the only way to adjust the scale. I anticipate that programs will
> continue to allow the user to choose a preferred font size.

What I'm saying is that that a single matrix can't simultaneously handle
quantities that jump from 1 to 2 and quantities that need to vary more
or less continuously. I don't think putting the burden of device 
independence on the default CTM works. If we were in a realm where
the average line width was 4-5 pixels, it might be OK, but we are still
in the 1-2 pixel world.

So, since varying the default CTM isn't sufficient, I don't see it as
being useful either. Instead of a panacea, it's just one more thing
to worry about.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20040929/3a680242/attachment.pgp