To reproduce: -On a A4 300 DPI canvas, draw a shape with freehand path tool on a vector layer. At 100% zoom the shape on screen looks very aliased and "fat"... -Then use "scale to new size", lock "Size in pixel" so the canvas stay the same size, and in the Resolution value insert the DPI value of your screen (I tried first with an estimate value of 90DPI taken from inkscape default render resolution, then I checked my screen DPI is 91,79 ...). Look again the previously drawn shape (you may have to click twice on the "use same aspect as pixel" button on the bottom left to "refresh" correctly the canvas size, that's another I just noticed...) At 100% zoom it now look smooth. And now drawing another shape with the same tool, same settings, it makes a good shape, with thinner outline (as I would expect at any DPI...) I think the problem is that somehow the shapes are "rendered" in the screen resolution DPI and then upscaled to document 300DPI are anything, and it seems wrong as it should be rendered in the canvas resolution from the begining.
It's not the rendering, the shape are rendered with image resolution and no upscaling after that. You can test to Layer->Rasterize Layer, which should give the same effect. I think it might just be that a sharp line will appear a bit blurry at some zoom levels.
Created attachment 76591 [details] kra file showing the problem See the problem with this file: -I did draw and rasterize result at 300 DPI (kept a copy of original layer..) -Changed DPI to 90, keeping same actual pixel size. -Re-draw with same tools, same settings: result is much more clean.. Knowing this I could live with the workaround of always make original work files at 90PPI with then a huge dumb print size value, export at the end and switch DPI/Print size on exported file to correct values, but this is a bit weird ;)
I want to add a note saying that either it's what I said above, or it's just that in Krita "core" pixel/inch really is a different thing than the DPI used for printing (as actually pixel/inch is used for display, while Dot/inch is used for print), in which case the problem is the Print size shouldn't be relative to pixel/inch, and so maybe add another actual DPI value related to print size (and so fix the canvas presets to not use PPI values but real DPI instead). What do you think about this?
Ok I've made more precise test, and here's the problem: every shape values assume a ppi of 72ppi (as does most software for historical reasons...) and so for proper result with shapes the document ppi must be set to 72. Iv'e made 2 files to show exactly this: -kritaShape-72ppi.kra is a 10x10px canvas, set the ruler to 1pixel and show the ruler to see the lines outlines are exactly the pixel size shown in the stroke properties docker (left line is1ps, right line is 2px) -kritaShape-300ppi.kra is the same 10x10px canvas, set the ruler to 1pixel and show the ruler to see the line outline is ~4pixels wide although the stroke properties docker say 1pix (that comes from 300/72=~4) So in my opinion best and easiest way to fix this would be to always use 72ppi anyway, remove the wrong "links" between ppi and print size in "Scale to new size" and maybe add a proper DPI value relative to image pixel size and print size. Of course all templates must be updated accordingly, not a problem. It think that's the best/proper way to fix it as anyway "Pixel Per Inch" really is relative to screen display, not to print size in any way, as that is then "Dot Per Inch" for print.
Created attachment 76813 [details] shape at 72ppi -ok
Created attachment 76814 [details] shape at 300 ppi - wrong width
PS: for the test file, if you convert the 72ppi file to 300ppi but keeping it a 10pix, result is somehow ok. The problem is more evident when creating shapes with file already at 300ppi.
Ack. Maybe we can fix this problem when we get multi-res layers in images.
Git commit 08e0b021165e712c722084577a92202362be0fc6 by Sven Langkamp. Committed on 01/10/2013 at 10:37. Pushed by langkamp into branch 'master'. don't turn of anti-aliasing in shape layers at some zoom level, looks ugly M +2 -6 krita/ui/flake/kis_shape_layer_canvas.cpp M +0 -1 krita/ui/flake/kis_shape_layer_canvas.h http://commits.kde.org/calligra/08e0b021165e712c722084577a92202362be0fc6
Created attachment 82584 [details] Screenshot There is something crazy going on. When I create an image with 300 dpi and insert a shape, it will be thicker than it should be. Then I scale the image to 72 dpi it wil stay thick, but when I copy it the new shape will have the correct line width.
*** Bug 341107 has been marked as a duplicate of this bug. ***
The workaround is bad if you're used to unchecking the "Use the same aspect as pixels" option next to the zoom slider.
Git commit fddc5e9cc648c4d0eceb67b793faa3c0c14b8d62 by Dmitry Kazakov. Committed on 28/11/2014 at 11:14. Pushed by dkazakov into branch 'krita-chili-kazakov'. Fix Default tool widgets to show values in real pixels, not points Now the option widgets use correct KoUnit object to convert their options in correct user-visible pixels. Some note on the implementation: 1) Affects KoStrokeConfigWidget and DefaultToolWidget 2) The correct conversion value is stored in KoUnit, which is reported by KisCanvas2 and retransmitted by KisView2. 3) There is a hack in KoStrokeConfigWidget. KoShapeStroke knows nothing about the absoluteTransformation() of the shape, which doesn't stop the shape from doing the transformation of the outline (loaded into QPainter directly). So we take it into account manually, by adding a multiplier into KoUnit. Related: bug 341107 M +17 -1 krita/ui/canvas/kis_canvas2.cpp M +2 -0 krita/ui/flake/kis_shape_controller.cpp M +2 -1 krita/ui/flake/kis_shape_controller.h M +4 -0 krita/ui/kis_view2.cpp M +3 -1 libs/odf/KoUnit.h M +35 -2 libs/widgets/KoStrokeConfigWidget.cpp M +12 -1 libs/widgets/KoUnitDoubleSpinBox.cpp M +3 -0 plugins/defaultTools/defaulttool/DefaultToolWidget.cpp http://commits.kde.org/calligra/fddc5e9cc648c4d0eceb67b793faa3c0c14b8d62