From: Andy Little (andy_at_[hidden])
Date: 2004-09-24 07:35:41
"Noah Stein" <noah_at_[hidden]> wrote in message
> > From: boost-bounces_at_[hidden]
> > On Behalf Of Andy Little
> > Yes..As I have touched in in a previous post this should be accessible
> > at the 'device layer'. OTOH Another way to look at a pixel is as a
> > rectangular box that is *currently*, *on this device*, (say) 0.25 mm
> > wide and 0.25mm high or whatever, the next layer up.
> What does "accessible at the device layer" mean in this context?
> A pixel is a fundamental unit in any graphics context. I don't think that
> an application programmer should be forced to jump through hoops to get
> at it.
In my current model it is available as (roughly) :
c.viewport.device.extent.x; // width of device in pixels
c.viewport.device.physical_size.x; // width in (usually) mm but...
//The actual units you use are up to you....
// (implicit conversion from mm to point):
= c.viewport.device.physical_size.x / c.viewport.device.extent.x;
//note: width could be a length typedef or its own type,
//which I am now thinking about.
> I fully support a unified rasterization model across output devices;
Not quite sure what that means.
> however, I don't think it should be achieved at the expense of the many
> programmers who will not use it because they do not need it. For the vast
> majority of UI programmers, the look of combo boxes and buttons on 1200
> dpi laser printers is irrelevant.
Hmm... so UI programmers arent at all concerned with explaining the UI to
Making the app look as good as possible on a wide range of platforms.
Trying to provide a uniform look and feel.
Avoiding making the user think in terms of pixels.
> The specification of certain quantities in pixels is necessary.
> When designing a graphics API, supporting high-quality output on a diverse
> set of devices is a large design issue. Text is very different on a
> monitor than on a high-res laser printer. Nice kerning is heavily
> by the dpi disparities, resulting in a whole host of issues. One major
> dissimilar line breaking. Inconsistent line breaks can have an enormous
> on presentation. At what resolution should kerning occur? What will
> pay the price: laser printers, monitors, or layout control?
These are the more interesting issues. I have only just started playing
about with units'n guis and havent delved too far into text, fonts and so
on. However text does as you say lead to interesting problems. It will be
interesting to see if it is easier to deal with text via pixels or units of
> I'm a big fan of types and units. I just think that pixels should be a
> readily accessible type.
They could be a 'runtime type', which you could interrogate to find the
current size of a pixel in (say) mm.
This would probably be useful in figuring out what fonts to recommend to
the user in a selection.
> I think it should be the default unit. Being
> American, there's nothing special about mm's. I like points more. Or
> maybe to just get everybody to think about it, the library could default
> to cubits. ;-)
Well... in my physical_quantities library you can use cubits if you wish.
If anybody knows what the scaling is between cubits and meters, I'll add it
BTW To those interested in the current status of pqs. I am working on the
next distro. But as always I find documentation a heavy slog. But I'm
getting there slowly. Hmm... discussing GUI's is so much more fun ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk