Andy Little wrote:
"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
For fonts, won't you use a wrapper over existing OS-primitives? Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)