Closed Bug 269482 Opened 20 years ago Closed 16 years ago

Allow <svg:use> to reference elements in other documents

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jwatt, Assigned: bzbarsky)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(1 file)

use #carrot
338 bytes, image/svg+xml
Details 
 
tried to change 'elements' to 'symbols' in Summary, hope this is more nearly the
intention.

But it wont let me :-) so please would you consider this?
The 'use' element is allowed to reference  'svg', 'g', graphics elements and
other 'use' elements as well as 'symbol' elements.
well how about putting that in the Summary?

point being that search might find it. element seems a bit broad as a search
term in this context.
This feature is very useful for reducing the size of SVG files when there are some re-usable elements.  
I am developing a mapping website that generates dynamic maps in SVG format according to user-defined study areas, geographic units, and mapping variables.  I use the <svg:use> tag extensively to reference geometries that are defined in other SVG files.  This saves retrieving spatial data from database and writing geometry coordinates into the map files.
Batik supports this feature and hopefully we can see it in the next release of FireFox.  
Thanks.

(In reply to comment #2)
> The 'use' element is allowed to reference  'svg', 'g', graphics elements and
> other 'use' elements as well as 'symbol' elements.
This bug is over two years old, are there any plans to fix it??

I've a project on hold, but in development that would be considerably enhanced etc etc....

a time guide would be helpful
oops
This bug is over 12 months old, are there any plans to fix it??

I've a project on hold, but in development that would be considerably enhanced
etc etc....

a time guide would be helpful
if a bug isn't assigned to someone then it has no timetable
What would be required to pull this off?
The things I can think of, which are probably a small subset of what's needed, are:

Load the required external documents and stylesheets (but not more than once) and manage the document-style set pairs (or do you need more than just those two?).

Use the appropriate style set and parent style context when resolving style and constructing frames

Make sure that everything that uses base URIs or URIs for security domains uses the correct one (and for the latter, correct may vary by use), and that our APIs properly reflect what's going on.

Figure out whether actual content-cloning is needed, what document pointers the content should have, and what GetCurrentDoc and GetOwnerDoc should return for the content.  And then audit all the code in Mozilla to make sure you're not breaking assumptions that it makes (which you probably will be no matter what you do).
Are there any plans to implement this features soon?
I submitted the duplicate bug yesterday, sorry.  I tried searching for SVG and use with various additional keywords link xlink, href, external, etc.  I figured there couldn't be a demonstration of the problem without those keywords. Since none of those keywords appear in this discussion, I thought mentioning them might help future searches.

So...  The bug really is well over two years old now.  And just like the earlier poster, I'm developing an application that's just begging for this feature. I had assumed that if I reported it, it would get fixed eventually, and I could just do the stupid thing in my application in the meanwhile. I now see that reporting it may not be sufficient to get it fixed.  Can someone in the know at least describe in more detail why it's hard to fix, and if anyone's trying to?

The list above gives me some idea, but I don't know enough about Gecko's internals to really understand what they mean in terms of effort -- or which one is the primary problem.  Loading the external document doesn't sound that tough. Merging the style sets could be difficult I guess depending on how that is written.  I definitely see where the security issue could get thorny, and that's what I assumed was the real problem.  But is there an easier solution for local xulrunner apps? That would be enough to take care of my needs.  And finally, the audit seems very difficult, but not that different from a lot of bug fixes similar to this one.

I'd be happy to help (I'm a competent C/C++ programmer) but to be honest I know so little about the Gecko core, that it would probably wouldn't make sense.  I'm not trying to cause trouble, just understand whether this bug will ever be fixed.

yah well...

people who use symbols to communicate would really benefit from this.

in particular if authors and users could reference a local library....

it's an issue not unrelated to fonts, and languages such as chinese that use ideograms

but priority does seem to be extremely low


I've got something vaguely resembling a work-around.  Jonathan, I hope this helps you as well, but I doubt it.  Of course it's a total hack, and is probably going to have very bad memory consumption side effects but at least it'll solve my problems managing a dozen duplicate SVG definitions of the same object for a while.  Basically it boils down to:

var svgdefs = doc1.getElementById("svgdefs");
doc2.documentElement.appendChild("svgdefs");
var myuse = doc2.createElementNS("http://www.w3.org/2000/svg", "use");
myuse.setAttributeNS("http://www.w3.org/1999/xlink", "xlink:href", "#myrect");
doc2.documentElement.appendChild(myuse);
...

Since I was building my second (and 3rd, and 4th, ...) documents dynamically anyway, it's no great hardship to begin by copying the defs from the "master" document.

