[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior revert to full-picture view?
Lofton, see inline > -----Original Message----- > From: Lofton Henderson [mailto:lofton@rockynet.com] > Sent: Monday, June 13, 2005 2:42 PM > To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org > Subject: RE: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior > revert to full-picture view? > > > At 08:32 AM 6/10/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote: > >[...] > > > ii.) The 'highlight' keyword is useless. When a program or an > > > XCF issues a > > > 'highlight' behavior, it has no way of knowing what is the present > > > view. Another DOM or WebCGM or XCF transaction may have > changed it. Or > > > the user may have panned/zoomed the picture with viewer > controls. It is > > > unknowable, in general, whether the target to be highlighted is > > > visible. Therefore, no one would risk using 'highlight' (or > > > 'highlight_all'). Only 'move_highlight' or 'zoom_highlight' have any > > > usefulness. > >It is not useless in my eyes, it becomes much more powerful now. So far, > >users rarely used this keyword because of the unwanted > navigation effects. > >Combinations with navigation are well defined now, so highlight > is reserved > >for the cases where the implementor well knows what he is doing. > > Did you indeed mean "implementor"? To me it seems like an issue for > users/content creators. What content creator would use such a > non-navigating "full" keyword in a hyperlink fragment, without any way to > know how the user may have moved the view with the viewer > controls? If the > content creators and other users cannot trust the result, who > would use "full"? Sorry, I meant the implementor of an IETM, hence a content creator. There are many use cases for this, e.g. in scenarios where the viewer is set to "fixed" in the OBJECT tag, but also in others. I think a strict separation of the behaviors highlight, move, zoom, full is very useful to clarify the actual behavior. Have a look at the following sequence: abc.cgm#id(myView,zoom) abc.cgm#name(myFirstObj,highlight) abc.cgm#name(mySecondObj,highlight) abc.cgm#id(myThirdObj,highlight) (assumed that the three objects are inside the rect established by myView). Typical thing that you can't do in other ways unless you start playing a lot with multiple name attribute on objects. > > [Btw, this is ignoring for the moment the "new wrinkle" (issue) I pointed > out yesterday, that the current picture-behavior wording of the spec does > not seem to support successive object behaviors being cumulative, > even with > intra-CGM links in the same file.] I will answer that one separately. > > -Lofton. > > Cheers, Dieter
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]