Hi developers,
I've been looking at merging the fix for bug lp:167335 in branch[1]
The code looks reasonable, although light. I'm compiling the branch now although could find no mailing list discussion about it and the merge review thread is empty.
Any issues with this code before I merge it in?
Martin,
[1] http://bazaar.launchpad.net/~novalis/inkscape/fix-167335
Addendum:
The real link is here: https://code.launchpad.net/~novalis/inkscape/fix-167335/+merge/190297
And there is some discussion, just sort of looks like the ball was dropped on getting the code in.
Martin,
On Thu, 2014-03-27 at 18:00 -0400, Martin Owens wrote:
Hi developers,
I've been looking at merging the fix for bug lp:167335 in branch[1]
The code looks reasonable, although light. I'm compiling the branch now although could find no mailing list discussion about it and the merge review thread is empty.
Any issues with this code before I merge it in?
Martin,
[1] http://bazaar.launchpad.net/~novalis/inkscape/fix-167335
2014-03-27 23:02 GMT+01:00 Martin Owens <doctormo@...400...>:
Addendum:
The real link is here: https://code.launchpad.net/~novalis/inkscape/fix-167335/+merge/190297
And there is some discussion, just sort of looks like the ball was dropped on getting the code in.
I'm not really sure whether adding a partial fix that only works for plain SVG export and moreover will cause very confusing behavior is the right thing to do. (When you reopen this file, edit the flowed text and save it again as Inkscape SVG, other renderers will not show any modifications.)
Regards, Krzysztof
On Thu, 2014-03-27 at 23:23 +0100, Krzysztof Kosiński wrote:
I'm not really sure whether adding a partial fix that only works for plain SVG export and moreover will cause very confusing behavior is the right thing to do. (When you reopen this file, edit the flowed text and save it again as Inkscape SVG, other renderers will not show any modifications.)
The switch should be there for inkscape svg and plain svg, right?
We've created this mess by using custom tags, it's far more obvious that inkscape saves dud svg files at the moment than if we had the switch in there.
My concern is that I can open an old svg file with flowed text, I can save it, I can open it, I can edit it, I can save it again and have those changes track. That at each save the file was presentable to a web browser and librsvg.
That's what I'll be testing for.
Although I got a SEG on the first compile's run saving an svg with flow text, so more testing and debugging will follow.
Martin,
2014-03-28 0:00 GMT+01:00 Martin Owens <doctormo@...400...>:
My concern is that I can open an old svg file with flowed text, I can save it, I can open it, I can edit it, I can save it again and have those changes track. That at each save the file was presentable to a web browser and librsvg.
There are 2 possible approaches to this: a) compute the fallback text as a postprocessing step when saving b) compute the fallback on every write to the XML
a) will be significantly faster, especially for large text, but b) allows one to inspect the fallback in the XML editor in real time and reduces the chance of crashing during save.
The branch implements option a), but it is missing an essential piece. Currently switches are treated as groups. The switch that contains the flowtext fallback should be treated as transparent and editable as a flowtext object. This can be done by adding a sodipodi:type attribute to it and modifying some code in SPFlowtext, but in general I think this should be the default behavior for switches.
Regards, Krzysztof
On Fri, Mar 28, 2014 at 12:32:43AM +0100, Krzysztof Kosiński wrote:
2014-03-28 0:00 GMT+01:00 Martin Owens <doctormo@...400...>:
My concern is that I can open an old svg file with flowed text, I can save it, I can open it, I can edit it, I can save it again and have those changes track. That at each save the file was presentable to a web browser and librsvg.
There are 2 possible approaches to this: a) compute the fallback text as a postprocessing step when saving b) compute the fallback on every write to the XML
c) put a future/dirty flag on the element which is evaluated on read (including read for write to file).
njh
Based on my concerns I've written a full report:
https://code.launchpad.net/~novalis/inkscape/fix-167335/+merge/190297/commen...
The branch is not a fix. Although it may be the start of one. I'd love to see the original developer or someone new pick up the code and attempt to fix this long standing blemish on Inkscape's svg output. It certainly needs to be done for 1.0 but I thought it'd be nice for 0.91 too :-)
Best Regards, Martin Owens
On Thu, 2014-03-27 at 19:00 -0400, Martin Owens wrote:
My concern is that I can open an old svg file with flowed text, I can save it, I can open it, I can edit it, I can save it again and have those changes track. That at each save the file was presentable to a web browser and librsvg.
That's what I'll be testing for.
participants (3)
-
Krzysztof Kosiński -
Martin Owens -
Nathan Hurst