RE: [cgmo-webcgm] Comments on Style attributes [2 of 2]

[Lofton Henderson <lofton@rockynet.com>]

Forrest,

Thanks, that's good feedback...

At 09:55 PM 10/9/2007 -0500, Forrest Carpenter wrote:
> [...]
> 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).

Related question (all).  Stuart's programming indicated that
getStyleProperty() inquiry method might be handy for DOM
programmers.  It doesn't seem to have made it onto our list
yet.  Thoughts?

> We
> do not support LTIO but would be simple to add.

Yes, I recall adding it to some old HSI stuff... trivial for that dash
generator of ours, if my memory is correct.


> We
> have customers that use markers, but never in a Web
> environment.

Okay, noted.

-Lofton.

 

---

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