Attached is a patch that attempts to handle the conversion from 90dpi
to 96dpi for old Inkscape files. It is not a complete patch as it
relies on the command line to ask users if they wish to update a file
that has been detected to be old. But before I work on it more, I would
like to get feedback on how well it works.
What it does:
* Detects if a file has an Inkscape version less that 0.92. (Might need
some tweaking as 0.91devel files should already be 96dpi.) If so:
** Checks to see if absolute units were used for the root 'width' and
'height' attributes. If so:
*** Asks user if they wish to add 'viewBox' to restore '90dpi'.
** Checks to see if user units were used for the root 'width' and
'height' attributes. If so:
*** Asks user if the width/height were meant to be fixed to a
particular real-life size and if they wish to scale the drawing and add
a 'viewBox" to correct.
* Adjusts guides if necessary. <-- May need more work.
* Adjusts grids if necessary. <-- May need more work.
No attempt is made to adjust perspectives or font-sizes in 'pt'.
If you find files that are not fixed properly or are fixed wrongly,
please attach them to bug 1389723.
On Sun, 2016-06-05 at 12:59 -0700, Bryce Harrington wrote:
What do you think we should do about the release-critical DPI bug?
We need a decision on a course of action.
One of the changes we're bringing in this release is changing the
definition of px from 90 dpi to 96 dpi, but a consequence of this is
that documents created in 0.91 or earlier will become mis-scaled if
in 0.92. This is tracked in the following bug report:
This is a release-critical bug, the sort that is likely to become a
thorn in our side in the near to mid term as users start running into
it more and more. Longer term it will diminish as our users move to
newer versions, but I imagine it'll take multiple years before it
I don't think we should consider reverting the change; it was
pretty early on this development cycle so backing it out could cause
secondary bugs to crop up. Also, it's a change that has to be done,
if we don't do it this release we'll have to go through all the
again next release anyway.
One proposed approach is to detect the affected files on load and
display a warning with a recommendation to convert the file manually.
Javier has posted a conversion tool that could be made use of; it's
received a fair bit of testing but there may be some remaining corner
cases to sort out; on the plus side with it being a discrete utility
fixes could be rolled out for it without needing full Inkscape
The other proposed approach would be for Inkscape to internally
files, so that no warning is needed. In theory this would provide a
better user experience, but is going to require a lot more developer
effort and thorough testing. I'm doubtful that all of this can be
adequately within the timeframe we're looking at for the release.
Both approaches also require a mechanism to detect affected files,
sounds like it may be the tricky part here, as our SVG documents
had versioning information we could rely on for this case.
Do you have thoughts on other ways to address this issue? Do you
strong opinion on whether for this release we should use the
approach or else postpone the release until the more user-friendly
approach can be developed? Or should we reconsider a revert of the
switch so we can get the release out and re-enable it post-release in
hopes the issues can be worked out?
What NetFlow Analyzer can do for you? Monitors network bandwidth and
patterns at an interface-level. Reveals which users, apps, and
consuming the most bandwidth. Provides multi-vendor support for
J-Flow, sFlow and other flows. Make informed decisions using
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659
Inkscape-devel mailing list