Hi,
On Fri, 2011-08-26 at 14:08 +0200, the Adib wrote:
Hello,
I would recoomend to stick to the standard rather old code behaviour. So an "automatic" conversion of old type to new type on load makes absolute sense.
Automatic conversion, unfortunatelly, will result in a forward compatibility problem.
Linked offsets, I think, are not defined in the svg standard but, rather, are implementation specific to inkscape that are saved as svg defined elements and inkscape-defined ones (ie not editable as linked offsets in any other program)
For me working as user I would appreciate if I do not have to set options, execute extensions etc. it should run in automaticaly background. (maybe a popup: "you file has been converted to inkscape version 0.48")
This might be intresting, but if the user decides to not do the conversion? should we mark it as uneditable and revert to the old rendering? (editing is extremelly difficult to implement with these different behaviors coexisting)
my 2ct. I wrote this without digging into the details and looking what is possible or not.
Adib.
On Fri, Aug 26, 2011 at 9:54 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
On 25-08-11 21:51, Adonis Papaderos wrote:
It apears that the work I have done with linked offsets to make them behave as linked offsets have the side-effect of breaking compatibility with old drawings that rely on the old behavior. (see bug #817907 https://bugs.launchpad.net/inkscape/+bug/817907). I believe that commit 10109 should be revoked and the attached bugs marked as won't fix (since I don't see any other way of fixing these).
What do you think?
It might be better to discuss this on the developers mailing list (instead of sending it to everyone in the inkscape developers group).
As for your question, as far as I can tell it's choosing between sticking to old behaviour that doesn't make much sense and causes problems for at least some people and new behaviour that makes a lot more sense but might cause some problems for existing drawings. This is not an easy choice, but I would be inclined to go with the new behaviour, as that's probably the better choice in the long run.
Obviously going with the "new and improved" behaviour will cause some problems with existing material, but I'm afraid it's impossible to always avoid this. Now, if you want to be really friendly towards people with existing material there are a couple of possible courses of action:
- Detect version of Inkscape that file was saved with and automatically
convert linked offsets.
Supply an extension that can "fix" linked offsets from older versions.
Provide details for manual migration (what's the easiest way to get
people's linked offsets to behave like they used to).
- Make the behaviour optional (per file), possibly in combination with
version detection.
- Create a new way to achieve linked offsets so that it does not affect
old linked offsets.
Personally I'm not a big fan of 4 (extra code, extra complication). Option 1 is kind of nice in some cases, but in this particular setting it could prove to be a hassle if files move between people with different versions. All in all I would recommend option 2 or 3, and possibly 5, if you're feeling adventurous :)
Option 5 is probably a bit more involved, but would be cool. In particular, I was thinking that it might be cool to be able to use LPEs on "clones", and a linked offset would then just be a certain kind of LPE. Currently this isn't possible as clones are not paths, so it would probably require creating a new kind of "linked path" and making sure that LPEs work with that. Then we would need to create an LPE that does an offset and make sure that the offset can be edited on canvas.
With option 5 we could choose to keep the old linked offsets code around or to remove it. The latter has the advantage that existing files will still render correctly, any old-style linked offsets simply aren't editable as linked offsets anymore.
EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Thanks
Adonis