From: Forrest
Carpenter [mailto:forrest@sdicgm.com]
Sent: Sunday, May 11, 2008 6:04 PM
To: 'Lofton Henderson'
Subject: RE: [cgmo-webcgm] ISSUE:
What values should be allowed for the 'stroke type' SP?
All,
I believe we should allow negative line
and edge types as the stroke type SP provided they are already defined in the
metafile, I don’t see any real need to define a new LETD through the DOM.
We will add support for line initial offset soon.
Regards,
Forrest
From: Lofton Henderson
[mailto:lofton@rockynet.com]
Sent: Sunday, May 11, 2008 12:35
PM
To: Cruikshank, David W; CGM Open
WebCGM TC
Subject: RE: [cgmo-webcgm] ISSUE:
What values should be allowed for the 'stroke type' SP?
At 03:59 PM 5/10/2008
-0700, Cruikshank, David W wrote:
Ok, but remember that Line Type Initial
Offset has been there for 16 years.
There is no test in the V3 suite. Which I think explains why no one
bothered; and because there wasn't a demand or use case until now.
(I think there might have been a test way back when HSI contracted with NIST to
upgrade the V1 test suite to V3.)
I hope at least 2 vendors implements it.
If they don't, then the feature gets pulled. (Since the TC approved the
requirement and associated use case, presumably they will implement what is
needed for it.)
BTW...in my example the offset should have been
..375 (not .5), but it still isn't supported.
Again:
** it's trivial to implement (I did it once);
** unless the reqt / use case is eliminated, vendors must implement either LTIO
or the present negative-indices-LETD kludge (I would *way* prefer this, as an
implementor);
** it is the cleaner solution for that reqt/use case;
-Lofton.
Technical Fellow - Graphics/Digital Data Interchange
Boeing
Commercial Airplane
206.544.3560,
fax 206.662.3734
david.w.cruikshank@boeing.com
From: Lofton
Henderson [mailto:lofton@rockynet.com]
Sent: Saturday, May 10, 2008 1:59
PM
To: CGM Open WebCGM TC
Subject: RE: [cgmo-webcgm] ISSUE:
What values should be allowed for the 'stroke type' SP?
At 12:53 PM 5/10/2008 -0700, Cruikshank, David W wrote:
In the case of pseudo-motion along a line,
Lofton said:
[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.]
Curiously enough, of the four products that I tried none of them have Initial
Offset implemented. I think this was pointed out in Stuart's table.
Too bad. It is trivial to implement. (We did it years ago.) I
remember a test for it. Is that in the V3 part of the WebCGM Test
Suite? Or was it just our own local test? (I suspect "not in
test suite" -- else we would have some implementations.)
Attached is a simple cgm file containing 4 lines.
The top line is the standard CGM Line Type 4
The second line a CGM Line Type -4 defined as "400 12 1
2 1" with an initial offset of .5
The third line is a CGM Line Type -6 defined as "400 6 1
2 1 6 0" with an initial offset of 0 to emulate the style of the second
line type (btw that zero gap causes a slight gap in some renditions)
The forth line is a Disjoint Polyline to indicate the correct
rendition of the line
The motivation for calling out negative Line Types through
the DOM is probably to get around the fact that Initial Offset is not well
supported. You can get the same effect by defining negative line types
(LETD) through the DOM and then reference them.
Two comments:
1.) in fact, the way the new SPs are defined, it is NOT POSSIBLE to download the
LETDs through the DOM. The SP 'stroke-type' definition indicates the have
to be already inside the CGM.
2.) I don't think we should redesign WebCGM -- bypassing the simple best
solution in favor of a complex and "kludgey" one -- because a simple
feature is missing from the viewers. Put a V3 test in the test
suite. That will ensure two implementations before 2.1 finishes.
I would bet that the implementors would prefer that also -- implement the
trivial InitialOffset CGM:1999 V3 element -- rather than the complex
workaround.
Recommendation: for support of that Use Case, rely on
InitialOffset. Remove the negative indices/LETD stuff from the
'stroke-type' SP.
-Lofton.
From: Lofton
Henderson [mailto:lofton@rockynet.com]
Sent: Friday, May 09, 2008 4:43 PM
To: CGM Open WebCGM TC
Subject: [cgmo-webcgm] ISSUE: What
values should be allowed for the 'stroke type' SP?
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.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.11/1422 - Release Date: 5/8/2008 5:24
PM