The reason I post this here is I'm wondering if it has any impact on how the problem could/would be fixed. Could a similar approach be built into the Core?  Does it result in a "copy" of the defs as I suspect, or a link?  Wouldn't it be better to provide "correct" results even if they didn't have the expected performance benefits?  Is there some obvious way in which my work-around is broken that I haven't detected yet?  Does the fact that this appears to work in anyway make the problem easier to fix?






off topic, for some at least ~:"

Red bus - green bus
and the concept coding framework:
http://www.wwaac.eu/products/ccf.asp

the underlying issue that needs to be addressed is that individuals use different ideograms for the same concept.
this is related to the issue of user style sheets, and users preferred CSS fonts.

users need a means to update their libraries of symbols.
authors, which includes users may need to advise others that a particular symbol may have a priviliged status.

The example I gave in 2002 relates to a user who fails to generalise a symbol of  a red bus as a bus. They have learnt to use a green bus symbol.
If the bus today is going to be a different colour, we need a means to explain this change, that will benefit the recipient.
similarly if we are only referring to a general bus, the local symbol library version will be sufficient: "Do you go to school on a bus?" and usually easier to interpret. 

in order to make progress on understanding the issues we need a simple way to copy and paste (SVG) ideograms.
https://bugzilla.mozilla.org/show_bug.cgi?id=334801

until these 2 bugs are resolved....
parity Opera
http://files.myopera.com/MacDev_ed/sarpsborg2007/external-use.svg

does this bug need a testcase or description?
Parity Amaya

SVG microformat for icons:
http://www.gnote.org/svgSearch/requirements.html

Authoring Tool Guidelines to follow shortly
Parity Batik,

webkit just raised the priority of this bug today.
https://bugs.webkit.org/show_bug.cgi?id=12499

http://www.openicon.org a search engine for SVG graphics relies on <use> external

openclipart.org and inkscape output are stymied because this has not been
implemented.
It's pretty close to impossible to search svg as graphic unless one understands
and implements <use>.
http://www.openicon.org/icon-ark/weather-icons.svgz
18 icons in 2.3K
42 months later:

this is part of the spec, and a really critical part for many potential users, whilst cutting bandwidth, which is vital for people in the third world.
I have a terrible workaround, but it may be useful.
The xul-overlay mechanism can be used to incorporate svg:defs.

e.g.
defs.xul
<?xml version="1.0" encoding="utf-8"?>
<xul:overlay  xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
              xmlns:svg="http://www.w3.org/2000/svg"
              xmlns:xlink="http://www.w3.org/1999/xlink">

  <svg:defs id="mydefs">
   <svg:rect id="abox"
              x="-150" y="-100" width="300" height="200"
              fill="cyan" stroke="black" stroke-width="8" />
  </svg:defs>
</xul:overlay>

main.xul
<?xml version="1.0"?>
<?xul-overlay href="file://.../defs.xul"?>
<xul:window  xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
             xmlns:html="http://www.w3.org/1999/xhtml"
             xmlns:svg="http://www.w3.org/2000/svg"
             xmlns:xlink="http://www.w3.org/1999/xlink">
  
  <svg:svg version="1.1" width="100" height="100">
        <svg:defs id="mydefs"/>
        <svg:use xlink:href="#abox" 
                       x="200" y="200"  transform="scale(0.2)"/>
              
  </svg:svg>
</xul:window>

I know, not too bad if you are creating a XUL application but otherwise, yuk!
Even then it can only be overlayed once.
Attached image use #carrot — 

    
    

    
  
practical example: http://www.openicon.org/irc/ircwithIcon.svg

follows irc://irc.freenode.net/#svg and appends an icon for each word, where available.
URL: http://www.w3.org/Graphics/SVG/Test/2...
Keywords: testcase

    
    

    
  
#23 please use http://www.openicon.org and follow the links
wfm Opera

    
    

    
  
I believe this was fixed as part of bug 433616.

These testcases look good:
layout/reftests/svg/use-01-extref.svg
http://www.w3.org/Graphics/SVG/Test/20061213/htmlEmbedHarness/full-struct-use-05-b.html

For now, both files must be on the same domain. http://developer.mozilla.org/web-tech/2008/10/10/svg-external-document-references/
Assignee: general → bzbarsky
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED

    
  
Depends on: 433616

    
    

    
  
Yeah, this is fixed for same-domain references.  We don't plan to ever support <use> across origin boundaries, to be honest: there are some serious security issues with it, at least in Gecko's implementation of <use>.
Flags: in-testsuite+

    
    

    
  
Not even with access-control?

    
    

    
  
Access-control protects the target of the <use>.  The security issues are for the document the <use> is in.  So access-control doesn't help.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: