Re: [Inkscape-devel] UX help

-- Mc On 02/05/2017 10:41 AM, brynn wrote: > Thanks for your very detailed explanation. I hope I will eventually understand > it. But for now, I'm stuck near the top, at the place where you talk about > calculating the size of a pixel. > > I thought a pixel is a screen pixel, which is a fixed size for each particular > screen. And that dots (as in dpi) is a print measure, and which dots can be > different sizes (dots per inch). Does Inkscape have some unique use of these > terms, that are different? Or do I have a misunderstanding? > > Thanks, > brynn > > -----Original Message----- > From: LucaDC > Sent: Friday, February 03, 2017 5:07 AM > To: inkscape-devel@lists.sourceforge.net > Subject: Re: [Inkscape-devel] UX help > > 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. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >