From: Noah Stein (noah_at_[hidden])
Date: 2004-09-23 11:59:37
> From: boost-bounces_at_[hidden] [mailto: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
> box that is *currently*, *on this device*, (say) 0.25 mm wide and 0.25 mm
> 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.
> Obviously you ultimately need pixels on a particular device, but what do
> do when you want to render the drawing that you have drawn (or your
> on a 640x480 pixel diplay on a 1200 dpi laser-printer?. Usually you have
> interrogate the system to find out its current pixel 'metric', and convert
> all your pixels on the display into some number of pixels on the printer.
> am just abstracting this process. The problem with pixels is that they can
> unless you work extremely hard, lock you firmly into one device. So
> *whenever possible* I would prefer not to deal with them directly.
I fully support a unified rasterization model across output devices;
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. 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?
> Of course graphics programming has since time immemmorial used pixels, so
> may appear that I am 'pulling away the floor from under you'. I would
> it to assembler programmers who see their freedom being taken away when
> forced to use 'types'. Its a different way of looking at things which
> be useful sometimes, so takes time to get used to.
Since time immemorial, computer science has used algorithms, and I don't
think we're getting rid of them anytime soon. :-D
I'm a big fan of types and units. I just think that pixels should be a
readily accessible type. 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk