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 used in 0.92. This is tracked in the following bug report: https://bugs.launchpad.net/inkscape/+bug/1389723 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 goes away completely. I don't think we should consider reverting the change; it was introduced 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, so if we don't do it this release we'll have to go through all the trouble 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 releases. The other proposed approach would be for Inkscape to internally convert 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 done adequately within the timeframe we're looking at for the release. Both approaches also require a mechanism to detect affected files, which sounds like it may be the tricky part here, as our SVG documents haven't had versioning information we could rely on for this case. Do you have thoughts on other ways to address this issue? Do you have a strong opinion on whether for this release we should use the expedient approach or else postpone the release until the more user-friendly approach can be developed? Or should we reconsider a revert of the DPI switch so we can get the release out and re-enable it post-release in hopes the issues can be worked out? Bryce ------------------------------------------------------------------------------ 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 Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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 used in 0.92. This is tracked in the following bug report: https://bugs.launchpad.net/inkscape/+bug/1389723 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 goes away completely. I don't think we should consider reverting the change; it was introduced 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, so if we don't do it this release we'll have to go through all the trouble 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 releases. The other proposed approach would be for Inkscape to internally convert 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 done adequately within the timeframe we're looking at for the release. Both approaches also require a mechanism to detect affected files, which sounds like it may be the tricky part here, as our SVG documents haven't had versioning information we could rely on for this case. Do you have thoughts on other ways to address this issue? Do you have a strong opinion on whether for this release we should use the expedient approach or else postpone the release until the more user-friendly approach can be developed? Or should we reconsider a revert of the DPI switch so we can get the release out and re-enable it post-release in hopes the issues can be worked out? Bryce ------------------------------------------------------------------------------ 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 Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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 used in 0.92.  This is tracked in the following bug report:   https://bugs.launchpad.net/inkscape/+bug/1389723 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 goes away completely. I don't think we should consider reverting the change; it was introduced 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, so if we don't do it this release we'll have to go through all the trouble 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 releases. The other proposed approach would be for Inkscape to internally convert 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 done adequately within the timeframe we're looking at for the release. Both approaches also require a mechanism to detect affected files, which sounds like it may be the tricky part here, as our SVG documents haven't had versioning information we could rely on for this case. Do you have thoughts on other ways to address this issue?  Do you have a strong opinion on whether for this release we should use the expedient approach or else postpone the release until the more user-friendly approach can be developed?  Or should we reconsider a revert of the DPI switch so we can get the release out and re-enable it post-release in hopes the issues can be worked out? Bryce ------------------------------------------------------------------- ----------- 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;132659 582;e _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

attempting to apply this patch to Inkscape rev 14907 on Windows XP, I get the following compile error: --- compile / cc compile src/file.cpp Make error line 313: problem compiling: In file included from src/style.h:21:0,                  from src/file.cpp:61: src/style-internal.h:522:5: warning: unused parameter 'inherits' [-Wunused-parameter] src/file.cpp: In function 'bool sp_file_open(const Glib::ustring&, Inkscape::Extension::Extension*, bool, bool)': src/file.cpp:310:60: error: 'root' was not declared in this scope -- View this message in context: http://inkscape.13.x6.nabble.com/Doc-sc aling-compatibility-issue-Bug-1389723-tp4976911p4976975.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;132659 582;e _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

sorry about that, the patch applies correctly under Inkscape 0.92pre1 r14965 (Jun  8 2016) some general comments: 1. It would be helpful if it printed out the file name, in case I have forgotten which file I opened.

2. It is not clear what this means: Absolute SVG units in root? false    Does this mean that the page height/width do not contain explicit units?    Or does it mean that these two parameters have not been specified at all, not even the value?    I think it would be better to use the term 'page height/width' or 'page size' 3. It is not clear what this means: User units in root? true    Does this mean that the parameter 'inkscape:document-units' has been specified?    The term 'user units' is not a well-defined concept, so it should be avoided.     A better term is 'inkscape:document-units' since this is unambiguous.

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/rect0485.svg> Cheers, Alvin -- View this message in context: http://inkscape.13.x6.nabble.com/Doc-scaling-compatibility-issue-Bug-1389... 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 Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel ------------------------------------------------------------------- ----------- _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel ------------------------------------------------------------------- ----------- _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel