Hi Josh!

On 01/25/2017 12:00 PM, Josh Andler wrote:

We are always looking to improve our UX. If you have any immediate thoughts/mockups on the items you brought up that you would like to share, we would be happy for the feedback. Thanks so much for reaching out. Given the volunteer nature of the majority of our development, it's greatly appreciated!

Mc has very patiently explained the particulars of this issue to me in IRC, and we worked together to come up with this:

http://i.imgur.com/moaKwfo.png

I would be interested in David Revoy's input on this. I know the single button he suggested is a much better experience for the majority of users, but I think for the physical output folks, it's going to cause some problems (they might not think to look under advanced) so I thought this progressive way of getting into the edge cases would allow them to have a reasonable experience while still keeping it relatively simple for the pixel-based majority case (they can pretty much just skim and click the button and they're fine.)

~m

Hi Eduard!

Thanks for the feedback! -

On 01/25/2017 01:35 PM, Eduard Braun wrote:

• A minor thing: "Pixel-based artwork" sounds a bit like pixel-art (which is not what this is about). Maybe call it "artwork based on dimensions given in pixels" or similar?

Yeh, I can see that being problematic. How about, "Digital Artwork" - the implied target for digital artwork in a screen which is pixels, right?

• The two selections for "physical output" do not really well explain what the difference between them is. Both selections mention that they are for content that "needs to be accurate" but the accuracy we're talking about is obviously different in both cases.

True, reusing accuracy as a concept might be confusing. The main decision: do you care more about the appearance of the artwork, or the real world scale of the artwork? To make that trade-off clearer, how about:

- "The appearance of elements such as clips, masks, and clones is most important."

- "The accuracy of the physical unit size and position values of objects in the file is most important."

Thanks, ~m

I think these mockups are great. A couple minor suggestions from the sidelines here:

As I was reading the explanation at the top and the option descriptions, I had no idea specifically what was different about the old and new Inkscape, and what would change about my file. It took me a while to read the more details, which finally gave me enough info to say "Oh, it's just converting from 90 to 96 dpi. Cool, go ahead."

This is because the explanation and descriptions describe the generic intent of the action, but not the specific cause and outcome.

It's good to have the gory technical details hidden behind a "more..." button for advanced users, but the addition of a few words above would've helped me. Something like *"foobar.svg was created in an older version of Inkscape using 90 DPI and we need to make it compatible with new versions that use 96 DPI. Tell us about the file:"*

It would also help to know what each of the 3 options do differently. Behind the "more..." button is fine, but the current explanation just describes two methods, not three, and doesn't clearly say which options they correspond to. It would be great if the methods described here referred back to the three options more clearly.

- Bryan

On 26 January 2017 at 07:49, Máirín Duffy <duffy@...43...> wrote:

This is what the suggestions I made would look like: http://i.imgur.com/jdKQCf0.png

~m

---

---

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

Am 25.01.2017 um 19:41 schrieb Máirín Duffy:

Hi Eduard!

Thanks for the feedback! -

On 01/25/2017 01:35 PM, Eduard Braun wrote:

...

• A minor thing: "Pixel-based artwork" sounds a bit like pixel-art (which is not what this is about). Maybe call it "artwork based on dimensions given in pixels" or similar?

Yeh, I can see that being problematic. How about, "Digital Artwork" - the implied target for digital artwork in a screen which is pixels, right?

Sounds good (seeing that Martin also came up with it independently!). I'd not drop the pixels completely, maybe go with "Digital artwork (pixel-based)"?

...

• The two selections for "physical output" do not really well explain what the difference between them is. Both selections mention that they are for content that "needs to be accurate" but the accuracy we're talking about is obviously different in both

cases.

True, reusing accuracy as a concept might be confusing. The main decision: do you care more about the appearance of the artwork, or the real world scale of the artwork? To make that trade-off clearer, how about:

• "The appearance of elements such as clips, masks, and clones is most

important."

Maybe say "Faithful reproduction of elements [...]" (Appearance sounds a bit vague).

• "The accuracy of the physical unit size and position values of

objects in the file is most important."

As a non-native speaker of English I'd be struggling with "the physical unit size" (maybe make it more about physical unit sizes in the graphic), but I agree with the concept

Thanks, ~m

Great work! I'm very interested about UX design.

Cheers, Jabier.

On Wed, 2017-01-25 at 14:10 -0500, Máirín Duffy wrote:

On 01/25/2017 01:57 PM, Eduard Braun wrote:

...

Sounds good (seeing  that Martin also came up with it independently!).  I'd not drop the pixels completely, maybe go with "Digital artwork  (pixel-based)"?

In the mockup I put (to be super clear) "Digital artwork for screen  display" (talked about the target output to contrast with the physical one.)

...

...

• "The accuracy of the physical unit size and position values of

objects in the file is most important."

As a non-native speaker of English I'd be struggling with "the  physical unit size" (maybe make it more about physical unit sizes in  the graphic), but I agree with the concept

Does dropping "unit" help?

"The accuracy of the physical size and position values of objects in the  file is most important."

Thanks, ~m

---

---

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

Hi all again. Is ok no do nothing option?

Cheers, Jabier.

On Wed, 2017-01-25 at 20:34 +0100, Maren Hachmann wrote:

Thank you for working on this, Máirín!

I actually have no idea what the two scaling methods do, so maybe these questions I have when I look at the dialog are similar to what others might think when they're confronted with them for the first time:

I don't understand what 'the appearance of a mask' might be (it's invisible...), and what could look wrong, if the units/physical sizes are correct.

