Brynn wrote
Remember that failing to properly convert a mm document can lead to loss of
data: if you start working on an old document without converting it, all old objects will report a size in mm which is not the original one but _without_a_visual_evidence_ of this, being the page wrongly sized too. But all new objects _will_have_correct_sizes_, hence will all be in a different scale than the older ones.
It may be that Mairin doesn't realize this, or maybe doesn't understand. I don't understand it myself, although I hope to be able to, so I can help other users.
I'm thinking that a mm has to be a mm, no matter what the dpi is. So if the user does nothing, won't they just keep on working at the same scale?
Why only mm units are affected?
Thanks, brynn
It's not only mm that are affected: all units other than px are affected. I spoke about mm only to give an example.
I'll try try to explain the problem and summarize the issue of conversion, hoping to be clear and correct. Sorry but I'll need to be a little technical (I'll try to be the least possible). Everybody finding errors, please correct me.
Old documents use a convention of 90 DPI, that is 90 pixels per inch. Starting from this you can calculate how large is 1 px in whatever physical unit you need. For example, 1 px = 1/90 inch = 0,28222... mm.
This convention would have been of little interest to everyone if it wasn't for the decision to store everything inside Inkscape's SVG created files using only the unit of px, regardless the units the user used in the GUI to create his objects. That is: you created a 10 mm x 10 mm square, Inkscape would store a 35,4331 px x 35,4331 px square in the SVG file, while still showing it as 10 mm x 10 mm in the GUI (well, sometimes this caused the displayed values to become something like 10.0000001 mm x 10.0000001 mm and this was the sign that something weird was happening under the hood). To keep all this coherent, Inkscape had to continuously convert all the data you inserted into px and all the numbers in the file back to your physical unit to show them in the GUI. This was the reason for the little discrepancies between what you input and what you got back.
To fix the problem of rounding errors, an effort has been made to stop using px as the only internal unit. So after this first step, Inskcape's files started using also mm and inches and so on to store numbers. This raised the problem of better defining some terms like "document unit", "GUI unit", "user unit" and so on. This was a great step toward correctness of numbers inside documents. Some problems due to this passage are still lingering around but hopefully the majority have already been fixed or will soon be.
Up to this point, everything would have worked fine: old "only-px" document didn't need any special treatment, they still could be managed as before without any difference nor advantages/disadvantages. Only newly created documents were going to take advantage of the new unit management system.
The problem come out when, to make it short, it happened that the 90 DPI convention was abandoned in favor of the new 96 DPI one. This means that the physical size of 1 px was going to change from (I still use mm as example, but whatever physical unit could be used here) 0,28222... mm @ 90 DPI to 0,26458... mm @ 96 DPI.
Here is the point: if inside an existing document physical units are used (like mm, inches, ...), this change is not going to affect anything as 1 mm is still 1 mm and 1 inch is still 1 inch. On the other hand, if inside an old document all physical unit had been converted to px using the old 90 DPI convention, if you now convert them back using the new 96 DPI convention they are going to be wrong. Example: an A4 is 210 mm x 297 mm. Let's convert it in px using the 90 DPI convention: 210/25,4*90 = 744 px 297/25,4*90 = 1052 px This is what was written in an A4 old Inkscape document as page size. Not let's open it with a new version that uses the 96 DPI convention: 744 px -> 744/96*25,4 = 196,85 mm 1052 px -> 1052/96*25,4 = 278,34 mm That is, the page is going to be ~6,28% smaller than intended (it's 6,25% without rounding errors). This is going to happen to old 90 DPI documents when opened with new versions of Inkscape that uses the 96 DPI convention: if you intended your page and your objects to have some particular size in your preferred physical unit, you'll find all of them 6,25% smaller (if you print or measure them!).
So, now the problem is that all around the world there are older, less old, slightly old and fresh SVG documents created with different versions of Inkscape that follow different conventions. When you open a file, the program cannot know: 1) which convention was used (I tried to stress this point at the time of the modifications, in order to add a field in the file reporting the convention; this was not done); 2) if the document is all in px, if the user really meant it to be so of it it was the product of the forced conversion of everything in px.
Now we come to the new dialog prompting for conversion.
Let's say that a user opens one of his old document he has drawn in an A4 page using mm (but another physical unit would do). He is prompted for the conversion, can't understand a word of it and blindly chooses the "do nothing" option: now he's facing his document that _we_ know is 6,25% smaller but he doesn't! The document looks good to him: he has the A4 page's borders as reference and everything looks fine (because the page is smaller too!). He starts working on it drawing new objects (still in mm, like a 10x10 mm square, a 25,3 mm diameter circle, and so on; maybe he even draws some quotes) but can't realize that the new objects are in a different scale than the older, because he doesn't measure anything of what he had already drawn and takes for granted all the old dimensions. Then he saves the document and goes to bed. The day after, fresh minded he reopens his document, works a little more and... Wait a minute! That quote is wrong: it was supposed to be 13,2 mm, not 12,375 mm... Let's measure this line: hey, it's wrong! And this too, and.. well this is not, this too is right... What --- <beads of sweat, headache starting>. Now we should try to explain him that all he had drawn before the conversion is 6,25% smaller, while all he has drawn yesterday and today is correct (with regard to physical unit, but wrong with regard to the original document). He just have to resize the page (!) and all the old objects while keeping the new ones as they are (but for sure line up them to the newly resized old objects where needed). Please, you explain him, I can't because I just remembered I had a commitment...
All this is going to happen if you choose the "do nothing" option. Then there are the conversion options. A couple of conversion methods have been developed but both have their limitations. I cannot speak about details on them because I've not tried them thoroughly enough. What I guess is that some features still use px as internal unit, so resizing the document tout-court is not going to fix them correctly. On the other hand, the solution of traversing all the document's structure to convert object by object coordinates and sizes should give a better result but is far more complicated and prone to errors (eg. objects inside groups which are grouped together, with rescaling matrices here and there...). I see that developing a 360° error free conversion procedure is a formidable task that requires deep knowledge of all Inkscape's options and features and of how they interact under the hood.
All this said, put yourself in the user's clothes: he doesn't know what 90 or 96 DPI px could have to do with him (he has always drawn in mm...), he has tons of old documents, he was just opening one of them and now he is facing a dialog that asks him:
Your document needs to be converted because #@§"-",!!!... (eh?) What do you want to do? - do nothing - convert it with method ç°§",,"k/0212341 - convert with method [213dgdf234231gdg] If you don't know what to do, choose ([{.}]).
This is a caricature of the dialog, of course. I'm deliberately ignoring all the amazing proposals that have been done. I think that they are really wonderful from a graphical and communicative point of view. I wouldn't be able to produce such good material so kudos to who can and absolutely no intent to criticize them. The point here is not how the information is presented, but which information is presented and what is the purpose of the dialog.
My opinion is this.
1) The subject is though. There's little possibility to try to explain it to all users so to let them make a thoughtful choice. Some of them may also (rightly, IMO) think that it's not fair to turn the responsibility of fixing such a large mess to them and that developers should handle all this transparently (correct but very tough and not always applicable) or give clear information about severe incompatibilities between Inkscape's versions (a bit exaggerated, IMO).
2) It's really important that users know that _there_is_ a problem. They must know that their older documents need a fix, or at least that they will find differences to be dealt with. They absolutely have to check their documents after whatever option they choose. This is really crucial: not informing them on the risks of this operation would be a serious fault. This is a cannot-miss point.
3) Providing some automatic ways of converting old documents is not needed to be bound to the opening of old documents. It could be a procedure that one has to launch by hand, _check_the_result_ and save it. The opening informing dialog could give advices on where the procedure can be found and urge to take notice of the problem. The user could simply choose to use an old Inkscape version to handle old documents. This approach has the benefit that users are bound to actively do something or deliberately ignore the warnings. If the dialog is well thought (and I see there are people that know what they do), there's no risk that someone will unconsciously overlook the problem.
4) The development of good conversion routines could take a long time. Different procedures could be developed to deal with different corner cases before reaching a single all-inclusive solution. Moreover, some bugs may need to be fixed before it's possible. This will require time and patience. By that time, users that have experienced data loss could have left Inkscape in favor of another more reliable program (and don't say there aren't because even if it's true, it's not professional nor fair). Better say the truth: giving a "choose this if unsure" option would be a lie like "trust us and do not worry: we know what you need".
Now, I hope to have shed some light on the argument. If I didn't, forgive my attempt. If I've written something wrong or stupid, please say it loud and correct me: I don't want to keep wrong ideas into my mind. Thanks.
Regards. Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/UX-help-tp4978575p4978752.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.