« SVG on Minimo | Main | 2005-05-09 Weekly Update »
May 3, 2005
2005-05-02 Weekly Update
News:- SVG is now built by default for the Win32 and OS-X firefox tinderboxes. Linux will follow when a problem with the profile driven optimizations is worked out (bug 292377).
- The SVG preference has been enabled by default.
- Bug 290048 - change of <svg:use> attribute not shown
- Bug 290688 - unable to compile XULRunner with SVG
- Bug 291471 - unused code causing svg text to crash on OS-X
- Bug 292054 - don't name firefox svg packages differently
- Bug 292160 - turn on SVG preference by default
- Bug 122092 - enable building SVG support by default
- Bug 163068 - zoom and pan implementation (frontend)
- Bug 267953 - allow text/ecmascript for <svg:script>
- Bug 267657 - clicking on link causes new window to open
- Bug 272630 - make getCTM() behave correctly
- Bug 272885 - disable element rendering if width/height=0
- Bug 280391 - SVGSVGElement.getElementById not implemented
- Bug 287035 - cairo code for compiling without int64 types bitrotted
- Bug 288042 - cairo/svg does not build on qt, xlib
Posted by tor at May 3, 2005 12:03 AM
Comments
Is there a progress table anywhere where we could see what SVG elements have been implemented in recent builds?
Posted by: poynting at May 3, 2005 4:17 AM
I don't think there is a table specifically for the builds but there is one for the status of the SVG implementaion in general. It hasn't been updated in a while so I think it's safe to say all of it is in the builds:
http://www.mozilla.org/projects/svg/status.html
Under the table is a list of exlusions/special cases/limitations/etc with links to the bugs for more details. Hope you find it useful.
Congrats on the progress devs!
Posted by: Geoff at May 3, 2005 6:52 AM
Will svg be enabled by default in the new nightly builds of xulrunner ??
Posted by: Raymond at May 6, 2005 2:52 PM
Looking through your blog I had a perception that some problems, like correct behavior of getComputedTextLength were solved long ago. Though this example behaves differently in ASV3 (correctly) and in Mozilla (gives zero):
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
onload="g_onload()">
<defs>
<script>
<![CDATA[
function g_onload() {
var text = document.getElementById("text")
var len = text.getComputedTextLength()
alert(len)
}
]]>
</script>
</defs>
<text id="text" x="10" y="30">This is a text</text>
</svg>
I would fix it myself, but the structure of sources is so complex, I can not even trace where this error comes from, not even speaking of fixing somthing ;-)
BTW, can samples like this one be included in regression tests and somehow automatically checked in current build/test process?
Thank you for your heroic efforts!
Posted by: Victor at May 7, 2005 6:08 PM
I used to download the mozilla-win32-svg-xtf-webdav-xform-GDI.zip file at the mozilla site. I have noticed that has not been updated for a few days, however, the plain svg-gdi has started being updated nowadays. Will there be any plans to have the xform and svg version updated? I liked that build as I could experiment with learning about xforms as well as using svg. I cannot build one on my computer as it is an old K6-2 500 machine with limited hard disk and ram.
Thanks
Posted by: naddie at May 7, 2005 11:34 PM
I have posted a bug (#292844) where Firefox fails to display two SVG elements side by side. This problem does not occur for Mozilla with native SVG support.
Can this bug be fixed on Firefox?
Posted by: Cheong Tek Mun at May 9, 2005 4:07 AM
Victor: if you want your bug looked at, you should file it in bugzilla and attach the testcase. Things not tracked by bugzilla can get forgotten.
Posted by: tor at May 9, 2005 7:51 PM