Lofton,
I think the only useful properties in
Stuart’s table needed to support script-based DOM manipulation of Style
Properties, or through a declarative animation are LETF, LTIO and LT, with this
I can support flow, directional flow and change of levels in a container. The
other requirements are transform, pan, zoom and some type redrawing hints. (no
redraw, full redraw, redraw apps that have changed).
We do not support LTIO but would be simple
to add.
We have customers that use markers, but
never in a Web environment.
Regards,
Forrest
From: Lofton Henderson
[mailto:lofton@rockynet.com]
Sent: Monday, October 08, 2007
4:25 PM
To: Bezaire, Benoit;
cgmo-webcgm@lists.oasis-open.org
Subject: Re: [cgmo-webcgm]
Comments on Style attributes [2 of 2]
[...part 2 of 2...]
Benoit et al --
Here are my more detailed thoughts from reading Benoit's comments on Stuart's
table.
This gets pretty dense and technical, so perhaps it can be filed till later --
per previous messages, it is probably not necessary to answer these details for
a workable, first-order requirements document. But since the comments are
raised already, I'll send them along (file 'em for future reference if you
like)...
Line Type (LT) and Line Type Initial Offset (LTIO): As Benoit said,
"LT...could be used to show flow". For example, for a discrete
step-animation one could cycle repetitively through three line types, where the
2nd and 3rd are 33% and 66% offset versions of the 1st:
1-2-3-1-2-3... But the exact same thing is achieved with the LTIO
attribute, applied repetitively in three successive amounts (0, 1/3, 2/3, 0,
1/3, ...) to a single line type.
(I think this is achievable either through script-based DOM manipulation of
Style Properties, or through a declarative animation -- a separate question.)
Looking at his question, "Useful, but unclear, hard to implement."
about LTIO ... I went looking for a test of LTIO in the test suite, without
luck. I thought even remembered what such a test looked like but I only
find LINSTD01, 02, and 03, and none of them seem to test it.
Benoit asks about Fill Reference Point (FRP), "remove...Isn't changing the
pattern/hatch enough?" This is exactly analogous to LT and
LTIO. You could, for example, crudely simulate a flow through a fat pipe
by cycling repetitively through three hatch styles, each of which was spatially
offset 1/3 from the previous one. The exact same effect could be achieved
using only a single hatch style, and cycling the FRP repetitively through three
locations (0, 1/3, 2/3, 0, 1/3, ... of the defined hatch size).
I believe that cycling the LTIO and cycling the FRP are conceptually
simpler. But I'd like to hear more thoughts, especially from implementors
(vendors) about difficulty.
A couple of related notes....
LETD. Stuart's table say "no" to Line & Edge Type
Definition (LETD). This would mean that LT can only be changed to one of
the positive values, 1..5 of CGM:1999 or the registered 6..15 of WebCGM (and
ATA, etc). Or to a negative index value that happens to be already
defined within the metafile instance by LETD element(s). So to simulate
flow via line style, I think one of 4 cases would be necessary:
either 1.) a few line types that are progressive spatial offsets of an initial
one are already defined in the metafile instance via LETD, and you repetitively
cycle through the index values (negative indices);
or 2.) LTIO is allowed as a DOM Style Property, and is defined as applying to
1..5 and 6..14 as well (which latter is currently dubious or at least
questionable);
or 3.) LTIO is allowed as a DOM Style Property and the target line type has
already been defined in the metafile instance via LETD;
or 4.) LETD and LTIO are both allowed as a DOM Style Property. In this
case, a LETD-like Style Property (e.g., "stroke-type-definition")
would function like any other Style Property -- it would set the style for all
lines and visible edges in the object.
Conclusion: I'm thinking that including LETD as well as LTIO in the Style
Properties opens up more efficient and flexible options for the target use
case(s). (Vendors should comment on difficulty.)
HSD (Hatch Style Definition). Stuart's table says "no".
Same situation with the line style.
Combining Line and Edge attributes. Note that so far, we have combined
Line and Edge attributes in Style Properties: stroke-weight and
stroke-color. Presumably we would continue that: stroke-type or
stroke-style or stroke-whatever-we-call-it, yes?
Summary. Some of this detail might be premature to consider, but it
doesn't hurt to be aware that it's lurking. What is critical now is to
decide at least at the level, "yes ... we do want some additional line
attributes as Style Properties to support use cases such as simulation of
flow". (Or "no ... we don't ..." -- Benoit prefers that
our effort should instead be spent on animation-along-path and transparency
animation.)
If we endorse additional line/edge Style Properties, and have clear agreement
on which of LT, LETD, and LTIO we want to support, so much the better.
But that level of decision could, in worst case, wait until the design stage of
2.1 functionality.
All for now,
-Lofton.
At 11:43 AM 10/4/2007 -0400, Bezaire, Benoit wrote:
Hi All,
Here
is my feedback on the Style attributes document:
http://www.oasis-open.org/committees/download.php/25270/Attributes_Table.pdf
I
can't speak for other implementers, but exposing all those attributes in a DOM
interface or declarative animation is a lot of work. Why not try and narrow down
the list? So far, I just don't see how a good number of the attributes help us
achieve our list of requirements. I think some examples would help me a lot.
Now this is just off the top of my head, but I think that a number of suggested
animatable styles require a lot of development work (for our viewer). In the
table below, I list my own preference:
Stuart's
suggestion
Benoit's suggestions Comments
Line
Type
Ok
Could be used to show flow
Line
Cap
remove
Isn't line type sufficient?
Line
Join
remove
Isn't line type sufficient?
Line
Type Continuation
remove
Isn't line type sufficient?
Line
Type Initial Offset
Ok
Useful, but unclear, hard to implement.
Marker
Type
Ok
Hard to implement
Marker
Size
Ok
Hard to implement
Marker
Colour
Ok
Hard to implement
Text
Score
Type
remove?
Is anyone implementing this? test case?
Interior
Style
Ok
Hatch
Index
Ok
Pattern
Index
Ok
Edge
Type
Ok
Never understood diff between line and edge.
Edge
Visibility
remove
Never understood diff between line and edge.
Edge
Cap
remove
Isn't Edge Type sufficient?
Edge
Join
remove
Isn't Edge Type sufficient?
Edge
Type Continuation
remove
Isn't Edge Type sufficient?
Edge
Type Initial Offset
Ok
unclear and hard to implement.
Fill
Reference Point
remove
Isn't changing the pattern/hatch enough?
Just
a note. In my own personal opinion; I think I would dedicated resources to
transparency and animation along a path as oppose to the Style attributes.
Feedback
would be appreciated.
Regards,
Benoit