OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cgmo-webcgm] How does interior-style work?


All,

 

I believe we need interior style. If we just say setting a hatch index will change the interior style to hatch, how would you change it back to solid? If you use set fill color to switch back to solid interior style, how do you know if the user wants to just change the hatch color.

 

Regards,

Forrest

 


From: Weidenbrueck, Dieter [mailto:dweidenbrueck@ptc.com]
Sent: Wednesday, January 14, 2009 9:08 AM
To: Lofton Henderson; WebCGM
Subject: RE: [cgmo-webcgm] How does interior-style work?

 

Lofton,

 

thanks for the clarification. If the group thinks that interior-style is needed I am fine with it.

 

However, from a script writer’s perspective I wouldn’t know how to set a pattern or hatch index at all. We are talking about a generic programmer without CGM knowledge, so it will be difficult at all to know that interior style allows for specification of patterns and hatchings as well. Then on top the viewer would expect an index. Other than with Metacheck I wouldn’t know how to get to such an index (beyond 1..6). For example, in IsoDraw there is no way to get to this index.

More than that, the various hatch styles and patterns in test files show a great variety, and I guess that nobody uses these.

 

When it comes to hatchings, it will be the standard hatch types 45°, -45°, cross-hatch, with variations of line distance, that people would want to use. Perhaps things would become a lot simpler if we would allow for these simple hatch types only initially, and document them with pics in the spec. Patterns is more difficult I guess, no idea here.

 

Let’s hear what others think, perhaps somebody has a better idea.

 

Dieter

 

 

From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Mittwoch, 14. Januar 2009 15:59
To: WebCGM
Subject: RE: [cgmo-webcgm] How does interior-style work?

 

Hi Dieter,

I agree with your observation that the present configuration is qualitatively more complex than 2.0.  You are correct that it will be difficult for script writers to detect programmatically what pattern indices and hatch indices (other than the default 1..6) are defined in the CGM.  A' priori knowledge is implied.  (The ACI allows the hatch styles to be defined, but not the patterns.)

The interior-style SP has been in the 2.1 drafts from the beginning, and was in tables that Dave and Stuart put together before the first drafts.  Those tables contained all possibilities, and we whittled down to the ones that people wanted to keep.  I recall past discussion of difficulties such as you identify, and other similar ones.

Do you (or anyone) want to propose that interior-style be removed?  Majority support would be needed.

All -- if such a proposal is forthcoming, please speak up, pro or con about interior-style SP (keep or remove)?

Regards,
-Lofton.


At 09:19 AM 1/14/2009 -0500, Weidenbrueck, Dieter wrote:

Lofton,

your description of Interior Style as per CGM:1999 is correct, of course. However, so far we have tried to keep things simpler in the DOM compared to the CGM world. We should try to follow that path here as well, and avoid complex rules for stroked parts.

Also, it will be extremely difficult for a script writer to know hatch or pattern indices, but there may be no way around this if we allow for different interior styles.

I was not aware that we did want to specify interior styles as well, I thought we only wanted to be able to change the color of an already applied style.

Dieter

From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Mittwoch, 14. Januar 2009 01:23
To: Bezaire, Benoit; WebCGM
Subject: RE: [cgmo-webcgm] How does interior-style work?

 

Benoit --

I'll put this on the agenda for Thursday discussion in the WG.  (Which excludes some TC members -- so please reply/comment now on this list if this topic interests you!)  Maybe also next week in the TC.

I'll take a crack at the "general explanation" in the next few days, unless someone else wants to have at it.

Aside from the question of "side effects", there might be technical problems with your suggestion to have fill-color, pattern-index, hatch-index SPs override the CGM's INTERIOR STYLE.  For example, FILL COLOUR is used in more than one way in CGM:1999.

** if INTERIOR STYLE is 'solid', it is the color of the interior;
** if INTERIOR STYLE is 'hollow', it is the color of the border (as distinct from the edge);
** if INTEROR STYLE is 'hatch', it is the color of the hatch lines;
** it doesn't affect 'geometric pattern', 'pattern', or 'interpolated interior', IIRC.

So the fill-color SP, at least, would not have an unambiguous association for overriding INTERIOR STYLE.

I haven't yet thought enough about pattern-index and hatch-index SPs -- whether there are technical issues with them having the INTERIOR STYLE override side effect.

About your observation that 2.0 only contained fill-color SP... Good observation.  So fill-color SP would only have an effect if the INTERIOR STYLE were 'solid', 'hollow', or 'hatch'.

I agree that we should specify test cases and assign them, after we have endorsed some new text for a general explanation of how SPs work.

Thoughts (anyone)?

-Lofton.

At 09:24 AM 1/12/2009 -0500, Bezaire, Benoit wrote:

A general explanation should suffice.  However, I wonder if interior-style is required at all... should we consider an approach where setting one of the following SP: fill-color, pattern-index, hatch-index automatically overrides interior-style? It seems awkward for the script writer to always have to make two calls, first to set the color or index, the second to change the interior style.

Please note that in WebCGM 2.0, we added fill-color and there's no mentioning at all of interior-style?!
 
Test cases should also cover the general explanation.

 

From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Saturday, January 10, 2009 1:18 PM
To: WebCGM
Subject: RE: [cgmo-webcgm] How does interior-style work?

Benoit,

At 10:41 AM 1/9/2009 -0500, Bezaire, Benoit wrote:

Since you used the words 'opinion' and 'guess'... the working group will have to work on better defining this.


Apologies, I was rushing and my too-casual wording doesn't reflect that I'm actually quite certain how it works. As I described:

