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: Re[2]: [cgmo-webcgm] DOM questions and implementation feedback


Catching up on some technical stuff, comments embedded...

At 04:30 PM 8/26/2004 -0700, Cruikshank, David W wrote:
>-----Original Message-----
>
>BB>>   2) Is the style attribute "fill-color" suppose to fill objects that
>BB>>   don't already have a fill-color?   If yes, what does WebCGM say
>BB>>   about filling non-closed objects?  calling setStyleAttr(
>BB>>   "fill-color", "50%" ) on a non-filled object should do what?
>
>CDW> I would rule that a call to the DOM fill attribute does not
>CDW> change the interior style of any of the closed figures in an APS.
>CDW> A circle with Interior Style of empty does not get filled if its
>CDW> containing APS is called with a fill-color style attribute.
>BB>>>Dave, just to make sure I'm on the same page you are; could you
>BB>>>explain to me when fill-color has an effect?
>
>Ben,
>
>My interpretation is that the fill_color style only has effect on elements 
>for whom the Interior Style is "solid".  Any other commnents??

About the first question -- I think we're getting into murky water, talking 
about filling objects that don't qualify under CGM:1999 as Filled Area 
primitives (there is a specific list of Filled Area graphical 
primitives).  I would vote 'no' on applying it to polyline, elliptical arc, 
text, etc.  (Question.  Don't we have an 'All-color' keyword?  I.e., dim 
everything in the object by 50%, or turn everything in the object red?  I 
remember it being discussed in one meeting.)

The other question is how, specifically, 'fill-color' affects Filled Area 
objects.

Thinking out loud...

I initially agreed that the fill-color style does not implicitly change the 
Interior Style ( {empty, hollow, solid, hatch, pattern} ).

The name fill-color would imply that it should apply only to those things 
that are affected by CGM:1999 Fill Colour attribute.  According to 
CGM:1999, this includes Interior Style 'solid', but also Interior Style 
'hatch' and 'hollow'.  (The hatch lines are drawn in Fill Colour, and the 
border of a 'hollow' filled area is are drawn in Fill Colour).

What about 'pattern'?  Do we want setStyleAttr("fill-color", "50%" ) to 
fade the pattern towards white?  (I think we do, else we have one 
exception, amongst all primitives, that we are unable to "dim").  Then what 
about setStyleAttr("fill-color", #FFOOOO) when interior style is 'pattern'?

Since we are talking about these style changes being used for transient 
highlighting, etc, you could make a case for wanting to turn the patterned 
circle to solid red temporarily.   If "yes", then we need to have it apply 
to interior style 'pattern' as well.

I think we need to talk (in telecon) about usage scenarios.  Do we want the 
fill-color style equivalent to:

1.) [intstyle=solid; new-fill-color]?
2.) [intstyle=unchanged; new-fill-color]?
3.) does the answer depend on whether new-fill-color is RGB or intensity 
(e.g., the 'pattern' case, if we choose #2)?

At 06:16 PM 8/26/2004 -0400, Benoit Bezaire wrote:
>Wednesday, August 25, 2004, 4:36:50 PM, David wrote:
>[...]
>BB>>   1) Are APS style attributes cumulative or not?  Example:
>BB>>   - assume we have a rectangle filled with black.
>BB>>   - we set it to red by calling setStyleAttr( "fill-color", "#FF0000" );
>BB>>   - we then set it to a relative color using setStyleAttr(
>BB>>   "fill-color", "50%" );
>
>CDW> Good question...without thinking too much about it, I would
>CDW> expect the transiant behavior of an APS attribute set through the
>CDW> DOM to revert to the original value when a subsequent call to the
>CDW> DOM is made w.r.t that APS?
>Ok, I don't have a problem with that.  The wording in the spec just
>has to be very clear.  If we don't go with this approach, I'm afraid
>we'll be increasing implementation time.

Cumulative or not?  I think the answer is "no", not across subsequent DOM 
calls aimed at the same object.

A different and interesting question is whether there is accumulation of 
relative styles down through the object hierarchy. This all started out 
being based on the CSS styling model (see [1]).

In the [1] section on Inheritance, we proposed that attribute values did 
inherit down the hierarchy to nested APS objects.  So 'red' (#FF0000) on a 
top-level APS turns all nested object red.

What about 50%?  If specified on a top-level APS object, then I would think 
you would want each nested object to be 50% of its CGM-defined color.  What 
if you used DOM to explicitly put 50% on top level APS, and to explicitly 
put 50% also on a nested APS.  Is the nested APS 50% or 25%?  I.e., Do 
relative values combine in the hierarchy, or are they always relative to 
the initial, CGM-specified value of the attribute.

I don't really care, but I suspect the latter is easier.

Does anyone know about the CSS model, what it would say in a case like this?

-Lofton.

[1] http://www.cgmopen.org/technical/stylable_cgm_submitted_0324.pdf




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