Should i push to lp:inkscape/0.91.x?
Hi folks,
I was getting troubles with extensions on Illustrator generated SVGs, so i solve it and send to the repo: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14564 That means trunk = the future 0.92.x
As i'm away for a while i must ask: Should i push this patch to lp:inkscape/0.91.x? I believe yes, but i don't know the rules to push on a stable branch.
Thanks!
On 2016-01-06 23:44 (+0100), Aurélio A. Heckert wrote:
I was getting troubles with extensions on Illustrator generated SVGs, so i solve it and send to the repo: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14564 That means trunk = the future 0.92.x
As i'm away for a while i must ask: Should i push this patch to lp:inkscape/0.91.x? I believe yes, but i don't know the rules to push on a stable branch.
Would you mind sharing a test case and steps to reproduce? Which extensions fail without the commit, and how exactly?
I do have a merge proposal pending (for review) for document-scale related issues [1], and would appreciate any further test cases which possibly are not handled correctly yet with the proposed changes for retrieving the document scale.
Regards, V
[1] https://code.launchpad.net/~inkscape.dev/inkscape/extensions-svgunitfactor/+...
On 06-01-2016 21:58, su_v wrote:
Would you mind sharing a test case and steps to reproduce? Which extensions fail without the commit, and how exactly?
Sure!
A designer send me many SVGs with this header: <?xml version="1.0" encoding="utf-8"?> <!-- Generator: Adobe Illustrator 18.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 1171.9 593" enable-background="new 0 0 1171.9 593" xml:space="preserve">
You may noticed the missed width and height definition. That crashes getDocumentUnit() at inkex.py because *svgwidth* become *None*. The getposinlayer() also have a problem trying to read undefined height from documentRoot.
That should crash third part extensions on the world (/like local garbage here/), as it directly crashes the official extractimage.py and plotter.py. There is a non direct call of getDocumentUnit() and getposinlayer() by all inkex based extensions, so I can say that missed attributes on documentRoot is crashing all extensions on getDocumentUnit(), because it is called by affect(), the mandatory extension method.
I do have a merge proposal pending (for review) for document-scale related issues [1], and would appreciate any further test cases which possibly are not handled correctly yet with the proposed changes for retrieving the document scale.
I hope this 2¢ helps. :-)
Cheers!
Regards, V
[1] https://code.launchpad.net/~inkscape.dev/inkscape/extensions-svgunitfactor/+...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2016-01-07 18:10 (+0100), Aurélio A. Heckert wrote:
On 06-01-2016 21:58, su_v wrote:
Would you mind sharing a test case and steps to reproduce? Which extensions fail without the commit, and how exactly?
Sure!
A designer send me many SVGs with this header:
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 18.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 1171.9 593" enable-background="new 0 0 1171.9 593" xml:space="preserve">
You may noticed the missed width and height definition. That crashes getDocumentUnit() at inkex.py because *svgwidth* become *None*. The getposinlayer() also have a problem trying to read undefined height from documentRoot.
These types of crashes in python-based extension scripts had already been addressed earlier in trunk (and the fix backported to the stable release branch for 0.91.1) - they had been reported multiple times in the bug tracker, and are tracked for width and height separately in
https://bugs.launchpad.net/inkscape/+bug/1461346 https://bugs.launchpad.net/inkscape/+bug/1463623
Seems that we now have a double-fix committed in trunk for the same issue ;-) I'll probably better revert the fixes committed earlier - AFAICT the remaining issue which the solution in your latest commit improves is getting a more correct view-center for such documents (by falling back to viewBox values if the width and height attributes are not present).
Thanks for the clarification [1].
Regards, V
participants (2)
-
Aurélio A. Heckert -
su_v