If I had to guess, I'd interpret the lower dialog part as:

"Masks might not be positioned correctly in relation to the object they are masking (and the same for the other things mentioned) if you choose that physical units are important to you."

Is this what it means?

Is there a way to also tell people about the downside of each method?

And to detect if there is a mask, filter, clone ... at all? Then it probably wouldn't matter so much which method you choose.

Can someone (some time) actually do explain the difference between the two methods? FAQ item is fine. Btw., we haven't had *any* question about the dialog meaning in the forums or in the answers section yet (which surprised me - maybe people just chose 'Ignore', as it seems the safest option...?).

Maren

Am 25.01.2017 um 20:10 schrieb Máirín Duffy:

...

On 01/25/2017 01:57 PM, Eduard Braun wrote:

...

Sounds good (seeing  that Martin also came up with it independently!).  I'd not drop the pixels completely, maybe go with "Digital artwork  (pixel-based)"?

In the mockup I put (to be super clear) "Digital artwork for screen  display" (talked about the target output to contrast with the physical one.)

...

...

• "The accuracy of the physical unit size and position values

of  objects in the file is most important."

As a non-native speaker of English I'd be struggling with "the  physical unit size" (maybe make it more about physical unit sizes in  the graphic), but I agree with the concept

Does dropping "unit" help?

"The accuracy of the physical size and position values of objects in the  file is most important."

Thanks, ~m

---

---

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

On 01/25/2017 02:34 PM, Maren Hachmann wrote:

I don't understand what 'the appearance of a mask' might be (it's invisible...), and what could look wrong, if the units/physical sizes are correct.

Would it be more accurate to say "masked objects" rather than "mask" ?

Is there a way to also tell people about the downside of each method?

Yep, I did this in the extended info. I think the options get too long if it's in the radio options. Do you think this is ok?

http://i.imgur.com/gIieEhm.png

And to detect if there is a mask, filter, clone ... at all? Then it probably wouldn't matter so much which method you choose.

I believe Mc intends to add this kind of logic to make smart choices for the users, but this is meant for a quick / temporary fix to update the strings and screen layout only to address the current UI. I think he is looking at making the dialog smarter after committing a strings-only change.

Can someone (some time) actually do explain the difference between the two methods? FAQ item is fine.

My understanding (which may be somewhat inaccurate):

We have two "sizes" that apply to Inkscape files. There is the viewbox size, and the document size. The document size sets the size for print output. The view box sets the size for display in a browser. The document size != viewbox size always. They are linked by the DPI, and unit conversions are performed based on the DPI requested by the output medium. The document size is used for print output. Initially, Inkscape files have a document size and viewbox that are the same, and the dimensions of one are calculated based on the default DPI, but if the viewbox is changed the document size stays the same; if the document size changes the viewbox may stay the same.

The first method, which preserves the appearance, resizes the viewbox. So if the file was A4 at 90 DPI and it's changed to 96 DPI, the file will be slightly smaller than A4. So this method takes the viewbox and changes the size to sort of reset the scale on the file so it would be the full size of A4 at 96 DPI. The problem is, if you have a line of text in the file that is exactly 100 mm tall on an A4 page at 90 dpi, because everything is getting scaled together, that line of text will be bigger than 100mm on the 96 DPI A4 version created through this method.

The second method takes into account the sizes set on individual elements in the file. This is more problematic because filters, masks, clips, etc. might not have the exact size / position / etc relative to the objects they are applied to. However, the end result of this is if you had a line of text in the 90 DPI A4 page that was 100mm, it would still be 100mm on the 96 DPI A4 page.

Btw., we haven't had *any* question about the dialog meaning in the forums or in the answers section yet (which surprised me - maybe people just chose 'Ignore', as it seems the safest option...?).

While I use 0.92 now and have been using preleases of 0.92 for a while, I haven't seen this dialog box before. Mc explained it appears if the viewbox isn't set in the file (older versions of inkscape, IIRC pre 0.48 did not have a viewbox setting, it was an implied rather than explicit value) , and may not appear depending on how the document size is set in the file.

I am thinking maybe not so many users are running into the dialog, and the few that have are loud? (I have run into line height issues messing up old mockups but the workaround trick works fine for me.)

I still have some holes in my misunderstanding here but hopefully this helps?

~m

Looks great to me. Thanks!

On 26 January 2017 at 09:35, Máirín Duffy <duffy@...43...> wrote:

On 01/25/2017 03:18 PM, Máirín Duffy wrote:

