Lofton,
Changing the offset for line types 2-5
would allow you to show the direction of a flow but it would not allow you to
show the progression of a fluid or gas in a pipe. You could accomplish this by
defining a line type with a long dash followed by a space of equal length. By
setting the initial offset to .5 and then decreasing the offset incrementally you
could show the progress of a fluid flowing in a pipe.
I do not see many users hand coding a DOM
script for a complex simulation. This would be done by an authoring tool that
would create the CGM file and the accompanying DOM script.
Regards,
Forrest
From: Lofton Henderson
[mailto:lofton@rockynet.com]
Sent: Monday, May 12, 2008 9:00 AM
To: Forrest Carpenter; 'CGM Open
WebCGM TC'
Subject: Re: FW: [cgmo-webcgm]
ISSUE: What values should be allowed for the 'stroke type' SP?
At 06:06 PM 5/11/2008 -0500, Forrest Carpenter wrote:
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?
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.
Thanks for the feedback, Forrest.
Just to help me understand better ... could you explain the usage scenario, how
you would intend to use the functionality? I.e., the metafile already
containing a collection of LETD elements defining negative indices, and then a
script application invoking those with setSP(..<negative>..)?
What is an anticipated application and what sorts of things are you trying to
accomplish? Who is the metafile author and who is the user? That
sort of stuff.
(If it's easier, we can talk about it Wednesday, rather than email.)
-Lofton.
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