Re: [cgmo-webcgm] ISSUE(S): Style Attributes

[Lofton Henderson <lofton@rockynet.com>]

Bottom line, Benoit, is that I think we're operating under different 
conceptions or models, and we have invented some terminology (<smile/>) 
which further obfuscates at least my understanding of our intentions...

At 04:51 PM 5/6/2005 -0400, Benoit Bezaire wrote:
>Friday, May 6, 2005, 3:10:44 PM, Lofton wrote:
>[...]
>LH> -- At 5.7.5, following the table, it says "Note Descriptions of all style
>LH> attributes have to be provide. [...]".
>LH> [...] However, the rest of that paragraph provides information that
>LH> should be in the descriptions, but is not.  For example, that
>LH> stroke-weight affects line-weight and edge-weight (or in CGM
>LH> parlance, "line width" and "edge width".
>Ok, what do we do about it? We need a proposal.

I will volunteer to do this as part of editing next version.  I don't 
guarantee a proposal before then.

However, the rest of this message makes me wonder if I understand at all 
what these "style attributes" are...


>LH> -- 5.7.5 "SetStyleAttr".  The description of text-font is "TODO".  What is
>LH> this going to be?  A font name (presumably), or a CGM text font index
>LH> (awkward)?  Is the font constrained to be amongst those in the CGM 
>Font List?
>Is there much use for this? Why would someone bother changing the
>actual font of a 'para' or 'subpara'? Could we take this out?

Actually, I have a vague memory of a previous decision to remove 
text-font.  But I can't find a record of that decision.  Any case, I would 
be happy to drop it.  I believe it is unimportant to the use cases upon 
which setStyleAttr is based.


>LH> -- 5.4 Style Attributes.  This starts right off talking about style
>LH> attributes without a clue as to what they are.  Either the table should be
>LH> right here, or there should be an intro paragraph that points to the table
>LH> in 5.7.5 setStyleAttr.
>This section is the CSS2 inheritance model. I agree that it needs some
>wording, and a proposal.

I will volunteer to do this as part of editing next version.  I don't 
guarantee a proposal before then.  (And I need a lot of clarification, see 
further comments below...)


>LH> 5.4.1.1, #1, "If the style attribute is assigned a value, use
>LH> it".  Assigned a value where?
>Assigned a value onto the APS. (where else?). We should review the
>words 'style attribute'... this is not the CSS 'style' attribute we
>are talking about.

Hmmm... well, it is not the ISO CGM attribute either.  CGM has no 
"stroke-weight" that affects both "line-width" and "edge-width" (the latter 
two being the ISO CGM [graphical primitive] attributes).  Stroke-weight is 
a WebCGM DOM invention.  It is a (graphical-ish) property applied to an APS 
via setStyleAttr (this was my belief).  It forces the alteration by a CGM 
viewer of the ISO CGM [graphical primitive] attributes line-width and 
edge-width.  In ISO CGM these latter two are not attributes of an APS, but 
rather of the graphical primitives within an APS.


>LH> Not in the CGM, as these are not CGM attribute elements.
>It could be. 'visibility' and 'interactivity' are (now) cgm
>attributes.

To be precise, they are CGM *application structure* attributes.  (CGM 
attributes are those things like line-width that are bound to CGM graphical 
primitives.)

The stroke-weight style attribute "cannot be assigned a value onto an APS" 
in the ISO CGM.  It does not exist in the CGM syntax.  It is "assigned a 
value onto an APS" by setStyleAttr of WebCGM DOM, or by definition of an 
initial value (in the WebCGM 2.0 spec).

>The problem is the title of section 5.4 "Style
>attributes", it needs to be rename.

Suggestion?

Btw, 'interactivity' is not in the table of 5.7.5 
setStyleAttribute.  Question.  Is the scope of 5.4 supposed to be identical 
to the contents of 5.7.5 table?  Are you saying that the Style Attributes 
of 5.4 are not an identical set to the Style Attributes of 5.7.5?!  (I have 
been assuming identical.)

>LH> So it could only be via SetStyleAttr, and that should be mentioned
>LH> (and linked) here.
>I don't agree.
>
>LH> (One exception:  visibility is settable via XCF also.)
>I think what's confusing is the fact that an introduction is missing.
>
>LH> 5.4.1.1, #3, "The initial value of each property is indicated in the style
>LH> attribute's definition."  Oops.  We didn't do this.
>We don't need to. #3 will never be reached for the exception of
>'visibility' and 'interactivity'. All these style attributes have an
>implicit value within the CGM document.

Stroke-weight does not have an implicit value in the CGM document, at least 
not at the APS level (which is where it is applied by setStyleAttr).  The 
example I gave earlier proves that.  (Or... are you saying that the 
stroke-weight of 5.7.5 is not amongst the Style Attributes being discussed 
in 5.4?)

(Even without the line-width / edge-width complication, what is the 
implicit value of stroke-weight of an APS that contains lines of widths 7, 
11, and 14?  Or ... are you proposing a model where, even though it can 
only be set at the APS level by setStyleAttr, nevertheless it conceptually 
exists at the primitive level within the APS, being the current value of 
either the line-width or the edge-width, depending on what kind of 
graphical primitives are under consideration.  Since we don't have a 
getStyleAttr(apsid), that model might work -- it doesn't matter whether a 
unique value of stoke-weight conceptually exists at the APS level.)

>The problem with the spec is
>that this section doesn't make the distinction between 'visibility'
>and 'interactivity' and these other style attributes.

Can you enumerate what "these other style attributes" are?


>LH> Neither the table in 5.7.5 nor the following style attributes'
>LH> descriptions give initial value.  Problem:  what should they be?
>LH> If you look at the table and  descriptions, it is clear that
>LH> "100%" is appropriate for all except  text-font and visibility.
>LH> What should 'text-font' be?  (I think we want "as-in-CGM", as it
>LH> is well defined there -- this is sort of the text-font equivalent
>LH> of "100%".)  What should 'visibility' be?  3.2.2.9 says "Initial
>LH> value: on".
>BTW, 'visibility' should be removed from this table.

Hmmm ... do you mean, because it is manipulated by 
setAppStructureAttr?  (And similarly for interactivity?)


>LH> 5.4.1.1, #3, s/property/style attribute/.  Actually, maybe we ought to
>LH> change the terminology to something like "style property"?  That would 
>help
>LH> to distance it from the CGM element class, "Attribute elements", which is
>LH> usually just shortened to "attributes".
>I agree we need to improve the terminology, "style property" work
>for me.

Okay.  I like the term also.  But now I'm completely confused about what it 
encompasses.  Again, can you enumerate the "style properties" of 5.4, and 
are they the same things as should be in the table of 5.7.5 
setStyleAttr?  (I.e., should that table be re-titled "Style Properties"?)


>I'm starting to think we may need two inheritance models.
>One for 'visibility' and 'interactivity' using the 3 current bullets
>founds in the spec. And a second one for the other style properties
>using only the first two bullets.
>
>LH> 5.4.1.2, "Specified values are resolved to computed values after the
>LH> document tree is create[d]; for example relative units ('%') are 
>computed to
>LH> absolute values (i.e., RGB color or NVDC)."  There is a conceptual problem
>LH> here.  Stroke-weight illustrates it.  Suppose "initial stroke-weight" is
>LH> 100%.  Suppose the CGM's line-width is 5 and edge width 10 in a given
>LH> APS.  What is the NVDC Computed Value for stroke-weight for that APS?  I
>LH> don't know the answer.
>We could require the implementations to behave 'as if' two values
>where inherited (line-width and edge-width)... But to be honest, I
>don't even know what's the difference between the two values?

<Aside to elaborate on CGM line and edge attributes...>
Line-width affects the drawing of line primitives -- a subset of cgm 
"graphical primitives" that includes polyline, polybezier, elliptical arc, 
disjoint polyline, and a few others.  Edge-width affects the drawing of the 
edge/boundary of filled-area primitives --  a subset of cgm "graphical 
primitives" that includes polygon, closed figure, rectangle, circle, 
etc.  They are separate attributes, that apply to disjoint sets of 
graphical primitives.  It could be that lw=7 and ew=14 simultaneously, in 
which case line primitives are drawn 7 wide and filled area boundaries are 
drawn 14 wide.  (Remembering, of course, that the CGM attributes are 
modally specified and modally bound to subsequent graphical primitives in 
the stream, until re-specified.)

It is a different model than SVG, where stroke-weight affects a drawn line 
no matter what kind of object it occurs on -- polyline, border of 
rectangle, stroked outline text, etc.  (And of course SVG is not a modal 
stream model of attribute binding.)
</aside...>


>LH> I suspect, because we don't have a 1-to-1 relationship between
>LH> style properties and affected CGM attributes, that we're going to
>LH> have some problems with Computed Values.
>
>LH> 5.4.1.2, 2nd pgph, "When the specified value is not 'inherit', the 
>computed
>LH> value of a style attribute is determined as specified by the Computed 
>Value
>LH> line in the definition of the property."  Oops.  We didn't do this.  This
>LH> is not specified in 5.7.5, neither in the table nor the following
>LH> descriptions.  I don't know what it should be.  We need a proposal.
>Dieter proposed that we add 'inherit' as a possible value for
>'visibility' and 'interactivity'. I don't think it was proposed for
>the other style properties. So again, the problem here, is that we
>fail to make the distinction between CGM attributes and style
>properties.

Yes.  It will help once we enumerate them.  (I myself am confused at this 
point.)

Regards,
-Lofton.


>LH> 5.4.2, "Each style attribute defines whether it is inherited or
>LH> not."   Oops.  We didn't do this.  Neither the table in 5.7.5 nor the
>LH> following style attributes' descriptions give inheritance rules.  We 
>need a
>LH> proposal (I don't have time right now to work one up.)  (Exception: we 
>know
>LH> about 'visibility' from 3.2.2.9.)
>Same comment than above.