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
Is this related to why flowed text line spacing sometimes freaks out when loaded? It's been really messing me up lately.
For an example, load this file: https://www.dropbox.com/s/3f43lyrr494m8cm/testfile.svg?dl=0
and try to change the line spacing in the text box.
Works okay in 0.91 stable and not at all in current trunk.
-C
On Sun, Jun 5, 2016 at 8:59 PM, Bryce Harrington <bryce@...961...> 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 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 2016-06-05 at 23:46 +0100, C R wrote:
Is this related to why flowed text line spacing sometimes freaks out when loaded? It's been really messing me up lately.
For an example, load this file: https://www.dropbox.com/s/3f43lyrr494m8cm/testfile.svg?dl=0
and try to change the line spacing in the text box.
Works okay in 0.91 stable and not at all in current trunk.
It's definitely not doc scaling that is causing this problem.
What is more likely is that Inkscape now respects the 'strut' value in the block element per CSS. In plain English, that means that the minimum spacing between lines is defined by the <text> or <flowtext> element that wraps all the text. The minimum spacing is the value of the 'line-height' property times the value of the 'font-size' property. There was a comment in the code saying that this was not implemented in Inkscape because none of the browsers were doing it this way... but that was a long time ago. All the browsers now implement this correctly according to CSS (at least for HTML since SVG 1.1 doesn't have multi- line text).
CSS line spacing is definitely a mess (and the CSS group seems to recognize it). But having a strut value is useful as it means being able to define a well know spacing between the lines (see: http://tavmj ong.free.fr/blog/?p=1632 ).
The problem for Inkscape is how can the user know what is the value of the 'strut' and how can they change it? We definitely need a better interface. I would consider this a blocker.
And we need to be able to control how CSS properties are written into the SVG file; at the moment writing a property into a block element causes the property to be written into all the children elements which is not really desirable in many cases.
Tav
On Mon, Jun 06, 2016 at 04:27:25PM +0200, Tavmjong Bah wrote:
...Inkscape now respects the 'strut' value in the block element per CSS. In plain English, that means that the minimum spacing between lines is defined by the <text> or <flowtext> element that wraps all the text. The minimum spacing is the value of the 'line-height' property times the value of the 'font-size' property. There was a comment in the code saying that this was not implemented in Inkscape because none of the browsers were doing it this way... but that was a long time ago. All the browsers now implement this correctly according to CSS (at least for HTML since SVG 1.1 doesn't have multi- line text).
CSS line spacing is definitely a mess (and the CSS group seems to recognize it). But having a strut value is useful as it means being able to define a well know spacing between the lines (see: http://tavmj ong.free.fr/blog/?p=1632 ).
The problem for Inkscape is how can the user know what is the value of the 'strut' and how can they change it? We definitely need a better interface. I would consider this a blocker.
And we need to be able to control how CSS properties are written into the SVG file; at the moment writing a property into a block element causes the property to be written into all the children elements which is not really desirable in many cases.
I wanted to follow up on this issue Tav. It seems there are several bug reports relating to line spacing:
Spacing between baselines not saving https://bugs.launchpad.net/inkscape/+bug/1590141
If you change interline width or interline unit only, you must do save as to save the changes. https://bugs.launchpad.net/inkscape/+bug/1587340
In Trunk text lines spacing increases suddently if text is selected while saving the document https://bugs.launchpad.net/inkscape/+bug/1569945
1590141 in particular is being listed as a blocker bug. Obviously all bugs are unfortunate, but some have to wait for future releases. Would it be possible for us to leave the line spacing problems as Known Issues and hope they can be fixed for 0.92.1?
If not, and assuming fixing all the problems is not a short-term achievable prospect, what is the minimum that *must* be fixed? And who would be a good person to be on point for the implementation work?
Thanks, Bryce
On Thu, 2016-08-25 at 18:53 -0700, Bryce Harrington wrote:
On Mon, Jun 06, 2016 at 04:27:25PM +0200, Tavmjong Bah wrote:
...Inkscape now respects the 'strut' value in the block element per CSS. In plain English, that means that the minimum spacing between lines is defined by the <text> or
<flowtext> element that wraps all the text. The minimum spacing is the value of the 'line-height' property times the value of the 'font-size' property. There was a comment in the code saying that this was not implemented in Inkscape because none of the browsers were doing it this way... but that was a long time ago. All the browsers now implement this correctly according to CSS (at least for HTML since SVG 1.1 doesn't have multi- line text).
CSS line spacing is definitely a mess (and the CSS group seems to recognize it). But having a strut value is useful as it means being able to define a well know spacing between the lines (see: http://t avmj ong.free.fr/blog/?p=1632 ).
The problem for Inkscape is how can the user know what is the value of the 'strut' and how can they change it? We definitely need a better interface. I would consider this a blocker.
And we need to be able to control how CSS properties are written into the SVG file; at the moment writing a property into a block element causes the property to be written into all the children elements which is not really desirable in many cases.
I wanted to follow up on this issue Tav. It seems there are several bug reports relating to line spacing:
Spacing between baselines not saving https://bugs.launchpad.net/inkscape/+bug/1590141
If you change interline width or interline unit only, you must do save as to save the changes. https://bugs.launchpad.net/inkscape/+bug/1587340
In Trunk text lines spacing increases suddently if text is selected while saving the document https://bugs.launchpad.net/inkscape/+bug/1569945
1590141 in particular is being listed as a blocker bug. Obviously all bugs are unfortunate, but some have to wait for future releases. Would it be possible for us to leave the line spacing problems as Known Issues and hope they can be fixed for 0.92.1?
If not, and assuming fixing all the problems is not a short-term achievable prospect, what is the minimum that *must* be fixed? And who would be a good person to be on point for the implementation work?
This is near the top of my list to work on in the next few weeks.
Tav
Thanks, Bryce
Note to self (and website team):
Add new FAQ about this, at release?
Note to self only - write a standard reply to paste into forum messages. Also possibly write tutorial for ways to re-scale the contents of the document?
-------------------------------------------------- From: "Bryce Harrington" <bryce@...961...> Sent: Sunday, June 05, 2016 1:59 PM To: <inkscape-devel@...6...> Subject: [Inkscape-devel] Doc scaling compatibility issue (Bug 1389723)
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 07.06.2016 um 11:08 schrieb Brynn:
Note to self (and website team):
Add new FAQ about this, at release?
- - Yes, that's definitely a good idea!
Maren
Hi,
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.
Thanks,
Tav
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 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@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-scaling-compatibility-issue-Bug-1389723... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Did you update to latest trunk first?
On Wed, 2016-06-08 at 05:20 -0700, alvinpenner wrote:
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@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.
Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Doc-scaling-compatibility-issue-Bug-1389723... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Wed, 2016-06-08 at 07:02 -0700, alvinpenner wrote:
sorry about that, the patch applies correctly under Inkscape 0.92pre1 r14965 (Jun 8 2016) some general comments:
- It would be helpful if it printed out the file name, in case I
have forgotten which file I opened.
- 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'
- 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.
Most of the output is just for debugging. It is certainly full of jargon. We can refine the text later once the approach has been proved useful.
Tav
one (Windows) user-interface issue which may need to be addressed at some point: 1. if I open Inkscape by itself, from the gui, and then use File->Open to load an svg file created in an earlier version, then Inkscape appears to hang forever. 2. if I perform a right-click on this same file and choose "Open with Inkscape", then Inkscape appears to hang forever. 3. if I run Inkscape from DOS, then all is well.
will test more carefully tomorrow
Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Doc-scaling-compatibility-issue-Bug-1389723... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
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-1389723... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
As whoever was interfacing with Inkscape at a low level such document's internal numbers was obliged to be aware and use the old fixed 90 DPI convention, I assume that leaving all numbers at 90 DPI would make the transition transparent for them. Surely they will not be able to use the new 96 DPI convention together with the old one, but this is another problem they'll have to solve by themselves. I suppose that such kind of users will choose not to convert any of their old documents if they don't want to/can't upgrade their external programs. All "normal" users are not going to care much about which numbers are internally stored inside the documents and will only see the effects on canvas: for them there should be no change at all because they are not going to have the knowledge required to fix conversion problems by themselves.
The main purpose of "fixing" the 90/96 DPI incompatibility should be to make "normal" users able to open an old document and keep working on it without the need of further manipulations. I won't mix addressing direct XML edits with normal on canvas usage.
IMHO a much better general approach could be abandoning targeting only the 90->96 conversion and trying to deal directly with the current document unit. That is, if the document is in mm all internal numbers should be moved to mm and the view box adjusted consequently, just like if the document was generated from the new mm template (using mm as an example, of course). My opinion is that "normal" users expect to have numbers in a mm document internally stored ad mm, so this approach should be fine for them.
A similar unit transformation utility may be useful also in other situations as it could be a general tool that permits a deep conversion of document's internal numbers from a unit system to another. I think about it being used on purpose by the user, specifying from which unit to which other to convert without relying on the document's internal stored state (probably a few options about how to deal with special objects like font sizes or filters' parameters may be appropriate). This general utility could be called at a document's opening if the 90/96 mismatch is detected, proposing to convert the old document from 90 DPI to a new unit system (e.g. mm or 96 DPI) and asking the user to specify to which one (proposing the current document's unit for all those who can't really understand what are being asked for and will just press 'Ok').
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Doc-scaling-compatibility-issue-Bug-1389723... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
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/rect0485.svg Cheers, Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Doc-scaling-compatibility-issue-Bug-1389723... 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Yes both can be merged, I do it time ago but discard the code in favor Tav, cleanest method to me.
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
Finaly get time and read Alvin mensage carefuly. And yes changing scale factor is not best.
This weekend I try to merge Tav work handling version with DPI Python switcher.
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
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
participants (8)
-
alvinpenner -
Bryce Harrington -
Brynn -
C R -
Jabier Arraiza -
LucaDC -
Maren Hachmann -
Tavmjong Bah