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.

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?

Thanks, Bryce

Note to self (and website team): Add new FAQ about this, at release?

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJXVrq7AAoJELavtZto4hQPRLsP/3GT+VzVn1Pt7emYKKPYXx8q e297j8HH5Io5lP4h8+AkM2aQitjonGohBtvrBX/E1nkijZfnjSblhMfkskKjRUJn qWCwYUgiVONPFeD+eeir6ZmsKJ8IvbiHdjG5uelTj3GdKk8RrNcwgLbSSYCtrn1z t3HFknzzOVWNxX5Ve9RnKhQPVCWYsJn0cre3a5l3utovX5S+U9nXKvd+Usf3vyEW qYm8mkeyu0WUoS1dshN5UABpZv4/v9a5GijqhMlJIpPUYt9Uev2YS1ByslkiQkx5 3GBrfvN7vSvbj86LTvyLVYuQ1zcwGhEc5kXFkYnVu9QlTwJSDuaR9DhsuPp3njOa gDRQe5Qjlsxz3jzqX44kf1IFkNjJcntnVITzHTpiW3elqX2ZMT+b9m2m6RLOjjig Bwmb/LCbA4UXX9uWs7W3xxHr2gVLaKv8k93eKLBIyQ7cePvXUctXVtce4lar8e92 ztknQ4sm8J38xo6KsZTTCb4XMjhrQKmmQRKGBAZMMwvdGV5BOfGMofnnfp2xhEPy 5RB23IzJQKgsgtYLk/8jRI7NUWRKv4LgUpnq8t8V2c5FJJgd1OqkfI8Jzx+58Q3h zob1h+bWilbC2pBknp9alLqJzwF7M0mhXb9c2gfIih1DyQ1qglFqmKky3j9e+nlZ fdrHAeFciykM7RX+EaDm =alwt -----END PGP SIGNATURE-----

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