...

Yep, I did this in the extended info. I think the options get too long if it's in the radio options. Do you think this is ok?

http://i.imgur.com/gIieEhm.png

Goofed the link here - thanks to Bryan for pointing that out - http://i.imgur.com/YF7MCWl.png

~m

---

---

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

On Wed, 2017-01-25 at 15:35 -0500, Máirín Duffy wrote:

On 01/25/2017 03:18 PM, Máirín Duffy wrote:

...

Yep, I did this in the extended info. I think the options get too long if it's in the radio options. Do you think this is ok?

http://i.imgur.com/gIieEhm.png

Goofed the link here - thanks to Bryan for pointing that out - http://i.imgur.com/YF7MCWl.png

~m

Looks very good! (Demonstrates that developers shouldn't do UX design.)

Hi,

On Wed, Jan 25, 2017 at 9:35 PM, Máirín Duffy <duffy@...43...> wrote:

On 01/25/2017 03:18 PM, Máirín Duffy wrote:

...

Yep, I did this in the extended info. I think the options get too long if it's in the radio options. Do you think this is ok?

http://i.imgur.com/gIieEhm.png

Goofed the link here - thanks to Bryan for pointing that out - http://i.imgur.com/YF7MCWl.png

I maintain two extensions for making board game components, as I posted about earlier on the list. In particular the countersheetsextension (https://github.com/lifelike/countersheetsextension) is affected by this. There is probably someone that uses it to make graphics for a screen, but the vast majority (everyone I heard from) wants to make sheets of cardboard counters or cards to print. Sometimes the sheets will be cut by machines, so of course the coordinates have to be correct.

With that background, looking at the drafts and original dialog I still am not sure what I should choose (and what I need to inform the users of the extension to choose!). Obviously the goal for anyone would be that if they work on say a card-game in Inkscape 0.91, upgrade to 0.92 (and upgrades to a later version of my extension that supports 0.92) and keep working on the same game, they want sheets printed to look identical. Same location relative to the page, same size and layout of all the text and graphics seen on each card. Pixel-coordinates is not likely to be on anyone's mind at all, as long as all the real-world coordinates and sizes seen in the GUI (and in the printed result) stay correct.

I am pretty sure that the correct option for us will be "intended for physical output" and hopefully everyone will figure that out. Although it might distract many to see the strong bold text saying "choose if unsure", coupled with that option being the default. Kind of inviting to click the "wrong" one? But then I am confused about the two sub-options. Why are they needed? It sounds as if scaling individual elements is the correct choice always. Does the other (default?) option exist only because Inkscape currently has some bugs? So in a future 0.92.x or later version the bad option might be removed, because the correct individual scaling will work properly? But by that time it might be too late I guess because many will have already chosen to convert their files using the inferior method, and it will be difficult to repair? In that case it might be better to stay on 0.91 until this has been solved?

This concern is of course no different from those making physical games without my extension, or most other users only interested in what the printed results look like. It just happens to be the only group of users I am familiar with.

On Thu, 2017-01-26 at 09:54 +0100, Pelle Nilsson wrote:

In that case it might be better to stay on 0.91 until this has been solved?

It would be very good to test it to death when it comes out. Having people such as yourself who can test files and formats specific for physical output will make sure that we're doing the right things in the code.

Best Regards, Martin Owens

Hi Brynn!

Thanks for the feedback! More below -

On 01/27/2017 08:34 AM, brynn wrote:

Sorry I missed this whole discussion yesterday. But I wanted to say that I like jabier's idea with a small graphic to represent what each option does, which clicking on it also sets the option choice.

I agree that visuals are a good idea - they don't require as much time to grok. I can draft up icons for this. If anyone has ideas on how to represent let me know. My initial thoughts (feel free to come up with better ones or just let me know if any of these wouldn't do):

- Digital art option: a paintbrush painting an image on a laptop screen - Appearance option: a graphic with a lot of shiny and effects / sparkles on it - Size accuracy option: artwork coming out of a printer with a ruler lined up with it

For the last version of the mockup I saw: I agree with whoever mentioned about "Choose if unsure". A lot of newbies, as well as not newbie, but still not very techically aware users, will choose it, simply because they don't understand it. So I'm not sure if "choose if unsure" should be there at all. I think the text, and maybe a small graphic, as jabier suggestion, should be clear enough that most users will be sure what to choose.

I completely understand your rationale, and it is logical. I can also say consistently based on my experience as a UX designer - having conducted many usability tests and read quite a bit of research - that the majority of users will just not read the explanatory text.

It's not that they are stupid or don't care. Their goal / focus is simply elsewhere and they don't want to have to make a decision like this - they fear them. I think it is a good practice to have a very obvious "choose this if you dont know" option, because at the very least, it is the least destructive option of any of the 3 we have to offer, it does the least amount of change to the file, and if it ended up being the wrong decision, they can manually adjust the file (I'm assuming!) later on.

