Hi, Chris-

Chris Lilley wrote:
|
| DS> Problem 2: There is no specified behavior for how 
| fragment IDs are 
| DS> to be treated in SVG. There are many options (it might 
| translate the 
| DS> view so that the element is in the top left of the screen, or the 
| DS> exact center of the screen, or just enough so that it is 
| visible, or 
| DS> it might even change the viewBox so that the element fills up the 
| DS> screen).
| 
| Right. It just has to make the linked-to object visible.

Just to clarify, by "linked-to object" you mean the element bearing the
specified id element and not just the whole document, right? Because from my
reading of "17.2.2 SVG fragment identifiers", there is no requirement to
make the id-element (the fragment identifier) visible.  It says:
 "If the SVG fragment identifier addresses any element other than a 'view'
element, then the document defined by the closest ancestor 'svg' element is
displayed in the viewport using the view specification attributes on that
'svg' element." 

So, if you have a link to 'myfile.svg#myId', if the nearest 'svg' element to
'myId' is the root, and 'myId' is a rect at, say, y='1000' and is outside
the viewport/viewBox, it won't be visible.

Personally, I think that the SVG Spec should specify that 'myfile.svg#myId'
is assumed to be an implicit view that includes the id-element. Much more
intuitive, and the outlier cases are miniscule. When *wouldn't* you want
such behavior? Of course, if the element doesn't have a rendered bbox (say,
in the case of display='none'), it shouldn't attempt change the viewport.


| DS> All of these behaviors are specified for the 'SVG view 
| DS> specification' [2], using syntax like 
| DS> MyDrawing.svg#svgView(viewBox(0,200,1000,1000)), but as far as I 
| DS> know, no viewer has yet imlemented that.
| 
| Its implemented by Batik and by CSIRO.
| 
| (Of course, it could have been implemented by ASV and Corel 
| too, in theory, but we wouldn't know because of the browser 
| those are hosted in).
| 
| DS> This is a real pity, because that rocks. Man... No, instead, all 
| DS> viewers I know about simply ignore the fragment-id.
| 
| Yes, it is. (I would have thought you would be familiar with Batik)

Oh, yeah... I think I heard about that... "Batik," you say? I'll have to
write that one down... ;)

I've got to confess, I didn't check Batik, because I concentrate mostly on
common Web browsers for tasks like this. I meant that it's unimplemented in
ASV, Firefox, and Opera. Thanks for setting me straight.

It does work, as you say, in Batik, but there's a bit of odd behavior... in
the location bar, the fragment identifier is doubled. For instance, 
 svg2.svg#svgView(viewBox(200,200,100,100))
becomes:
 
svg2.svg#svgView(viewBox(200,200,100,100))#svgView(viewBox(200,200,100,100))

No big deal, but I guess I'll file a bug report. BTW, seeing this in action,
it really does rock, as predicted.


Regards-
Doug

[EMAIL PROTECTED]
www.vectoreal.com ...for scalable solutions.
 



------------------------ Yahoo! Groups Sponsor --------------------~--> 
1.2 million kids a year are victims of human trafficking. Stop slavery.
http://us.click.yahoo.com/.QUssC/izNLAA/TtwFAA/1U_rlB/TM
--------------------------------------------------------------------~-> 

-----
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click "edit my 
membership"
---- 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/svg-developers/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to