Re: Have you ever thought about security issues?

On 11/11/05 12:01 PM, Maxim Shemanarev wrote:
>> 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:
> 
> ==============================
> [munch]
> =====================================
> 
> And compare it with Adobe

Thanks for the bug report.  This example will work if you use 
style="overflow: visible;" instead of overflow="visible".  We just 
forgot to map the PresentationAttributes-Viewports attributes of 
<marker> to the CSS.

> 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

We do take the approach of rendering a repeat cell and using it as a 
texture (pattern in cairo terms).  However that still leaves a number of 
variables that will influence the rendering quality, such as what 
resolution to render the tile, the transform space the cell is rendered 
in, and what filtering is used for sampling the texture/pattern.

> 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.

The memory usage by Firefox SVG is caused by a mismatch of gecko's 
content/frame/style model with SVG, a direct mapping of the SVG DOM for 
our data model, and some duplication of existing gecko functionality in 
the SVG codebase.  All of these issues are being looked at as we move 
forward in development.

I would like to get access to your large SVG test files for development, 
if you can make them available.

Thanks.

-tor

Received on Friday, 11 November 2005 18:30:06 UTC