Yes both can be merged, I do it time ago but discard the code in favor
Tav, cleanest method to me.
El jue, 25-08-2016 a las 18:21 -0700, Bryce Harrington escribió:
Thanks Tav for investigating this issue and coming up with a
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
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
not being able to determine the Inkscape version, however it sounds
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
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
be to flesh that out into a workable solution? I'm guessing it'll
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 was
> 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
> 'viewBox'? (yn)
> - note that the page size is A4 according to the Document
> Properties dialog,
> and that the red rectangle matches the page border perfectly, as
> - note that the Scale X in Document Properties is 0.9375, which
> 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
> 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.
> actual result is that it is too large by a factor of 96/90,
> 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
> 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
> coordinates are expressed in terms of a coordinate system whose
> is 90 dpi. Therefore it will not be possible to directly compare
> 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
> attacking it at the bottom level of the xml tree by recalculating
> numerical value of the coordinates. There are two alternative
> proposals to
> deal with this problem that should be considered instead. The first
> 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
> coordinates to be consistent with the new dpi. This means that the
> 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
> 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
> 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
> to the current proposed patch. Personally I would vote for the
> 'dpi switcher' simply on the grounds that it appears to be closer
> completion. The point is that either of these alternative
> approaches will
> preserve compatibility with the new trunk version at 96 dpi with a
> of disruption of the basic structure of the svg file.
> rect0485.svg <http://inkscape.13.x6.nabble.com/file/n4976997/rect04
> View this message in context: http://inkscape.13.x6.nabble.com/Doc-
> 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
> J-Flow, sFlow and other flows. Make informed decisions using
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;1326
> Inkscape-devel mailing list
Inkscape-devel mailing list