© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
@JazzyNico
1) This issue of this one (bug #1508400) I would personally consider a blocker for 0.92 unless solved otherwise (e.g. by enforcing a conversion of the document's SVG user unit size based on CSS Pixel size of 1/90 inch to one based on 1/96 inch the first time it is loaded in Inkscape 0.92 - note that this would mean rescaling the content itself, not just adjusting the viewbox, and possible require to introduce some kind of versioning scheme for Inkscape SVG files).
I had chosen a more generic summary line for this report because at the time I felt it more accurately reflected the actual limitation of unit conversions in current inkex.py - its relevancy for 0.92 is high because documents created with <= 0.91 use one such "arbitrary" document scale when opened/viewed in recent trunk / 0.92. The underlying issue relates in general to what was/is discussed in bug #1387864 (tracker bug for 0.91) and #1389723 (tracker bug for 0.92).
I'm aware that the branch proposed for merging has conflicts now (IIRC due to the (partial) PEP8 updates applied in trunk since the original merge proposal was created). I'm also aware that the proposed change is not "elegant" (code-wise) nor really "pythonic", and that - if minimal changes to inkex.py are preferred by the project - someone might be able to work out a simpler solution which just (and only) adds support for documents based on older Inkscape versions (i.e. with SVG user units defaulting to the CSS Pixel size of 1/90 inch).
It's been quite a while since I last looked at the changes proposed for merging, sorry - I kept copies of the same changes in use for some of my custom extensions, but even with those my local testing was rather reduced in the past few weeks or even months.
2) I personally would not consider bug #1474188 a blocker for 0.92 (it would be nice to have that one fixed, too, of course - whatever the chosen solution ends up to be). Bug #1474188 is not such a generic wide-spread issue as this one (bug #1508400) - even if mostly triggered by a bug (already fixed) in 0.91 (which could cause to generate attribute values for the top-level <svg> element not handled well everywhere in current inkex.py IIRC).