Re: WebCGM preview

[Dieter@isodraw.de (Dieter Weidenbrueck)]

Lofton,

 

I looked at the two paras and compared them. Here is the result:

 

Table of Object Behaviors, compiled from 3.1.2.4. and 3.2.1.1.

Attributes:		Fragments:
Object has	and	#myObj (default behavior)	#id(myObj,view_context)	#id(myObj,highlight)	#id(myObj,highlight_all)
view_context	region	zoom to view_context rectangle (3.2.1.1.)	zoom to view_context AND highlight (3.1.2.4.)	shrink to fit and highlight first object (3.1.2.4.)	shrink to fit and highlight all objects (3.1.2.4.)
view_context	no region	zoom to view_context rectangle (3.2.1.1.)	zoom to view_context AND highlight (3.1.2.4.)	shrink to fit and highlight first object (3.1.2.4.)	shrink to fit and highlight all objects (3.1.2.4.)
no view_context	region	"move" object into view (3.2.1.1.)	same as #id(myObj,highlight) (3.1.2.4.)	shrink to fit and highlight first object (3.1.2.4.)	shrink to fit and highlight all objects (3.1.2.4.)
no view_context	no region	"move" object into view and highlight in some way (3.2.1.1.)	same as #id(myObj,highlight) (3.1.2.4.)	shrink to fit and highlight first object (3.1.2.4.)	shrink to fit and highlight all objects (3.1.2.4.)

 

3.2.1.1. defines the default behavior only, it doesn’t apply as soon as the fragment contains a specific object behavior.

 

Object behaviors in general

I suggest we understand the behaviors as follows:

-        if view_context is used the intention is to NAVIGATE TO the object. In my humble opinion this means to move the object(s) into view and zoom into the illustration to make them the dominant part of the viewer rectangle. If the object has a view_context attribute this is what happens, however, if there is no view_context attribute I suggest we keep the behavior as close as possible to the one using a view_context.

-        If highlight (highlight_all) is used the intention is to SHOW the object(s) and visually discriminate it (them) from others.

 The following table shows in red the suggested changes.

Attributes:		Fragments:
Object has	and	#myObj (default behavior)	#id(myObj,view_context)	#id(myObj,highlight)	#id(myObj,highlight_all)
view_context	region	zoom to view_context rectangle (3.2.1.1.)	zoom to view_context AND flash (3.1.2.4.)	shrink to fit and highlight first object (3.1.2.4.)	shrink to fit and highlight all objects (3.1.2.4.)
view_context	no region	zoom to view_context rectangle (3.2.1.1.)	zoom to view_context AND flash (3.1.2.4.)	shrink to fit and highlight first object (3.1.2.4.)	shrink to fit and highlight all objects (3.1.2.4.)
no view_context	region	Zoom to object region such that the region fills a significant part of the viewer rectangle (3.2.1.1.)	Zoom to object region such that the region fills a significant part of the viewer rectangle and flash region (3.1.2.4.)	shrink to fit and highlight first object (3.1.2.4.)	shrink to fit and highlight all objects (3.1.2.4.)
no view_context	no region	Zoom to object primitives such that the enclosing rectangle fills a significant part of the viewer rectangle (3.2.1.1.)	Zoom to object primitives such that the enclosing rectangle fills a significant part of the viewer rectangle and flash region (3.1.2.4.).	shrink to fit and highlight first object (3.1.2.4.)	shrink to fit and highlight all objects (3.1.2.4.)

This would accomplish the following:

-        remove differences between default behavior and view_context behavior. 3.2.1.1. could actually point to 3.1.2.4 from then on

-        clarify the “move into view” expression in 3.2.1.1

The term "flash" suggests some kind of highlighting different to the one used in the "highlight" cases.

 

Let me know what you think,

 

Dieter

 

----- Original Message -----

From: "Lofton Henderson" <lofton@rockynet.com>

To: "Dieter" <dieter@itedo.com>; <cgmopen-members@lists.oasis-open.org>

Sent: Tuesday, May 29, 2001 6:07 PM

Subject: Re: WebCGM preview

> At 05:04 PM 5/29/01 +0200, Dieter 
Weidenbrueck wrote:
> >[...]
> >Comments:
> 
> 
>1. The wording is a bit confusing:
> 
> Tell me about 
it!!!
> 
> >For an object that has a view_context 
attribute
> >- 3.1.2.3 suggests both navigation AND highlight plus a 
default behavior
> >(highlight)
> >- 3.2.1.1 suggests 
navigation only
> >This should be made consistent.
> 
> I 
agree.  We have talked to Chris and will delay Second Release for another 
> week or so, while we straighten it out.
> 
> >The 
combined navigation and highlighting of course only works if there is a
> 
>body, i.e. if graphical primitives exist.
> >Also the last sentence 
of the view_context para should read
> >"The view_context behavior is 
the default behavior."
> >The current language is probably misleading 
with regard to the highlight
> >statement right before the "This 
is...".
> 
> Yes, I noticed the same and it bothered me as 
well.
> 
> 
> >It becomes obvious that the viewer behavior 
leaves a lot of room for
> >interpretation. The requirement "... moves 
the object into view" for example
> >is met in your example, because a 
shrink-to-fit representation does of
> >course show the object. 
However, this example really doesn't show the
> >difference between 
highlight and view_context.
> >IsoView will move the object into view 
and zoom into the illustration so
> >that the object becomes the 
dominant part in the viewer rectangle.
> 
> I want to call attention 
to a 2nd Release clarification which is already in 
> the draft 2nd 
Release text, and which was discussed several times (and 
> finalized, I 
think, either at the 6/00 Autotrol meeting or the 12/00 DC 
> 
meeting):
> 
> The third bullet, at the end of 3.2.1.1, now 
reads:
> 
> "If the object contains neither a view context nor a 
region attribute, the 
> viewer shall move the object into view and 
indicate
> visually that the graphical primitives of the grobject are the 
target of 
> the link. The manner in which the viewer creates the 
new
> display is viewer dependent. The resulting view is a full-picture 
view, not 
> a zoomed view."
> 
> Note the new last sentence 
to this paragraph, clarifying the ambiguity 
> which you noted 
above.
> 
> (Note.  I see no problem with offering different 
behaviors as viewer 
> options.  But the viewer has to be capable of 
the specified behavior, and 
> it should be the default, in the absence of 
user option setting.)
> 
> 
> >BTW, we recently decided to 
use lowercase for all attributes/tag names.
> >Throughout the spec 
almost all possible variants of "view_context",
> >"linkuri" etc are 
used. Will we adjust the spelling in the spec to lowercase
> >as 
well?
> 
> Yes, I will work with Dave to make it as consistent as 
possible.  Note that 
> we never had any problem with the 
"view_context", which is a *value* of the 
> object behavior parameter (of 
the fragment).  But it does get confusing 
> because we refer 
to:
> 
> 1. "ViewContext" -- as a generic term for the view context 
concept.
> 2. "ViewContext" -- as the value of the APS attribute 'type' 
parameter, 
> indicating a view context APS attribute.
> 3. 
'viewcontext' -- as the value of the APS attribute 'type' parameter, 
> 
indicating a view context APS attribute.
> 4. "view_context" -- as a 
possible value for the object behavior bit of the 
> fragment.
> 
> Anyway, we'll sort it out.
> 
> -Lofton.
>