cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [cgmo-webcgm] ISSUE: What values should be allowed for the 'stroke type' SP?
- From: "Cruikshank, David W" <david.w.cruikshank@boeing.com>
- To: "Lofton Henderson" <lofton@rockynet.com>, "CGM Open WebCGM TC" <cgmo-webcgm@lists.oasis-open.org>
- Date: Sat, 10 May 2008 12:53:48 -0700
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.
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.
Dave
Technical Fellow - Graphics/Digital
Data Interchange
Boeing Commercial Airplane
206.544.3560, fax 206.662.3734
david.w.cruikshank@boeing.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.
line_offset.cgm
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]