[[[
order does not matter as long as *both* changes happened before the display redraw (i.e., you might want to delay updates till you set both).  If not, then given the modal nature of CGM attributes, I would:  set pattern index; change interior style to pattern.
]]]

FIRST order of business:  this will be on the Thursday telecon, to endorse as correct or to refute.  If the latter, i.e., if I'm wrong, then we need specific counter-proposal and rationale from someone.

SECOND.  Let me explain why it is correct, and then let's think about how improve the specification might be better.

(Patience please! ... it has gets lengthy...)

Overview:
----------

1.) Though somewhat intricate, it is nevertheless unambiguous in the CGM:1999 specification how all permutations and combinations of fill attributes would work in static sequences of metafile elements, in various orders etc.  (Forget about interactive SP-setting for the moment.)

2.) I think it is also unambiguous how setRedraw works to allow or suppress the immediate effect of individual SP-setting calls.

So if we can devise a general statement/rule that relates how a given SP-setting call affects the modal attribute list of the APS (see CGM:1999 section 6.7), then CGM:1999 defines the exact graphical effect that should happen at the redraw after each SP-setting call.  Combining that with the setRedraw state, then such a general statement/rule can be used to answer any detailed question such as yours.

Detailed Explanation:
---------


I think the specification should describe the relationship between interior-style and other relevant style properties.


CGM:1999 (see section 6.7) is unambiguous about the graphical effect of static sequences of elements in metafile instances like:

FILL COLOUR 'red'
INTERIOR STYLE 'solid'
PATTERN INDEX '9'
POLYGON
INTERIOR STYLE 'pattern'
POLYGON
(the first polygon is solid red, the second is pattern #9)

or

INTERIOR STYLE 'solid'
INTERIOR STYLE 'pattern'
POLYGON
PATTERN INDEX '9'
POLYGON
(the first polygon is pattern #1 (the default pattern index), the second is pattern #9)

If we can understand how each SP-setting call alters the "virtual" metafile element sequence in an APS, then post-SP-setting effects can be understood from CGM:1999.  WebCGM doesn't need to replicate the details, for example, of how interior-style and pattern-index DOM SP settings interact, if we make it clear how each SP setting affects the (virtual) metafile-element sequence in the target. 

The way in which the SP-setting calls affect the metafile element sequence of the APS shouldn't be hard to describe.  Here is a fast, off-the-cuff first cut:

When the metafile is first interpreted, conceptually a virtual copy of the elements in the APS is made and is initialized from the actual APS content of the metafile.  Call this the display list for the APS.  An SP-setting function like interior-style (e.g., to 'pattern') has the effect of setting the INTERIOR STYLE to 'pattern' in the modal attribute list (see CGM:1999 sec 6.7) , throughout the APS.  I.e., regardless of the initial interior style(s) affecting each graphical primitive throughout the APS, the INTERIOR STYLE is reset to 'pattern' for all primitives as a result of the SP call.  The interpreter knows how to draw this from CGM:1999, and the interpreter immediately does redraw it unless there has been a call to setRedraw('disableAll').

So ... does the order matter?  Yes.  If you do this to an APS that has one graphical primitive element -- a polygon as its last element:

setRedraw('enableAll')
setSP(interior-style, 'solid')
*** redraw-1 ***
setSP(interior-style, 'pattern')
*** redraw-2 ***
setSP(pattern-index, 11)
*** redraw-3 ***

Then you get:  *** redraw-1 *** solid polygon in the current fill color; then *** redraw-2 *** pattern polygon with current index (default #1, if it has not otherwise been set in the metafile); then *** redraw-3 *** pattern polygon with index #11.  (On the other hand, if you disable redraw at first and re-enable at end, you get only #3.)

setRedraw('enableAll')
setSP(interior-style, 'solid')
*** redraw-1 ***
setSP(pattern-index, 11)
*** redraw-2 ***
setSP(interior-style, 'pattern')
*** redraw-3 ***

Then you get:  *** redraw-1 *** solid polygon in the current fill color;  then, *** redraw-2 *** [unchanged] solid polygon in the current fill color; then, *** redraw-3 *** pattern polygon with index #11.  (Note:   the interpreter could detect "no change" and optimize by not redrawing #2).

Summary:

I claim that all specific questions like yours are answered by the existing rules of CGM:1999, and need not be answered one-by-one in WebCGM, if this model relating the aftereffect of a DOM SP-setting call to a sequence of static metafile elements is clearly understood.

Question:

What should be added to the spec?  I vote against situation-by-situation (element-by-element) explanations, if we can draft a general explanation of the rules that helps each person to answer such specific questions.

Thoughts?

Regards,
-Lofton.



Benoit.

 

From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Friday, January 09, 2009 10:24 AM
To: Bezaire, Benoit; WebCGM
Subject: Re: [cgmo-webcgm] How does interior-style work?

My opinions...

At 10:13 AM 1/9/2009 -0500, Bezaire, Benoit wrote:


I'm slightly confused with interior-style, more specifically the dependency that other style properties have on interior-style.
 
Let's say a WebCGM metafile contains an APS (polygon filled with red color). A script writer wishes to change the fill to a pattern, how does he do that?
 
He needs to change the interior-style and the pattern-index, right? Does the order matter?


My guess:  order would not matter as long as *both* changes happened before the display update (i.e., you might want to delay updates till you set both).  If not, then given the modal nature of CGM attributes, I would:  set pattern index; change interior style to pattern.



Another question is if fill-color only has an impact if interior-style is set to solid?


Fill color also defines the drawn border when interior style is 'hollow' (as distinct from the edge, which has its own attributes).

-Lofton.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]