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: Background Re:a question about Esc.45


All --

Rather than overload the question of the previous message (below), I 
decided to split out this indication of my preliminary thinking on the 
drafting task of sorting out the overall mess...

BACKGROUND.   There are a half-dozen or so transparency-related items in 
WebCGM that affect the foreground and/or the background.  Each of these was 
designed with a some use case in mind.  WebCGM should expect them to give 
the intended result(s) when used in isolation.  That notwithstanding, 
Benoit did a great job of clarifying some of the mixed cases when drafting 
2.2.2 [1].

However, IMO we should not go as far as trying to normatively specify 
results of *all* of the odd combinations that are not already clearly 
covered by [1] -- maybe some, but not ALL.  The spec should warn that using 
the functionalities in odd combinations will likely give unpredictable 
results.  (More later, in a complete recommendation.)

In closing, one more observation.  It would really simplify things to get 
rid of (deprecate) RGBa and sRGBa, and I doubt it would invalidate much 
current WebCGM content.  However, these are capabilities that go back to 
the original W3C requirements for a scalable vector format for the Web, and 
I suspect that we might run into problems trying to go to REC without them.

-Lofton.


At 05:37 PM 2/18/2008 -0700, Lofton Henderson wrote:
>Hi all --
>
>I'm working on the 2.1 drafting assignment, specified in the minutes as:
>
>[[[
>·       Clarify transparency interactions
>Not assigned  Ben did this before  is there anything more here?
>]]]
>
>First, consider it assigned -- I'll take it.  Right now, I'm still reading 
>and understanding the details.  One such detail question is the main 
>purpose of this mail.
>
>There are three references relevant to my question:
>
>[1] Sec. 2.2.2: 
>http://docs.oasis-open.org/webcgm/v2.0/OS/WebCGM20-Concepts.html#webcgm_2_2_2
>[2] Esc.45:  http://jitc.fhu.disa.mil/nitf/graph_reg/diagrams/esc045.html
>[3] Sec. 2.2.3: 
>http://docs.oasis-open.org/webcgm/v2.0/OS/WebCGM20-Concepts.html#webcgm_2_2_3
>
>[2] says:  "This escape function may occur in the Picture Descriptor or 
>Picture Body, in the definition of segments of all kinds, and in the 
>METAFILE DEFAULTS REPLACEMENT element."  But it doesn't say what happens 
>if it occurs in the PD.
>
>[1] talks about "Primitives which have a value for [...Esc.45...] other 
>than fully opaque...", but doesn't mention the PD (which of course has no 
>primitives).
>
>[3] says: "...the registered Escape 45 (alpha transparency) element may be 
>included in the Picture Descriptor and applied to the background color of 
>the picture."
>
>QUESTION:  Is that the clarification/interpretation that should apply to 
>the (underspecified) definition of Esc.45 in the PD [1]?
>
>OPINION:  Yes.  It seems to conform to our (1999) thinking as written into 
>[1] and [3], and it would allow the main use cases involving non-trivial 
>alpha values on foreground stuff and background to be handled either by 
>Esc.45 alone (in RGB metafile), or by RGBa alone.  I.e., two separate and 
>complete mechanisms.  The only sensible alternative meaning would be 
>"applies to everything in the picture body", but this can be done by 
>putting Esc.45 at the beginning of the picture body.
>
>-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
>
>




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