ISSUE: What values should be allowed for the 'stroke type' SP?

[Lofton Henderson <lofton@rockynet.com>]

ISSUE:  What values should be allowed for the new 'stroke type'
Style Property?

Source:
http://lists.oasis-open.org/archives/cgmo-webcgm/200805/msg00013.html

DESCRIPTION:  Ben writes:

At 11:30 AM 5/6/2008 -0400, Bezaire, Benoit wrote:
> [...] 
> i) stroke-type: we should put stroke-type
> values between " (quotes), see fill-style. Proposal: remove negative
> values, how is a script writer going to know about user defined
> types?

At the risk of being lengthy, I'd like to explore this in some
detail...

I had the some of the same reactions when I read this.  I have two
questions about intent:
1.) Why not 6..15 -- the registered types or some subset of them -- as
well as 1..5 (or rather solid ... dash-dot-dot as they are currently
specified)?

2.) Does it make sense to allow negative line type index values through
setSP(), relying on the LETDs already being resident in the CGM (as
opposed to the LETDs being defined through setSP())?

About #1 -- I don't have a strong opinion.  I'm just wondering how
the use cases / usage scenarios distinguish between 1..5 and 6..15? 

About #2.  I have looked back at the use cases, 
http://www.oasis-open.org/committees/download.php/26099/Attributes_Table.pdf
,
and am wondering how this fits in.  

I can guess at a couple possible motivations:

2a.) Is this intended as another source of possible line types to use for the common sort of Style Property scenario -- temporary visual emphasis or emboldening of content?

[Question.  Does the implementation complexity of this basic usage justify its gain, as opposed to just being able to ask for 1..5 and maybe 6..15?  I'm dubious.]

2b.) Is it about pseudo-motion along a line, by cycling through a set of LETDs?  I.e., about that first bullet in the "..DOM column.." bullet list?  (That bullet seems to imply that the LETD would actually be passed in the setSP() call.)  

[In any case, pseudo-motion via line type would be *much* better handled by cycling through a set of values of Initial Offset (e.g., 0, 1/3, 2/3, 0, ...) than by cycling through a set of different line types.]

SUMMARY:  I have lots of questions, trying to understand how this is to be used, and whether the usage scenarios justify the complexity or the conceptual disconnects.  (Let's keep 2.1 as simple as possible while satisfying actually useful scenarios!)

RECOMMENDATION: remove the negatives, or clarify & approve the usage scenarios that justify them.  

MORE DISCUSSION:

As Ben points out, the only way that negatives could be used is that the user has a' priori knowledge of what is in the metafile (e.g., ran some tracing tool). After seeing what LETD elements are in the metafile, then sets up DOM calls to setSP(), or XCF elements for SP-setting.  This makes access to the negatives very different from access to 1..5 and 6..15, which are always implicitly available.

Is this scenario reasonable enough that we want to document and promote it?  If the author were going to write the metafile with the LETDs in there already, why would he/she not go ahead and invoke them right there in the metafile?  Do we envision that authors are going to write lots of LETDs in the metafile for possible later use through DOM or XCF?  

Would the DOM / XCF scenarios for highlighting or emboldening be better served by simply passing an LETD in the SP call?  Then, in effect you would then telling the viewer, "change all lines in the picture (or APS) to the pattern defined by this LETD".  While this scenario seems more sensible conceptually, on the other hand it is more complex to implement.

-Lofton.