• Thank you @ede123 ! Fixed punctuation a bit, and some tiny typos. Overall, I think it's written very understandably. Especially, I like that it gives examples, which was missing from all previous attempts of explaining the issue.

    What confuses me (in the interface, not here) is that the details section seems to relate to the second option with its sub-options only, but it's visible already when you're still deciding on first/second option, and also doesn't follow the terms from the options consistently, so it adds to the confusion rather than reduce it. Perhaps it could be moved up, to make it clear where it belongs, at least, without needing to change the wording?...

    Would be helpful if the methods were numbered in the interface, too, then consistency with FAQ items would be given.

    What I still miss is the explanation how an element that takes up one third of a 3cm page, with the document's viewbox adjusted, can be smaller than 1cm, in option 2a. Where is it smaller? How can I see that it's smaller? Where is the size shown wrongly? (or correctly, in whichever direction you define that). How do I notice? Does it make a difference when I output a pdf? Can't I expect a 3d printer/... or the export extensions of Inkscape to be able to deal with this, when a browser can? If not, why not? (there's a hint in 2b, that starts explaining this a bit).

    If I do this with a group, in Inkscape, the element's size is always reported correctly, in relation to the page size. The analogy to the viewbox is the group's transform attribute. But in which cases is the viewbox/the transform attribute not taken into account?

    @brynn: This is the dialog we're talking about:

    First view:

    dpi_dialog0

    Click on details:

    dpi_dialog1

    When you select second option:

    dpi_dialog

    Click on details:

    dpi_dialog2

  • What confuses me (in the interface, not here) is that the details section seems to relate to the second option with its sub-options only, but it's visible already when you're still deciding on first/second option, and also doesn't follow the terms from the options consistently, so it adds to the confusion rather than reduce it. Perhaps it could be moved up, to make it clear where it belongs, at least, without needing to change the wording?...

    Would be helpful if the methods were numbered in the interface, too, then consistency with FAQ items would be given.

    Those all seem like good suggestions but I'm afraid it's a bit too late (at least for 0.92.2). We also can not simply move the text I think: The first section of "More details..." has the general explanation and the last component is the link to this FAQ, both which should be kept visible at all times.

    What I still miss is the explanation how an element that takes up one third of a 3cm page, with the document's viewbox adjusted, can be smaller than 1cm, in option 2a. Where is it smaller? How can I see that it's smaller? Where is the size shown wrongly? How do I notice?

    The problem is that in the UI you don't notice this, except when looking into the document properties (where the scale will be ≠1) or into the XML editor (where you will then see that in fact all elements are stored smaller than they appear on canvas). Inkscape does all the scaling behind the scenes, so that in the UI always scaled sizes are shown, even if the actual size of an element that is stored in the XML code differs significantly.
    If you know how to clarify this part I'm all ears since I guess this might also be the most confusing part for users. I hoped the sentence "This is the best option if you want to preserve visual appearance while scaling your document and it's the correct choice in most cases where scaling is required." would cover this base sufficiently though for users who do not understand the difference as I'm unsure how to explain those "ugly details" to a user who does not know anything about how an SVG document works internally without causing even more confusion.

    Does it make a difference when I output a pdf? Can't I expect a 3d printer/... or the export extensions of Inkscape to be able to deal with this, when a browser can? If not, why not? (there's a hint in 2b, that starts explaining this a bit).

    That's a question to ask the people who were actually involved in implementing this change initially but don't seem to be interested to follow up on these details anymore (or in writing the FAQ entry at that). Probably in an ideal world it would work exactly as you describe...

    If I do this with a group, in Inkscape, the element's size is always reported correctly, in relation to the page size. The analogy to the viewbox is the group's transform attribute. But in which cases is the viewbox/the transform attribute not taken into account?

    I guess that group transforms might lead to similar issues, but again: That's a question for the people who were actually involved.

    Edited by Patrick Storz
  • Should we tag someone?

    I'd suggest making these changes then: (replaced 'scaling by photocopying' by 'setting a different print quality option' - which is technically more correct. But not sure if it helps.) Also added the info that more advanced users who want more details might look for (viewbox).

    Method 2b would only scale elements whose sizes are given in user units, right? I think it's possible to give an object size in SVG code in mm, cm, ... - and those would not change. But Inkscape does not create any object descriptions like that, correct? Added example numbers, converted to inch, because that saves one step in the calculation.


    All artwork of this type needs to be scaled to keep physical dimensions identical, and there are two approaches for this scaling that have different strengths:

    • Method 2a preserves the visual appearance of elements, especially for clipped or masked objects, filters, and clones. For this option, Inkscape scales the whole drawing as if it were one big group (by adapting the SVG document's viewbox attribute).
      This means that the size of each individual element in the SVG source code that describes it will not be changed to accomodate the different dpi value, but that after scaling the whole image, sizes will be as expected. Inkscape will always display the resulting object sizes in the user interface, and they will not differ from the sizes shown in previous Inkscape versions. You can compare this process to copying a sheet of paper and setting a quality factor for the printout in your copier - the document's elements will not be moved, or altered in any way, only their level of detail (the resolution) will be different. This is the best option if you want to preserve visual appearance while scaling your document and it's the correct choice in most cases where scaling is required.

    • Method 2b preserves the physical size of each individual element. For this option, Inkscape scales each element separately. This means that an element that was 10 inch long in Inkscape 0.91 (think of a 1:1 drawing of a ruler), i.e. it had a length given as 90 in the SVG source, will still be 10 inch long after scaling in Inkscape 0.92 (but will have its length given as 96 in the source). This is especially important if the path data itself has to be used (for example to provide coordinates for a 3D printer, plotter or cutter) as each path is scaled individually to the actually required size. The downside: Scaling each element individually is error-prone and might result in different visual appearance (especially for the elements listed above) and can even fail completely in some cases. Only use this option if you depend on unscaled elements with proper physical size in the resulting SVG file.

    Edited by Maren Hachmann
  • I'd suggest making these changes then: (replaced 'scaling by photocopying' by 'setting a different print quality option' - which is technically more correct. But not sure if it helps.) Also added the info that more advanced users who want more details might look for (viewbox).

    Sorry, but even I am utterly confused by the term "print quality option" in this context. While it could be used to describe the fundamental change (probably in a confusing way though as it's basically a raster concept), in this case I really meant "take the whole document and scale it" in contrast to "take every element in the document, give it a new size and put it back". Talking about "level of detail" or "resolution" of a vector object doesn't make any sense in my opinion.

    For all your questions on Method 2b I'm really not the right person to ask as I never looked into the details (and I also don't want to - I really only took on this job as nobody else seemed to care and I didn't want to have a broken link in the release). I could make an educated guess at this point but it would probably be more efficient to ask @jabiertxof or @su-v (they were both involved in the extension which does the actual scaling) or maybe @Tavmjong (who I was told introduced the DPI change to start with).

  • No worries, Eduard, those were just ideas. Let's hope we'll also get the promised feedback from brynn.

  • Yeah, sorry if I sounded negative.

    I like the first part (viewbox) and also what you've done to Method 2b (given it really works like that - I didn't check). Actually it sounds much more mathematically as I'd dared to add myself (I was already afraid you'd tear the the calculation in the introductory part out ;-) )

  • No, having a concrete example makes it a lot more intellegible. Not just soft descriptions that could be interpreted differently, but facts. The kind of users who I imagine will take a closer look may be those who do use a 3D printer, or a plotter, and are somewhat technically inclined already. The others who don't know what it's about (in my imagination, at least) will just click the 'choose if unsure' option, and be done with it - they might not be interested in the details anyway. But I may be wrong, it's just a prediction.

  • On 2017-08-06 02:23 (+0200), @ede123 wrote:

    I could make an educated guess at this point but it would probably be more efficient to ask @jabiertxof or @su-v (they were both involved in the extension which does the actual scaling)

    Wrong - the scaling (like all other options in that dialog) is done internally (by core inkscape), not by that extension.

    The extension is mostly a legacy option or relict (IMvHO), available via Extensions menu.

  • Thanks for clarifying. I noticed the two of you discussing about this extension when 0.92 was about to be released and issues with DPI scaling were discussed so I made a wrong connection in my mind.

    The scaling is done in file-update.cpp and @marcjeanmougin is the go to person.

    Edit: Then again su_v pointed out that there was also code in master in file.cpp even before that... Really feels like a scavenger hunt!

    Edited by Patrick Storz
  • I've updated the text a bit adding a "Further information" section with pointers for advanced users who might land on that page.

    I incorporated most of @Moini's suggestions and also re-worked Method 2b a bit (I think it should be more clear now). Regarding Method 2a: I cut any printer analogy out completely now (if it was confusing to us it will be confusing to readers). Instead a much better analogy (at least I think it is) came to my mind. A magnifying lens should visualize the concept nicely (and the analogy is even mathematically correct as a magnifying lens creates an affine transform, too! ;) ).

  • Thank you, @ede123 , looks very complete and understandable to me now. I wish we could get feedback from someone who has a less technical background than we do, before publishing. @brynn : Would you have some time to take a look here?

  • To get on the analogy, basically, SVG with size and viewbox is like giving you both a drawing and a ruler. Option 2a changes your ruler, option 2b changes your drawing.

    Some external tools (eg tools linked to plotters/cutters) don't "follow" the "ruler" of the svg file and try to read info from the content and (wrongly) assume things about the sizes, so fixing the ruler has no effect on them.

    But for any tools that correctly support svg, and ignoring possible bugs, both options should have the same apparent (from the pov of the appearance and export to e.g. pdf) behavior

    (edit: and option 1 is "what should I need a ruler for? I'm using abstract units")

    Edited by Marc Jeanmougin
  • ^ I like that analogy... Thank you for explaining the issue with the plotter tools, too, @marcjeanmougin . Finally, I think I've got a half-way accurate understanding, or at least no open questions anymore.

  • I went ahead an published the article after some final polishing, see https://inkscape.org/en/learn/faq#dpi_change

    If anybody notices something that still needs updating now's the time, otherwise we can probably drop translators a note (do you want to do that @Moini ?).

    Edited by Patrick Storz
  • Yes, I will. Btw. which link have you added to our German translation file? (i.e. do I need to translate this second or first? News, FAQ, release notes).

  • Sorry, I'll look it up myself, silly question :)

  • Thanks! (In case you didn't look it up yet: I didn't modify the link so it points at https://inkscape.org/de/learn/faq#dpi_change like you originally put it)

  • :) Just started translating... We should have kept it shorter :-P

Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment