Thanks Tav for investigating this issue and coming up with a proposed
solution. And Alvin thanks identifying a third option of reusing
Unfortunately, this remains an open issue and is now the principle
blocker for the 0.92 release. I'm not sure what approach we should be
focusing on, and I'd like to see more discussion towards a near-term
plan for addressing this.
Alvin makes a good point that Javier's python tool approach is the
furthest along. It sounds like one of the stumbling blocks for it was
not being able to determine the Inkscape version, however it sounds like
Tav's approach included a method for doing this; is it possible that
piece of Tav's work could be used to resolve the issue in Javier's tool?
I'd also like to hear what other issues remain for getting the python
tool production ready enough that we could close this bug and proceed
wrapping up 0.92?
Regarding SPGroup::scaleChildItemsRec, how hard / how much work would it
be to flesh that out into a workable solution? I'm guessing it'll take
more than a trivial amount of effort, but if it is indeed a good
solution perhaps that could be worked on in trunk to provide a more
robust solution down the road (0.93+)?
On Thu, Jun 09, 2016 at 05:07:25AM -0700, alvinpenner wrote:
the proposed scaling fix was tested using the file rect0485.svg which
originally used in Bug 1389723, comment 4
This file contains a single red rectangle, created in Inkscape 0.48.5, which
perfectly matches the border of an A4 page.
- For the test, I open this in current trunk with the proposed patch, in
- answer yes to the question: Do you wish to scale the drawing and set
- note that the page size is A4 according to the Document Properties dialog,
and that the red rectangle matches the page border perfectly, as hoped.
- note that the Scale X in Document Properties is 0.9375, which equals
90/96, which suggests that the viewbox has been re-defined during the load
of the file.
- now try to re-create this red rectangle by drawing a new rectangle from
- draw an arbitrary rectangle using the mouse
- open the XML editor and select the new rectangle.
- set x and y = 0
- set width = 793.70081, height = 1122.5197, where these numbers are taken
directly from the page width/height in the root element. These are the
numbers appropriate for an A4 page at 96 dpi.
- the resulting document is attached here. The expected result was that the
new rectangle would be the same size as the original red rectangle. The
actual result is that it is too large by a factor of 96/90, apparently
because the viewbox has been re-defined by the proposed patch.
- what this means, in effect, is that in the future it will not be possible
to manually edit or inspect this document in any meaningful way because the
document units have been re-defined so that the native resolution in the
file is no longer 96 dpi but is now 90 dpi. That is to say, all numerical
coordinates are expressed in terms of a coordinate system whose resolution
is 90 dpi. Therefore it will not be possible to directly compare this
document's coordinates to a different document that did not have this patch
applied. This is a serious incompatibility for those people who are
developing or using third party software to interface with Inkscape, or for
anyone who wishes to manually edit a file.
The basic problem with this approach is that it attempts to correct the
situation at the top level of the document tree structure rather than
attacking it at the bottom level of the xml tree by recalculating the
numerical value of the coordinates. There are two alternative proposals to
deal with this problem that should be considered instead. The first proposal
is the Python extension 'DPI switcher' by Jabiertxo. See Bug 1389723 and the
file dpiswitcher.py in Inkscape rev 13696. As I understand it, this
extension walks through the entire xml tree and recalculates all the
coordinates to be consistent with the new dpi. This means that the revised
document will be transparently the same as if it had been created in trunk
at 96 dpi in the first place, which is the desired result. This approach was
ultimately abandoned, but I believe the main reason for abandoning it was
that the Python extension was not able to automatically determine the
Inkscape version of the original file, which meant that the user would have
to make a manual decision as to whether to apply the scale change or not.
This is in my opinion a relatively minor inconvenience, not exactly a design
defect, not sufficient reason for abandoning the method.
The second approach to consider is the routine
SPGroup::scaleChildItemsRec by Matthew Petroff in the file
sp-item-group.cpp. This uses the same approach of walking the entire tree to
modify the coordinates at the bottom-most level. This was originally
developed for the purpose of switching document units, not switching dpi,
but it could probably be modified for the current purpose.
I think that these two approaches should be considered as alternatives
to the current proposed patch. Personally I would vote for the Python-based
'dpi switcher' simply on the grounds that it appears to be closer to
completion. The point is that either of these alternative approaches will
preserve compatibility with the new trunk version at 96 dpi with a minimum
of disruption of the basic structure of the svg file.
View this message in context:
Sent from the Inkscape - Dev mailing list archive at Nabble.com
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
Inkscape-devel mailing list