From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-22 07:14:22
* Reece Dunn <msclrhd_at_[hidden]> [2004-12-22 06:42]:
> Alan Gutierrez wrote:
> >* Reece Dunn <msclrhd_at_[hidden]> [2004-12-22 05:22]:
> >>Hi All,
> >>In the "thoughts on a GUI component library" thread there have been
> >>various discussions about the layout of a rectangle and come relating to
> >>CSS. Note that point and size are stable.
> >>The CSS3 Values and Units module
> >>(http://www.w3.org/TR/2001/WD-css3-values-20010713/) defines various
> >>units (e.g. inches, picas and em). This is a good basis for a GUI
> >>library metric type. The type should store the values as a floating
> >>point to allow things like 2.71cm and also to support platforms that
> >>store coordinates as floating points (e.g. Cocoa).
> >>The CSS3 relative values (em and ex) are dependant on the inherited
> >>font-size property, so it is difficult to use these units as there is no
> >>associated font-size property. Another issue relating to this is how to
> >>resolve metric values between units that are not directly convertable. I
> >>have suggested using a device::resolve method that takes metric, point,
> >>size and rect types, but it may not always be possible to get access to
> >>a device.
> > Maybe, in this sense, a font is a "device" that can resolve?
> Maybe what would be better is a css_device, since this would allow
> font-size property inheriting and resolution of the em unit. It should
> therefore be possible to extend/override the default resolution
> behaviour for a device:
> struct device
> virtual metric resolve_unit( metric v, metric::type t, orientation o );
> inline point resolve( const point & p, metric::type t )
> return point
> resolve_unit( p.x, t, orientation::x_axis ),
> resolve_unit( p.y, t, orientation::y_axis )
> // similar resolve method for size and rect
> Therefore the css_device would override the resolve_unit method.
Would the css_device be implemented as a device decorator?
-- Alan Gutierrez - alan_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk