RE: Chapter 4 Review

["DULUC, Franck" <franck.duluc@airbus.com>]

Oops, wrong file.

 

Sorry for that.

 

Correct file attached:

 

-----Message d'origine-----
De : DULUC, Franck
Envoyé : mercredi 14 mai 2008 13:51
À : CGM Open WebCGM TC
Objet : Chapter 4 Review

All,

 

Here is my inputs for Chapter 4.

 

I have not mastered to help Dieter on 5. Will do it later this week.

 

Regrets for this afternoon.

 

Franck.

-----Message d'origine-----
De : Weidenbrueck, Dieter [mailto:dweidenbrueck@ptc.com]
Envoyé : mercredi 14 mai 2008 10:54
À : Lofton Henderson; CGM Open WebCGM TC
Objet : RE: [cgmo-webcgm] ISSUE: What values should be allowed for the 'stroke type' SP?

All,

 

just a couple of comments re LTIO.

This is currently not implemented in IsoDraw and IsoView, and it would be a major effort to change this for internal coding reasons.

 

I think the concept of LTIO goes back to the days when people paid a lot of attention to graphical detail (which I always liked a lot). However, to improve the graphical quality the LTIO would have to be specified on a per element/primitive basis, to balance the line style between end points. A good illustration would move the pattern such that it would look good on an single line. A general LTIO was something that our users very rarely asked about.

 

Now we want to (ab)use this feature to enable some kind of cheap animation, which is a very different purpose IMO. Instead of providing a simple to use, straightforward interface to meet users' requirements we now export very low level detail of the CGM to the outside.

 

Example:

We decided to use NVDC for all DOM actions related to coordinates or sizes. This means that a user has a very easy to use coordinate space, and he doesn't have to deal with all the different variations inside a CGM.

 

Back to the linestyles. First question: How will a user be able to tell which linestyle has which ID? In IsoDraw there is no way that anybody could tell, and simply copying a line from one illustration to another together with its linestyle would change the ID of the linestyle to keep it unique. There is - to my knowledge - no interface that a user could query the linestyle of a specific object (because he can't address primitives in DOM calls), nor is there a call to find out about the details of that linestyle. Hence the entire foundation for solid scripting is missing, the application writing the CGM would have to write a file-specific script at the same time. That script would then work with a single file only, and not necessarily with any other file.

 

Some thoughts about setting an LETD by means of a DOM call:

Right now we can address an APS only, e.g. a grobject. We can not address primitives. So an LETD would be applied to the entire APS content, which may be fine. We should provide a "restore" call as well to allow the script writer to return to the intial state. The application would register the supplied LETD internally and apply it temporarily to the APS content, and hence it would handle all ID related issues internally only.

 

Regards,

Dieter

---

From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Samstag, 10. Mai 2008 22:59
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

This mail has originated outside your organization, either from an external partner or the Global Internet.
Keep this in mind if you answer this message.

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

Chapter_4_XCF_FD_Review_20080514.pdf