cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cgmo-webcgm] Comments on Style attributes [2 of 2]
- From: Lofton Henderson <lofton@rockynet.com>
- To: "Bezaire, Benoit" <bbezaire@ptc.com>,<cgmo-webcgm@lists.oasis-open.org>
- Date: Mon, 08 Oct 2007 15:24:59 -0600
[...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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]