"Noah Stein" <noah@acm.org> wrote in message news:20040923095953.SM01616@enki...
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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) : Canvas c; 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): width::point_comp current_pixel_width = 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 the user? 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 affected by the dpi disparities, resulting in a whole host of issues. One major issue dissimilar line breaking. Inconsistent line breaks can have an enormous impact 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 measure.
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 in :-) 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 ;-) regards Andy Little