I'm not saying that the tactic of having a default choice is absolutely the right one in this scenario - we can take a look at how the screen design reads with the icons, for instance, and see if it makes it clearer which option to choose - but I'm just saying with a lot of experience with this sort of problem (diff context but same problem, think storage and system management UI... ) having a 'default' is the option that users are best able to navigate and requires less cognitive load.

The tension here is the users having to learn something when they're not necessarily in the mood / have the time to learn vs. us taking on the guilt of pushing them towards something that might not be the perfect decision for them and could impact their files negatively. I do think if they choose the default option we push here, that the negative impact isn't going to be significantly high (they print it, it doesn't fit the page correctly, they adjust manually. Costs them a piece of paper, some ink, and time. Ok, so that print could be a plotter print, but still :) )

Where it says in the More section, 'there are 2 scaling methods - the whole document, or the individual elements in a document' - that is very clear to me. But which goes with which option above? I'm guessing they describe the 2 sub-options for the 2nd main option?

To more clearly link them, we could use the same text in the top UI options and in the bottom explanatory text. Since I think framing in terms of the user's context is more important, I would use the text that talks about the type of artwork. Maybe instead of italicizing it, bolding it:

- Appearance - Accuracy of Scale

So where the bottom talks about each method, the bold text titling that section would say Appearance / Accuracy of scale and then after that explain for appearance, we scale the whole document.... so on and so forth.

Because of all the info provided in the More section, I'm not sure what info is going to be included in the FAQ. It seems like the More section should be in the FAQ, and at the bottom of the dialog, it should be a link to the http anchor for that item.

I agree. That is a better way to do it. We could use the same text and even have a screenshot of the dialog in the FAQ if need be.

If more technical info (than what's in the More section) is going to be available, maybe it should go in the developer faq, in the wiki. Then the user faq item (on the website) could link to it in the wiki.

As one of those 'not newbie, but not very technically aware' people, the first 2 main choices are very clear to me (screen display or printer). But I'm still a little unclear for the 2 sub-options for the 2nd ("physical output") main option.

Does the 1st sub-option mean if my drawing has any clips, masks, filters or clones, I should choose that option? Because if the 2nd option (accuracy of physical unit/position) means 'is the file going to be used for 3d printing', such a file is probably not going to have clips, masks, filters or clones.

If your drawing is meant for printing *and* it has clips/mask/filters/clones/etc., yep, that's the option for you.

So I wonder if it could be simplied to a) The image contains clips, masks, filters or clones b) The file will be used for 3d printing

The one worry I have here is if you're printing the file out, are worried about scale, but the artwork doesn't have clips, masks, filters, or clones. You still probably would want that option.

I wonder where files used for cutters/plotters would fit - all the new gcodetools and etc.? I guess they would choose the 2nd option? If so, then maybe the 2nd option should be b) This file will be used with 'digital'? 'computerized'? cutters/plotters or 3d printing.

Good question - not sure.

Are these changes reversible? If not, maybe the option to make a backup could indicate they aren't reversible?

Not reliably for the 3D printer one, so a backup should be default for that option.

Could there be a "do nothing" option? Or is a choice needed for every file? If a "do nothing" option is added, it should maybe warn about the consquences. "This or that might happen" (or "will happen") if you don't make a choice.

The first option (digital artwork) is the do nothing option, which is why it's also being pushed heavily as the default choice.

I really like your idea to emphasize consequences though because I think users really care about that above all. Let me noodle on that for the text.

Last comment. There needs to be a space in "Thismethod" in the "Scaling individual elements....." section in the More section.

+1 Good catch.

Thanks for your good work Mairin, and offer to help! It's clear you have awesome skills for UX and mockups! For the most part, I think Inkscape's interface is very good. But there is plenty of room for tweaking and polishing.

Thank you - what a nice thing to say. :) I love Inkscape's interface and basically live in it. I agree there is room for tweaking and polishing, and I'm happy to help with that on the UX design front.

(This is probably a different subject, but there was recently some discussion about making the Page tab of the Document Properties dialog better - maybe split into 2 tabs, I'm not sure. Currently I have to dock that dialog to be able to see the last 3 options on that tab. This is a basic 15 inch laptop, which is apparently considered a small screen.)

I have the same issue with my laptop! I would be glad to play around with that design next.

I will have an updated mockup soon, hopefully I'll have time later tonight.

~m

Accuracy option - I suspect the cutter/plotter users would choose this option, and if so, somehow depict a CNC machine? I have no idea what a 3d printer looks like.

CNC and 3D printers caught my eye. I’d suggest a laser cutter plus ruler.

I suspect there’s more people using Inkscape to drive laser cutters than any other digital fab tool. It’s reasonable to go straight from Inkscape design -> laser cut goodness. CNC and 3D printing typically have extra/intermediate steps that will probably cause most people to drop into some other software before fabrication. (Eg extruding to 3D, or creating cutting paths that are the radius of the cutting tool away from the outline.)

Cheers,

Julian

Hi,

On Thu, Feb 2, 2017 at 1:20 AM, Máirín Duffy <duffy@...43...> wrote:

It's not that they are stupid or don't care. Their goal / focus is simply elsewhere and they don't want to have to make a decision like this - they fear them. I think it is a good practice to have a very obvious "choose this if you dont know" option, because at the very least, it is the least destructive option of any of the 3 we have to offer, it does the least amount of change to the file, and if it ended up being the wrong decision, they can manually adjust the file (I'm assuming!) later on.

