[diagrams] Attributes

[Ryan Yates]

On Thu, Nov 18, 2010 at 12:27 PM, Brent Yorgey <byorgey at seas.upenn.edu>wrote:
>
> Indeed!  I've thought about this too, and I had actually thought of
> having such a primitive called 'freeze' as well.  Given the type-based
> attribute framework we have, it also shouldn't be too hard to do
> selective freezing/thawing, although I guess it would require doing
> something funny like passing a dummy attribute of the desired type
> (whose value would be ignored!).  i.e.
>
>  freezeThingsLikeThis :: AttrClass a => a -> Diagram b -> Diagram b
>

Yeah.  I suppose that this brings up the topic of diagram query.  What would
be minimum to support the range of selectors that something like CSS has?


> One problem that arises is exactly what the semantics of transformable
> attributes would be.  For example, if you have a line width of 2 and
> apply a scale of 2 in the x-axis and 0.5 in the y-axis, what exactly
> should the new line width be??  For this reason I propose making
> attributes transformable simply by pairing them with an associated
> transformation.  The transformations can then be accumulated for
> frozen attributes (and ignored for non-frozen ones), leaving the final
> decision of how to interpret the transformation up to each backend.
> For example, I think Cairo can combine line drawing with actual
> transformations in such a way that the line will be thicker or thinner
> in various places depending on (say) a non-uniform scale -- precisely
> as you would expect for a "frozen" diagram.  But other backends might
> not be able to do this, and might settle for simply sampling the
> transformation to compute some sort of average scaling factor and use
> that to transform the line width.  And so on.
>

The postscript manual spends a lot of time talking about how the primitives
get rasterized and I haven't read the metapost book but I imagine it is
somewhat similar.  But I think we are looking for something that's more of a
happy middle ground where differences in backends is not too big a deal.
 Perhaps a starting point could be that given a diagram "d" we take "freeze
d" to be semantically the same as the functional raster representation:

f :: (BSpace v, Color c) => v -> c

I think any backend should be able to live up to that (aside from the normal
issues with rounding and anti-aliasing).


> I agree that options A and B seem like two points at the ends of a
> space of possibilities, but the above seems much too complicated to
> me...


I agree.


> One place I can think of where I would want something other
> than just options A or B is that sometimes when scaling a diagram,
> keeping the same absolute line width looks bad (because it gets too
> thick or thin relative to the overall diagram), but scaling the line
> width by the same amount as the diagram looks bad too! (because
> e.g. it gets so thin it can hardly be seen).


Right.  In the CAD software that I work with I often find it useful to put
bounds on line widths.  When you zoom out the lines have a minimum width so
they can still be seen, when you zoom in the line thickness matches the
accuracy of the tool the line represents.  If the tool accuracy changes with
relation to curvature, for instance, it would be nice to not have just a
minimum, but show a "relative" difference once the minimum is hit.  The same
goes for plotting equations.  What I really care about is not the single
value that happened to be calculated, but instead the margin of error around
that point as a line thickness.  This gives a way to have real meaning to
plots as opposed to the normal lies that graphing calculators give.  It
would be nice to still be able to represent these kind of things as lines or
curves instead of as polygons.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.haskell.org/pipermail/diagrams/attachments/20101119/7dcac697/attachment.htm