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

[Lofton Henderson <lofton@rockynet.com>]

Real-world content generators --

My detailed opus of yesterday agrees with and illustrates a lot of what
Stuart says in his (below) message.  

I generally agree with his choices.  But I do have one question
embedded, to vendors (and users as well, I guess)...

At 02:18 PM 10/8/2007 -0700, Galt, Stuart A wrote:

Hello all,
 
The second column of the table in http://www.oasis-open.org/committees/download.php/25270/Attributes_Table.pdf
contains all of the potential attributes including ones that are not allowed by the profile, and some that would be
crazy to let people change at runtime.  The last column "DOM/XCF" was intended to be a superset of what
would could potentially show up in next version of webCGM.  I figured that it would be easier to take things
off the table than to put them on.  So here is my quickie description of potential use cases...

Line Type: This allows changing from solid to dashed lines.  I could see it used to show changing state (eg the part that is not quite removed yet) Line Cap, Line Join, and Line Type Continuation:  I agree with Benoit.  I can't think of a real use to be able to control these at runtime. Line Type Initial Offset: This would be useful to be able to give patterns the illusion of moving (flow along a line) Marker Type, Marker Size, Marker Color:  I don't use these but I would think that the use case for this would be the same one as changing the size/color of text.

Is anyone generating markers in any real-world content?

-Lofton.

Text Score Type: I put this one one the list to be able to underline text.  I am not sure how well this is supported so I will not be surprised if it does not make the cut... Interior Style:  This would mostly be used to switch between hollow and solid or a pattern as way of changing the interior of polygons, circles, etc. Pattern Index, Hatch Index:  Not sure I understand the difference between these two but I suspect that the use case would be similar to being able to change the line type but for the interior of solids. Edge Type, Edge Visibility: For solid shapes that a fill of hollow it would allow similar effects as changing LineType.  Edge Cap, Join and Continuation:  I agree with Benoit on this.  I feel it is the same non-use case as the line version of these attributes. Edge Type Initial Offset:  This would have a similar effect as the Line Type Offset but I am not sure why this would be useful.  I imagine that it would be like having chaser lights around the exterior of a sign. Fill Reference Point: This would be similar to Line Type Initial Offset but for solids.  It could be used to show things like heat flow, condensation, weather (like rain or snow) etc. or places where you want a pattern moving in a box.

Most of those items above can be "worked around" but repeating geometry and putting them into different
APS structures and turning the visibility on and off.
 
Hopefully this provides some insight as to what I was thinking when I initially made the table.  In a more
global sense I would trade most of these items on the list to be able to translate and/or rotate an APS
either via transforms defined in an XCF file or via DOM calls.  This would allow me to have "movement"
without having to resort to simulating movement by changing the visibility of APS structures.
 
Stuart.

--
Stuart Galt
SGML Resource Group
stuart.a.galt@boeing.com
(206) 544-3656

 

---

From: Lofton Henderson [mailto:lofton@rockynet.com]

Sent: Monday, October 08, 2007 1:03 PM

To: cgmo-webcgm@lists.oasis-open.org

Subject: Re: [cgmo-webcgm] Comments on Style attributes [1 of 2]

[...part 1 of 2...]

Benoit et al --

Thanks again to Benoit for his thoughtful input on the DOM Style Properties question.

Per earlier message, I agree with his sentiment that it is not necessary, and is potentially wasteful of vendor resources, to give access through DOM Style Properties to all CGM V3 attributes.  For requirements like simulating flow, for which we have use cases, there is no need.

Exposing all attributes might have a potential benefit related to Accessibility, but ... personally, I'd prefer not to go there now.  I think the TC should answer an initial question before trying to list which specific Style Properties should be supported.

QUESTION:  Is our motivation to expose as DOM Style Attributes all of those CGM attributes (etc) that can sensibly be altered through DOM?  Or do we want to expose a restricted subset which support articulated use cases?

If the latter, then so far (at Seattle and since then) I have heard use cases for better supporting flow simulation, in wire-like things (implying some more stroke properties) and in tube-like things (implying more of either fill or line properties).

Part 2 to follow,

-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