I'm not saying that the tactic of having a default choice is absolutely the right one in this scenario - we can take a look at how the screen design reads with the icons, for instance, and see if it makes it clearer which option to choose - but I'm just saying with a lot of experience with this sort of problem (diff context but same problem, think storage and system management UI... ) having a 'default' is the option that users are best able to navigate and requires less cognitive load.

The tension here is the users having to learn something when they're not necessarily in the mood / have the time to learn vs. us taking on the guilt of pushing them towards something that might not be the perfect decision for them and could impact their files negatively. I do think if they choose the default option we push here, that the negative impact isn't going to be significantly high (they print it, it doesn't fit the page correctly, they adjust manually. Costs them a piece of paper, some ink, and time. Ok, so that print could be a plotter print, but still :) )

Unfortunately I think it is safe to assume that a lot of users are going to just leave it at the default safe setting, even when it is not correct for them. That is kind of the (only) idea with a default setting after all, that the lazy user can just ignore the question and click OK? Then when they print they might very well have forgotten all about that question, and even if they remember it not realise that was the problem. And even if they do remember and want to go back, that requires that they still have the backup of the file where they can find it and that they do not mind re-doing all work that has been done on the file between the time they imported it to 0.92 and first time it was printed.

Even if the end-goal is to print something, that can be far into the future. I do not think it is uncommon that you work on a file for several months (and I know, sometimes years) before first printing it. Maybe some pros are clever enough to make sure to test-print things every now and then, and carefully measure the resulting output looking for errors, but I would not count on the majority of users to do that.

So I still think, even if people using Inkscape for printed works are in a minority, they should not be mislead by a default option that can result in a lot of unneeded extra work (and some users abandoning Inkscape). Forcing every user to stop for 2 seconds to think about clicking one of two hopefully obvious choices (most people will know if they want to make art to print or just view on a screen?) does not sound like a high price to avoid that. Of course I am rather biased. :)

The first option (digital artwork) is the do nothing option, which is why it's also being pushed heavily as the default choice.

Would it not make sense to make sure the viewBox is updated so that user-units are correct even when working for screen-output? I know there are some current issues so that user-units are not respected as much as they should, but for the effects that are now working around the broken unittouu things can get ugly if the viewBox is not as expected. If someone wants to keep working with pixels as pixels it should be easy to update the viewBox to match that (and perhaps it is already being done?). I have seen some old documents with pretty weird viewBox-settings, so resetting them to say that pixels (px) really are pixels could only be good even for screen-output only users (I think?). (It looks as if Inkscape currently is cheating a bit and pretend that a px is a pixel instead of a user-unit, so having a broken viewBox might work quite ok, but I consider that a bug rather than a feature.)

Am 25.01.2017 um 21:18 schrieb Máirín Duffy:

On 01/25/2017 02:34 PM, Maren Hachmann wrote:

...

I don't understand what 'the appearance of a mask' might be (it's invisible...), and what could look wrong, if the units/physical sizes are correct.

Would it be more accurate to say "masked objects" rather than "mask" ?

- My problem was rather with the word 'appearance'. What about it should be important to me when I select this option? Appearance is a very general word.

...

Is there a way to also tell people about the downside of each method?

Yep, I did this in the extended info. I think the options get too long if it's in the radio options. Do you think this is ok?

- It would have been okay for me even if it would only be in the FAQ (as it's really going into the specifics, and users who know less than me could rather find that info confusing. Taking them by the hand and making the decision for them is okay - but I really dislike that for myself, I want to know what I'm doing and what can happen ;-)). Hiding it is nicer, though, in case one doesn't have internet access :)

http://i.imgur.com/gIieEhm.png

...

And to detect if there is a mask, filter, clone ... at all? Then it probably wouldn't matter so much which method you choose.

I believe Mc intends to add this kind of logic to make smart choices for the users, but this is meant for a quick / temporary fix to update the strings and screen layout only to address the current UI. I think he is looking at making the dialog smarter after committing a strings-only change.

- Ah, thank you, that would be cool.

...

Can someone (some time) actually do explain the difference between the two methods? FAQ item is fine.

My understanding (which may be somewhat inaccurate):

We have two "sizes" that apply to Inkscape files. There is the viewbox size, and the document size. The document size sets the size for print output. The view box sets the size for display in a browser. The document size != viewbox size always. They are linked by the DPI, and unit conversions are performed based on the DPI requested by the output medium. The document size is used for print output. Initially, Inkscape files have a document size and viewbox that are the same, and the dimensions of one are calculated based on the default DPI, but if the viewbox is changed the document size stays the same; if the document size changes the viewbox may stay the same.

