I do a mixed option with some TAV code and runing the extension. https://bugs.launchpad.net/inkscape/+bug/1389723/comments/78
Cheers, Jabier.
El jue, 25-08-2016 a las 18:21 -0700, Bryce Harrington escribió:
Thanks Tav for investigating this issue and coming up with a proposed solution. And Alvin thanks identifying a third option of reusing SPGroup::scaleChildItemsRec's functionality.
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+)?
Thanks, Bryce
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 https://bugs.launchpad.net/inkscape/+bug/1389723 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 DOS.
- answer yes to the question: Do you wish to scale the drawing and
set '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 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 scratch.
- 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.
rect0485.svg http://inkscape.13.x6.nabble.com/file/n4976997/rect04 85.svg Cheers, Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Doc- scaling-compatibility-issue-Bug-1389723-tp4976911p4976997.html 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;1326 59582;e _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel