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: ISSUE: change WebCGM 1.0 degeneracy specs? [was: Initial values, % sub-issue]


I'm starting a new thread.  This degenerate-values discussion is a 
different issue than "initial values, %, etc."

Dave, can you record the issue?

At 01:00 AM 5/19/2005 +0200, Dieter  Weidenbrück wrote:
>[...]
> > -----Original Message-----
> > From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
> > Sent: Wednesday, May 18, 2005 11:30 PM
> > To: Benoit Bezaire; cgmo-webcgm@lists.oasis-open.org
> > Subject: RE: Re[2]: [cgmo-webcgm] Initial values, % sub-issue [was:
> > Re[2]: [cgmo-webcgm] Style properties]
> >
> >
> > For Line Width and Edge Width, zero width, minimum width, and no
> > stroke are different if you follow the guidelines in Annex D of
> > the Standard
> >
> > D.4.6.3   LINE WIDTH
> > If a device cannot produce a line of the exact specified width,
> > the closest implemented width is chosen.  If a zero width is
> > specified in the metafile, it is recommended that interpreters
> > select the minimum available width for affected primitives.
> >
> > D.4.6.18   EDGE WIDTH
> > If a device cannot produce a line of the exact specified width,
> > the closest implemented width is chosen.  If a zero width is
> > specified in the metafile, it is recommended that interpreters
> > select the minimum available width for affected primitives.

Just to be clear, Annex D of ISO 8632 is non-normative.

The specification in WebCGM 1.0 T.20.4 is normative.

>This is what I referred to when I said "it is impossible" to have 0 width.
>A thin line will always be drawn, which is a heritage that I would
>rather see being removed.

Let's start a new thread.  This is an entirely different...
ISSUE:  do we want to deprecate or change the WebCGM 1.0 degeneracy 
specification, in the PPF?

(I'm assuming that we don't want to layer on top of WebCGM's 1.0 
specification of degenerate attribute behaviors, a set of allowable style 
property degenerate-case specs that lead to *different* result than if the 
zero-valued thingy comes from the WebCGM instance?)


>So 0% of
>- any color results in white,
>- of text-height results in ...?

WebCGM 1.0, T.20.15:  "minimum available size".

Related, we have not yet described, for example, how the character-height 
style property, which can ONLY be % according to table in 5.7.5., interacts 
with the existing text layout of the RESTRICTED TEXT elements.

>- of line-weight results in a thin line
>
>We should agree on a result that is understandable for a user, if possible.

How about this:  those style-properties must be positive.  Why create 
another set of degeneracies, and then have to sort out how they behave?  We 
had to specify behavior of degenerate cases for WebCGM 1.0, because ISO CGM 
Model Profile allowed 'em (and we weren't smart enough to prohibit them in 
1.0).  So we had to make a normative specs for how they behave.

>The thin line is difficult to accept unless you know CGM inside out. You
>wouldn't
>believe how many support cases we have had because of that thin line.

For 2.0, I would not mind adding some guidance for what is a reasonable 
rendering of "minimum available size".  That has become problematic since 
technology has moved on from 1986 (hey ... next year is 20th birthday of 
ANSI CGM standard!).  Extremely high-resolution new devices make that rule 
"quaint", whereas it made some sense 20 years ago.

-Lofton.




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