The first method, which preserves the appearance, resizes the viewbox. So if the file was A4 at 90 DPI and it's changed to 96 DPI, the file will be slightly smaller than A4. So this method takes the viewbox and changes the size to sort of reset the scale on the file so it would be the full size of A4 at 96 DPI. The problem is, if you have a line of text in the file that is exactly 100 mm tall on an A4 page at 90 dpi, because everything is getting scaled together, that line of text will be bigger than 100mm on the 96 DPI A4 version created through this method.

- This is where I don't get it. So the objects are closer to each other now? (if one is bigger...) I thought this would keep inter-object relations intact, but kind of just change the density... while it still looks exactly the same when printed. I might need an example...

Or is it just that inside Inkscape, the interface tells you a different size value, while it's actually another one when printed?

So, no difference for printing, but during editing, you get (and set) 'inaccurate' values, which will not correspond to their printed real-world sizes?

The second method takes into account the sizes set on individual elements in the file. This is more problematic because filters, masks, clips, etc. might not have the exact size / position / etc relative to the objects they are applied to. However, the end result of this is if you had a line of text in the 90 DPI A4 page that was 100mm, it would still be 100mm on the 96 DPI A4 page.

- I think I start to understand... But if it's like I think it is, the main important point for me would be to stress that 'while editing it shows the correct sizes you get when printed, at the cost of masks' filters' ... positions not always being perfectly accurate, because Inkscape may get the calculation wrong (or similar)'.

...

Btw., we haven't had *any* question about the dialog meaning in the forums or in the answers section yet (which surprised me - maybe people just chose 'Ignore', as it seems the safest option...?).

While I use 0.92 now and have been using preleases of 0.92 for a while, I haven't seen this dialog box before. Mc explained it appears if the viewbox isn't set in the file (older versions of inkscape, IIRC pre 0.48 did not have a viewbox setting, it was an implied rather than explicit value) , and may not appear depending on how the document size is set in the file.

- I got it a couple of times, but mostly when I was trying out su_v's line-height fix extension.

I am thinking maybe not so many users are running into the dialog, and the few that have are loud? (I have run into line height issues messing up old mockups but the workaround trick works fine for me.)

I still have some holes in my misunderstanding here but hopefully this helps?

- Depends upon if I got it right now ;-) Thank you!

Maren

~m

On 02/02/2017 11:17 AM, Pelle Nilsson wrote:

Hi,

Just replying to the last mail in this thread I saw, without commenting on anything specific.

What about giving users the option to generate all three different documents, so that they can inspect them and decide for themselves which one they like the best? THAT option could be pre-selected, so only veteran users that understand the technical details need to guess what to do, and the default is to do all of them instead. Or would it still be too difficult for many to spot the differences without knowing what to look for?

Perhaps a bit awkward to work into the flow of opening a document (which of the three generated files will be open? all three? for instance) but maybe something that can be worked into something that works, even if not exactly as I described it here. Thoughts?

That's a really interesting idea. Rather than back it up and generate each subsequent version if you wanted to try all out, it could keep the original file then autoconvert to the other formats and say if the file has problems we made other versions for you in the same directory.

We would have to provide guidance on evaluating each version to help them figure out which one would work best, but it does bring the stakes down a little to have 4 versions of the file.

~m

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

-----Original Message----- From: LucaDC Sent: Thursday, February 02, 2017 3:35 AM To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] UX help

...

Could there be a "do nothing" option? Or is a choice needed for every

file?

...

If a "do nothing" option is added, it should maybe warn about the consquences. "This or that might happen" (or "will happen") if you don't make a choice.

The first option (digital artwork) is the do nothing option, which is why

it's

also being pushed heavily as the default choice.

I think that having a default option that does nothing completely voids the purpose of the dialog.

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. This means that if the user works a lot before realizing that something is wrong (e.g. when it comes to comparing an old and a new objects that should match or line up or whatever), the solution can be a pain: either correct the page and all new objects or rescale all new objects to the new-old (wrong) scale. This could mean acting by hand object per object, being the wrong intermixed with the correct ones.

Avoiding this situation is the reason for which I tried to stress the need of a warning to the user like "HEY: BE CAREFUL BECAUSE SOMETHING IMPORTANT HAS CHANGED AND IF YOU DON'T CARE YOU MAY CORRUPT YOUR DRAWINGS AND LOSE HOURS OF WORK!".

Now you're proposing a "do nothing" as default option for who doesn't care?!? Really, I'm a bit disappointed thinking that people fail to get the point.

I understand that creating the less stress on hurried users can have its importance. But trying not to upset them by suggesting them the wrong solution could make them angrier and I can't see how this could be thought as a wise decision. IMO it's definitely a short-sighted decision.

My opinion is that there should be a huge warning sign on the dialog, maybe the biggest object in it (better if pulsating :) ) and the user shouldn't be able to go on before understanding that there could be a problem. Maybe a first warning informative dialog with only a "I've read, I'm ready to choose my option" button that opens a second dialog with the conversion option.

And absolutely: no default option already selected or pushed, unless it's something that you're completely sure that cannot harm without possibility of recovery; which does not mean making a backup of the old document, that I assume is obvious, but that means that when the user will realize that the first choice was wrong he must have some alternative (workable) fixing procedure that saves the new work done so far.

And to confirm the choice the button should not say simply "Ok", but "Ok, do convert my document and let me see what comes out! I will check." (of course not this exact wording, which is ugly, but just to give the idea). It should be clear that the document where you'll be working is going to be different from the original so one should check that everything is fine before going on. THIS IS THE MAIN POINT: users must understand that something weird or even bad could happen to their documents and check them carefully after the conversion.

The main purpose of the dialog should be the _warning_, not the _choice_.

And for sure the "do nothing" option is not eligible as default option because it's not always safe. The only cases where it could be useful are: - the document is in px, i.e. no physical units used inside so 90 DPI or 96 DPI or whatever, makes no difference; - the user really doesn't care about the physical size of the document: maybe it has been drawn in mm or inches but no measure is relevant, only the global graphical appearance and proportions matter; - the document has physical units inside but will not be printed nor converted to other formats nor modified nor its object copy-pasted to other new documents and so on (that is, it's being opened just to look at it, without measuring anything and then closed); - the user knows how to deal with the problem so wants to open the original document and fix it by himself. In all other cases that I can think of, the "do nothing" option is harmful if overlooked.

Regards. Luca

-- View this message in context: http://inkscape.13.x6.nabble.com/UX-help-tp4978575p4978731.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

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

Hi Brynn, first of all thank you for reading and trying to understand what I've written.

I've gone straight over some concepts that would deserve a closer examination. My intent was to be as easy as possible.

In our context 1 px = 1/DPI inches. This is because when referring to "px" we mean the SVG Working Group (very unfortunate, IMHO) definition of it. It was 1/90 inches recommended and now has been changed to 1/96 inches mandatory. Moreover, in our context "px" is referred also as "user unit". In latest releases of Inkscape you can define your own user unit with regards to physical dimensions, thanks to the use of the viewbox attribute and the new internal Inkscape generated files conventions.

Your point about "real" pixels is correct: 1 pixel is a fixed size _for_each_particular_screen_ (better say: for each particular medium). This means that 1 pixel is not an absolute unit because its dimensions (plural, because there are devices on which pixels are not even square) depend on the particular device you're referring to. There's not such a possible universal fixed conversion as 1 pixel = xxx mm or 1 px = yyy inches. To link pixels and absolute physical units we need to speak about PPI, that is pixels (points) per inch. So, 1 pixel = 1/PPI inches = 25,4/PPI mm. Each real device has its PPI ratio. But, as I see, this math is exactly the same as 1 dot = 1/DPI inches = 25,4/DPI mm. This has led to interchangeable use of PPI and DPI, even if they aim to express different concepts.

In any case, resolution only matters if you need to convert between different physical mediums that each have its discrete resolution. Inkscape is a vectorial drawing program so it could not care about the resolution but only about dimensions (in whatever unit you need). So, why should I (who always draw in mm) care?

This is Inkscape's fault that chose to enforce the misunderstood claim on defining px as physical unit, using px as the only unit in which to save its files; that is converting all real physical units (like mm, inches and so on) into px @ 90 DPI. This choice has been eventually proven to be unwise when the same SVG Working Group decided to change their own "physical px" definition from 90 DPI to 96 DPI, just showing that it's not a physical unit at all (try changing 1 mm definition at your pleasure, if you can...). Fortunately in the meantime Inkscape has gained the ability of saving files in other units than px, so now you can have an entirely mm or entirely inches document if you whish so. Now only old "px @90 DPI" documents have problems because they need a conversion.

One important still missing feature in Inkscape is the ability to define a document's specific DPI ratio. This would even solve all problems with old documents. And would finally let people create, for example, a real 300 DPI document (a document in px where 1 px corresponds to 1/300 inches) in which to draw shapes using mm and inches without having to make on the fly numeric conversions (that is if you draw a 2 inches line it will be 600 pixels long).

All this is my (surely poor, hope not too wrong) understanding on the subject.

Luca

-- View this message in context: http://inkscape.13.x6.nabble.com/UX-help-tp4978575p4978771.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Hi Luca, I'm starting to understand better now. Thank you for taking the time and effort to explain. From your previous message, now I'm down to this place, where I'm stuck: "Here is the point: ...... 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 " I think it uses math symbols that I don't understand. (I've learned math with that ancient world of inches, feet and yards, rather than metric system.)

Is it 210 divided by 25? If it is, why do you divide by 25?

I think 4* 90 means 4 times 90, but I don't understand where the 4 comes from. And the comma is foreign to me, if it means anything more than pause.

Thanks again, brynn

-----Original Message----- From: LucaDC Sent: Monday, February 06, 2017 5:01 AM To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] UX help

Hi Brynn, first of all thank you for reading and trying to understand what I've written.

I've gone straight over some concepts that would deserve a closer examination. My intent was to be as easy as possible.

In our context 1 px = 1/DPI inches. This is because when referring to "px" we mean the SVG Working Group (very unfortunate, IMHO) definition of it. It was 1/90 inches recommended and now has been changed to 1/96 inches mandatory. Moreover, in our context "px" is referred also as "user unit". In latest releases of Inkscape you can define your own user unit with regards to physical dimensions, thanks to the use of the viewbox attribute and the new internal Inkscape generated files conventions.

Your point about "real" pixels is correct: 1 pixel is a fixed size _for_each_particular_screen_ (better say: for each particular medium). This means that 1 pixel is not an absolute unit because its dimensions (plural, because there are devices on which pixels are not even square) depend on the particular device you're referring to. There's not such a possible universal fixed conversion as 1 pixel = xxx mm or 1 px = yyy inches. To link pixels and absolute physical units we need to speak about PPI, that is pixels (points) per inch. So, 1 pixel = 1/PPI inches = 25,4/PPI mm. Each real device has its PPI ratio. But, as I see, this math is exactly the same as 1 dot = 1/DPI inches = 25,4/DPI mm. This has led to interchangeable use of PPI and DPI, even if they aim to express different concepts.

In any case, resolution only matters if you need to convert between different physical mediums that each have its discrete resolution. Inkscape is a vectorial drawing program so it could not care about the resolution but only about dimensions (in whatever unit you need). So, why should I (who always draw in mm) care?

This is Inkscape's fault that chose to enforce the misunderstood claim on defining px as physical unit, using px as the only unit in which to save its files; that is converting all real physical units (like mm, inches and so on) into px @ 90 DPI. This choice has been eventually proven to be unwise when the same SVG Working Group decided to change their own "physical px" definition from 90 DPI to 96 DPI, just showing that it's not a physical unit at all (try changing 1 mm definition at your pleasure, if you can...). Fortunately in the meantime Inkscape has gained the ability of saving files in other units than px, so now you can have an entirely mm or entirely inches document if you whish so. Now only old "px @90 DPI" documents have problems because they need a conversion.

One important still missing feature in Inkscape is the ability to define a document's specific DPI ratio. This would even solve all problems with old documents. And would finally let people create, for example, a real 300 DPI document (a document in px where 1 px corresponds to 1/300 inches) in which to draw shapes using mm and inches without having to make on the fly numeric conversions (that is if you draw a 2 inches line it will be 600 pixels long).

All this is my (surely poor, hope not too wrong) understanding on the subject.

Luca

-- View this message in context: http://inkscape.13.x6.nabble.com/UX-help-tp4978575p4978771.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

Thank you Tav for neatly formatting and explaining my mathematic mess. Sorry for the notation.

I hate Excel for having forced me to use the comma when I'm used to the dot everywhere else (with a keyboard, of course). Now my brain always struggles when writing numbers inside a text and it usually switches to "comma mode". I suppose I'd better always use the dot when writing in English.

Luca

-- View this message in context: http://inkscape.13.x6.nabble.com/UX-help-tp4978575p4978787.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Hi Everyone, Copying Mairin in. I've lost track of everyone who has commented in this thread. But I guess they are still watching it, and can still reply if they want to. After reading all of Luca's very generous explanations (and thanks again), I have to agree with some of it. I wonder if we could work in something like "If you're planning to save new edits to this file, it's important that you choose one of these options. If you don't, and you save new edits to this file you'll have content that was created in 2 different scales, and some objects will be the right size while others will be too small. If you're not going to save new edits to this file at all, you can choose 'do nothing'. If you're going to copy something out of this file, and paste into version 0.92, you will need to scale that object after it's pasted in." I'm actually not sure if that's correct. But I do that quite a lot, copy something out of another file. So maybe it should be mentioned. Of course it all needs to be said in more concise language. And here's another "what if". (Now that I understand more, I'm thinking about all the reasons I might have for opening old files.) What if someone opens an image they made in an earlier version, and decides to use File menu > Save a Copy. Won't that save the file with version 0.92? How can that be addressed? I guess the dialog needs to pop up at that time? Or does it literally save the file just like it is? I agree with Mairin's earlier comments about the need for a default choice, because people are in a hurry or whatever. But I also agree with Luca, that the default without any notification of the consequences will result in nightmares for users as well as nightmares for users who support other users (forums, mailing list, irc, etc.). So far, I haven't converted any files. So I don't know what happens the next time you open that file. The developers must have put in some kind of flag, so Inkscape won't continue asking to scale a file that was already scaled (one way or another). Also we need to find out which option the gcodetool users, and all the cutting/plotting users need to choose (I assume 'scale element' or 'accuracy of scale'). So it should be mentioned next to "3D printing". Probably can be shortened to "cutting/plotting". I also realize that including Luca's points will push back the dialog from being finished, and maybe too late for 0.92.1. But now that I understand it better, I think Luca is making some good points that need to be addressed. I'll continue to help in whatever way I can. Thanks again for everyone's hard work on this!

All best, 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