Comment 20 for bug 1239682

Alvin, thank you for the deep analysis you're doing here and for the generous explanations you're giving.
I completely agree with you that this problem has been "swept under the rug" for too long and that it will not go away alone.

To comment your considerations, I still think that the attempt to find a single general procedure to deal with this problem is not going to be appropriate. The different situations that you have depicted, ask for targeted approaches. You should not try to address Inkscape documents and files form other programs in the same way because they have different histories. Also, files from different Inkscape versions may need different approaches too.
This is why I stressed a bit before 0.91 to insert something to be able to recognize which convention was being used in a particular file (because it was going to be changed), to be able to know how to correctly convert it. Then I lost focus on what have been done as I sticked with Rev13640 because it's the last one that doesn't corrupt my documents (0.91 corrupts guides). I really hope that something has been done!

Now, I think that distinguishing between Inkscape's and external programs' documents is pretty straightforward, so the "document-fix" procedure should take advantage of this in the first place.
Then it comes to deal with Inkscape internal fuzzinesses: my understanding is that the vast majority of documents in the world today is in px @ 90 DPI (apart from the "reported" document's unit). Hence the "document-fix" procedure should apply this kind of correction if it can't understand from which other "particular" revision of Inkscape the document comes from.
Here I've already expressed my opinion: either the "document-fix" procedure is absolutely sure on what it's working on (e.g. from the Inkscape version in the document) or it ought to ask the user for what to do.
I think that with a carefully written "document-fix" procedure that parses the document to understand the conventions used, almost all situations could be correctly faced (of course not in a manually edited file with its own convention).

The case of a template that no longer works is a very minor case: I suppose that most users will accept to be asked to modify their custom made templates to satisfy a new program version. It's an operation you'd have to do only once and templates documents are usually very simple and small. The only important thing here is giving correct information!
In any case this aspect should not get too much in the way while looking for the correct solution for the _real_ problem, that is _opening_ old (big and complex carefully-carved-by-its-creator) documents.

All this to say that I'm really much skeptical that your proposed one-line and one-for-all solution will really fix everything; but, at the same time, I don't have enough knowledge to say that it will not work for sure.
So, let's try it and as soon as it will be on trunk I'll take a look with my documents: if it works for them you won't hear me complaining again. :)
Thank you.