From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-21 05:44:44
> * Aaron W. LaFramboise <aaronrabiddog51_at_[hidden]> [2004-12-16 23:18]:
>>Andy Little wrote:
>>>"John Torjo" <john.lists_at_[hidden]> wrote
>>>>As a side-node, I'm moderately against having float coordinates. Why would
>>>>you think int is not enough?
>>>A more complete framework would have UDT's rather than ints, representing
>>>pixels, as well as other types representing inches, millimetres as used in
>>>(say) CSS and (I think) SVG etc, which would allow automatic conversion
>>>(runtime for pixels) of one measure to another. It would also allow precise
>>>control over the semantics of converting.
>>I think the decision on the representation of coordinates is an
>>extremely important one--one that might doom a library to ultimate
>>obsoletion if decided wrongly. As Boost is meant to be a model of _the
>>C++ way_, future libraries may also be inclined to specify in the manner
>>Boost does. It's very important to remain forward-looking, thinking
>>not, "What sort of pixel representation do today's GUIs use?" but rather
>>"Will tomorrow's GUI be based on pixels?"
> What about todays printer? Is that based on pixels?
Printers are based on "dots per inch", e.g. a 600dpi printer. These dots
can be seen as pixels, but the CSS documentation has information about
converting screen pixels to other devices (e.g. printers) such that a
pixel consists of 3 dots on a 300dpi printer and 5 dots on a 600dpi printer.
> If I were to go to the trouble to create an GUI that rendered
> diagrams, I'd probably to to the touble to print those diagrams.
> I'd like to use the same algorithm to render to the screen and
> to the printer, simply swap out the device context.
The Microsoft MFC library takes this approach and, IMHO, it is the best
way to go. The problem is that with the MFC:
* conversion between "metric spaces" (inches, pixels, picas) is not
handled by the library, making it hard to say "draw a circle at (2in,
3.7in) with a radius of 2cm".
* the way the library manages graphical objects and selecting a
graphical object on a canvas is *way* off base!
Anyway, I have started work on a metric type, available in the latest
Be warned, though, that this is experimental. It provides conversion
between the types that are directly convertable (e.g. points to inches).
I have yet to work out how to properly handle conversions between the
base types (pixels, inches and scalefactor). In principle, this is easy,
* ppi: pixels per inch
* max: maximum length of the object to which the metric value is bound
pixels = inches * ppi = scale * max:px = scale * max:in * ppi
inches = pixels / ppi = scale * max:in = scale * max:px / ppi
scale = ?
These values are dependant on the device being targetted. They are also
dependant on the orientation of the metric (x-axis or y-axis). So how do
we resolve the metric values?
The best solution I can see is have a resolve_metric function on a
device, such that:
metric device::resolve_metric( metric, type, orientation );
it takes the metric and returns that metric with the units specified by
type given the orientation. For example:
p.x = dev.resolve_metric( p.x, metric::pixels, device::x_axis );
p.y = dev.resolve_metric( p.y, metric::pixels, device::y_axis );
This will convert the point p into pixels for the device specified by
dev. Helper functions should be included to convert points, sizes and
dev.resolve( val, metric::pixels, device::x_axis ); // metric
dev.resolve( pt, metric::pixels ); // point
dev.resolve( sz, metric::pixels ); // size
dev.resolve( rc, metric::pixels ); // rect
So, why the term device? A device (screen, printer, etc.) is an object
that can perform graphical operations that render graphical content to
it. The device can be queried for information relating to it (e.g. the
size of a block of text or the number of pixels per inch along the
y-axis). A canvas is an area that can be drawn on.
It is possible to get a canvas for a device (allowing you to, for
example, send a graphical image to a printer). Likewise, it is possible
to get the device associated with the canvas (allowing you to perform
The library update also includes some experimental work on basic
graphics components (font) that I am using to compute the size of
several widgets. The idea being that this can be plugged into a layout
manager. The flow layout *does not work* at the moment and the whole
layout mechanism may be subject to change.
However, the widgets are fairly stable and usable. I have included
buttons (push, checked (2 and 3 state), radio button/group), labels,
textbox (textfield, textarea and password), along with a calendar widget
that is MS-specific (I think). I intend on supporting a table control
like the Java JTable component, with a TableModel-style interface.
The link to the code is: http://uk.geocities.com/msclrhd/gui/gui.zip
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk