At 01:09 PM 11/23/2004 +0000, Ian Hickson wrote:
>On Wed, 10 Nov 2004, Peter Sorotokin wrote:
> > >
> > > It seems like the simplest way to do this would be to use a new unit,
> > > one that didn't scale with the zoom.
> >
> > Yes, we certainly tried that (in pre 1.0 drafts CSS units did not
> > scale). It kind of works for uniform scale, but if x and y scale factors
> > are different it breaks down. In graphs people typically scale the
> > coordinate space to work in their units and scale is typically
> > non-uniform. And what about non-scaled fill patterns?
>
>Could you expand on these problems? I'm not sure I follow. What would the
>problem be with x and y scale factors being different, if the unit simply
>doesn't scale at all?
The way stroke works is that the stroke outline is being calculated in the
user space and then it is transformed from the user space to the device
space. So stroke ends up being thicker (and it can be dramatically thicker)
in some places.
> > > > - there is a need to assign multiple strokes and fills to an object
> > > > (drawing tools had this for long time)
> > >
> > > This could be done in the same way that the CSS working group is
> > > handling multiple backgrounds on elements, namely, let the 'fill' and
> > > 'stroke' properties take multiple comma-separated values.
> >
> > That was certainly one of the ideas WG members had as well. It works for
> > fill, but stroke is not controlled purely by stroke property. Typically
> > one wants to change either stroke-width or stroke-dash-array as well.
>
>Allowing those properties to take multiple values as well would address
>this (and is how 'background' is being handled in CSS).
It would be a very dirty solution (implicit correspondence between value
lists - if I guessed what is you proposing there) which is hard to use in
dynamic environments. It was floated, but I do not think anyone in the WG
liked it.
Peter
>[snip]