Re: Have you ever thought about security issues?

> Firefox can render nested markers just fine, as can Batik and ASV.

Yes, it can. It doesn't process overflow="visible" though, it always clips 
it to the viewBox. Try this:

==============================
<?xml version="1.0" standalone="no"?>
<svg width="100%" height="100%" viewBox="0 0 400 400"
     xmlns="http://www.w3.org/2000/svg" version="1.1">

  <defs>
    <marker id="Swallowtail1"
      viewBox="0 0 10 10" refX="4" refY="5"
      markerUnits="strokeWidth"
      markerWidth="4" markerHeight="3"
      orient="auto"
      overflow="visible">
      <g stroke="blue" stroke-width="1.5" fill="none">
         <path d="M 0 0 L 5 5 L 0 10"  marker-start="url(#Swallowtail2)" 
marker-end="url(#Swallowtail2)"/>
      </g>
    </marker>
    <marker id="Swallowtail2"
      viewBox="0 0 10 10" refX="4" refY="5"
      markerUnits="strokeWidth"
      markerWidth="4" markerHeight="3"
      orient="auto"
      overflow="visible">
      <g stroke="blue" stroke-width="1.5" fill="none">
         <path d="M 0 0 L 5 5 L 0 10"/>
      </g>
    </marker>
  </defs>

<path d="M300 100 L 300 200" stroke="blue" stroke-width="8" 
marker-end="url(#Swallowtail1)"/>
<path d="M100 200 L 100 100" stroke="blue" stroke-width="8" 
marker-start="url(#Swallowtail1)"/>
</svg>
=====================================

And compare it with Adobe

> The trunk development of Firefox (not the 1.5 release branch) does
> implement <pattern>, though with some artifacts that seem at first glance 
> to be
> caused by cairo.

I'm working on the Renesis project, see http://gosvg.net
And yes, I can confirm, rendering of patterns is very tricky. In fact, the 
only appropriate way of doing it is to render a raster bitmap and then use 
it as a texture. All other approaches are not effective enough. Just to 
compare:
http://www.gosvg.net/wp-content/photos/pattern12_adobe.png
http://www.gosvg.net/wp-content/photos/pattern12_renesis.png

BTW, another question about FireFox SVG. Why is it so greedy? I have a 700K 
SVG that mostly consists of lines (namely <line> elements), and it consumes 
24 megs (right after start FireFox takes 18 megs, after loading this file it 
eats 42 megs - it's 30x overhead!). And it works terribly slow. I have a 30 
meg SVG file that I'm sure FireFox won't handle.
I can handle those things, for example, that very 30 meg SVG takes about 16 
seconds to parse and 3 seconds to render, with only 40 megs of required 
memory.

I would say, that the native XML DOM that SVG *implicitly* assumes is 
totally useless in practice. A good SVG engine must be based on some custom, 
compact and fast data model.

McSeem

Received on Friday, 11 November 2005 18:01:15 UTC