The first step to export in a higher resolution is to change the resolution, which changes the width/heigh. For instance, an object with a width of 10cm becomes 1cm when the resolution is increased by 10x. But this dependency is not clear from the UI. Second problem, deleting the number separator (dot or comma) for a high resolution starts an internal calculation of the expected output size that takes very long and fails silently in the end (0kb).
The user expects to define the width of the output sometimes in cm but most often as pixel. As a second step he or she wants to fine-tune the resolution (dpi). But changing the pixels per inch when the width is defined in inches makes not much sense resp. would change the image width. Proposed solution: We add a third input and show width, number of pixels, and resolution with the option to manipulate every value resulting in an update of the depending fields. The three options get radio buttons that define what of the three options is fix as we have it for RGB/CMYK/HSV in the color picker. Alternatively, we add a 4. control like a dropdown that defines what of the three controls is sticky. The resulting workflow in both cases is that I change on field resulting in an update of the second while the third is "sticky".
The issue was part of the discussion in bug 37678.
Confirmed: draw and impress are vector drawing, so the expected behavior is to keep the physical size. Increasing the resolution should increase the number of pixels.
Created attachment 142611 [details] Mockup for the dialog Hard to understand my own comments, but this mockup should make it clear. What kind of size (better terminology granted) is modified is selected per radio button including the third option of number of pixels. As cherry on top of the cake I moved the Mode/Drawing Object categories into an Options category together with the compression slider.
- There is no need for radio buttons, it should be a play between 3 values where you can change any of those depending on what you want to know. In almost all cases users only care about pixels, but sometimes you want to know something like: "If I print with a 300 DPI printer and want a 12" image, what should the pixel dimension be". - There is not drop down for pixels, that is the absolute value of the image, the only one that has the influence for the bitmap image (logical units and the ratio are a informative value only in bitmap images) - Pixels should be top as they are most important value - pixel width and height - Maybe only have a switch between imperial/metric which changes both - resolution and the logical dimension unit - Information is a lame guesstimate, almost always wrong currently. Who cares about the memory, the exact compression could be calculated instead (like in compress image dialog)
(In reply to Tomaz Vajngerl from comment #5) > - There is no need for radio buttons The RBs make it clear that values change depending on each other. That's the essence of this request. > In almost all cases users only care about pixels I never do and don't know users who think like "This drawing should have 87346832 pixels to fit nicely into my document with good printing output" > - There is not drop down for pixels Again, the idea of this ticket is it to make the mutual dependency between the three values clear. To be precisely, you can change two of the three parameters - but usability/simplicity wise I wouldn't do that. > - Maybe only have a switch between imperial/metric which changes both - > resolution and the logical dimension unit You have a dropdown right now to select what unit you want to change - including pixels.
Created attachment 142619 [details] Export as an image in Karbon
(In reply to Heiko Tietze from comment #6) > The RBs make it clear that values change depending on each other. That's the > essence of this request. No, the RB's do exactly the opposite. The unselected mean they are irrelevant, disabled, which is exactly what they aren't. Noone does is like this - gimp, inkscape, krita, karbon. > > In almost all cases users only care about pixels > > I never do and don't know users who think like "This drawing should have > 87346832 pixels to fit nicely into my document with good printing output" We are dealing here with bitmap images - their pixel dimensions (width and height) is the most important information. The logical size and DPI is in best case included in the meta-data as a hint. http://www.rideau-info.com/photos/mythdpi.html Actually, looking at Karbon (see attachment 142619 [details]) - it has the ideal UI for that. Pixels first, then logical units and resolution.
(In reply to Tomaz Vajngerl from comment #5) > - There is no need for radio buttons, it should be a play between 3 values > where you can change any of those depending on what you want to know. That's true, but it requires some experimenting to understand what is going on. Radio buttons could be used to indicate what is kept fixed. In this case, what is grayed out would be reversed with respect to Heiko proposition: if size is "fixed", it is grayed out, dpi can be changed, which automatically changes pixels or pixels can be changed, which automatically changes dpi if dpi is "fixed", it is grayed out, pixels can be changed, which automatically changes size or size can be changed, which automatically changes pixels if pixels is "fixed", it is grayed out, size can be changed, which automatically changes dpi or dpi can be changed, which automatically changes size This would be clearer, IMO. > In almost all cases users only care about pixels, but sometimes you want to > know something like: "If I print with a 300 DPI printer and want a 12" > image, what should the pixel dimension be". > - There is not drop down for pixels, that is the absolute value of the > image, the only one that has the influence for the bitmap image (logical > units and the ratio are a informative value only in bitmap images) > > - Pixels should be top as they are most important value - pixel width and > height > > - Maybe only have a switch between imperial/metric which changes both - > resolution and the logical dimension unit As an example, for publications, the most common usage is that we know the physical size that fits the column width, and also know the dpi that the editor expects. The number of pixels is really secondary. Actually, for a vector graphics software, I would expect this to be the most common usage during png export. > - Information is a lame guesstimate, almost always wrong currently. Who > cares about the memory, the exact compression could be calculated instead > (like in compress image dialog) Having an expected png file size information would be very helpful.
Created attachment 142621 [details] Mockup for the dialog Have to correct myself (the discussion with Regina and Armin was some time ago). Comment 9 describes what I have in mind. But actually there are always two parameters that can be modified at once, so the new mockup has a toggle button that locks one of the parameters, here number of pixels. Changing the dimension must result in a smaller resolution (that's how it works today). But what the user wants is a constant resolution and changing width/height ends up in more or less pixels.
(In reply to Heiko Tietze from comment #10) > <...> the new mockup has a toggle > button that locks one of the parameters, here number of pixels. I like this lock toggle button, its action is very clear. > <...> > But what the user wants is a constant resolution and changing width/height > ends up in more or less pixels. Agreed; this should be the default case. Adding a mockup for this case might be even more convincing ?
First of - change the "number of pixels" (as you self admitted it is meaningless to the users) to pixel width and height as other programs do and users are used to. Number of pixels "clever" as number of pixels is, it is not what users have a feeling for (as you self admitted). Locking seems superfluous to me. We just need to decide the order in the meaningful way. I would do it like this: - change pixel width or height changes logical width and height - change logical width or height changes pixel width and height - change of resolution changes pixel width and height This should work well for those people who want to just define the pixel dimensions and for those who wants to define a logical dimension and the resolution factor. I must again emphasize that pixel width and height is the only absolute parameter that defines the bitmap, logical dimensions or resolution is written to the bitmap as metadata (usually the resolution only) and will or will not be taken account when the bitmap is later used. The problem with current dialog is that you have the possibility to set either the pixel dimensions or one of logical dimensions and separately the resolution. The misunderstanding for users occurred when because the change of resolution changed the logical dimension and change of logical dimensions changed the resolution. One problem was that this was not visible and the second problem was that this did not change the pixel dimensions, so users thought the change did not have any effect. Order I propose doesn't create this situations - locking can still do this.
I disagree with Tomaz order. I want to export so, that the png has the same width and height as the original vector graphic object and I want to set the DPI according the purpose of the export. I do not care in how many pixels this settings result. Using a "lock"-icon is a good idea to make clear, what can be changed and what not. That is better than the radio button in a previous mockup. But I agree with Tomaz, that it would be better to have width and height for pixels, that is much better understandable. And for preventing to generate too huge images, the information part is sufficient.
(In reply to Regina Henschel from comment #13) > But I agree with Tomaz, that it would be better to have width and height for > pixels, that is much better understandable. And for preventing to generate > too huge images, the information part is sufficient. You had the idea with the third category resp. to show all dependencies at FOSDEM :-). Anyway, the user needs to know today at what input she starts to get the desired result. Changing dpi afterwards spoils the input (or vice versa). That needs to be fixed, and I'm the first to agree with simplification.
(In reply to Heiko Tietze from comment #14) > You had the idea with the third category resp. to show all dependencies at > FOSDEM :-). Yes, but showing the total pixels is useless for the user. If the user wants an image of 200px width, he surely do not want to calculate himself, how many pixel he needs for the height to keep ratio and to multiply width and height for to enter that value. So please change the mockup to have separate width and height fields in category 'Pixels'.
Created attachment 142672 [details] Mockup for the dialog (In reply to Regina Henschel from comment #15) > So please change the mockup to have separate > width and height fields in category 'Pixels'. Different units are available right now via dropdown. If we remove the total numbers of pixels the dialog looks a bit overcomplicated; taking Tomaz comment into account that the dpi value is rather an advice we could drop the dependency and have just an input field, e.g. a combobox with common values 72,150,300..., that doesn't depend on the size.
(In reply to Regina Henschel from comment #13) > I disagree with Tomaz order. I want to export so, that the png has the same > width and height as the original vector graphic object and I want to set the > DPI according the purpose of the export. I do not care in how many pixels > this settings result. I can live with the different order. > Using a "lock"-icon is a good idea to make clear, what can be changed and > what not. That is better than the radio button in a previous mockup. I still don't understand why we need to "lock" something. All three parameters are changeable, they just depend on each other. Changing DPI that changes the logical width or height is essentially a no-op, which causes a lot of confusion now, so why allow it in the first place..
(In reply to Heiko Tietze from comment #16) > Different units are available right now via dropdown. No... pixels have a different meaning than logical units. We can't mix them together, or at least we need to show the final pixel dimensions (width and height) in the dialog all the time and somewhere near the (for example like Gimp does it when you create a new image).
(In reply to Tomaz Vajngerl from comment #17) > I still don't understand why we need to "lock" something. All three > parameters are changeable, they just depend on each other. There exists three situations: Change widht/height length and change DPI => Pixels are calculated Change width/height in pixels and change DPI => width/height length is calculated Change width/height in pixels and change width/height length => DPI is calculated So if the user changes e.g. width/height length, you cannot change DPI or pixels automatically, because there are two situations in which a length change are possible. Locking one of them makes it possible to calculate the other. (In reply to Heiko Tietze from comment #16) > Different units are available right now via dropdown. You cannot offer pixel as length in this context. Because here 'pixel' do not mean a length unit, but reflects the number of color items. Only with the additional information of DPI you get a length from it. That is different from e.g. CSS.
(In reply to Tomaz Vajngerl from comment #18) > No... pixels have a different meaning than logical units. (In reply to Regina Henschel from comment #19) > You cannot offer pixel as length in this context. That's a very technical explanation and users likely do not understand the difference. The expectation is to export the image with 10cm/in or 1000px (don't think other units are used). To solve the issue we can make dpi an independent property or give better feedback what effect a modification has.
A symmetrical yet clear layout would be 3 groups (i.e. 3 lockers) of two numbers: 1) physical size (width, height) with a toggle to keep aspect ratio fixed 2) pixel size (width, height) with a toggle to keep aspect ratio fixed 3) dpi (width, height) with a toggle to keep their ratio fixed In this way the user can choose what to fix, and what to control, and see immediately the outcome of the changes.
*** Bug 119149 has been marked as a duplicate of this bug. ***
*** Bug 119684 has been marked as a duplicate of this bug. ***
Created attachment 144664 [details] presentation minimizer for resolution This is the dialogue from Impress presentation minimizer (Impress -> Tools -> Minimize Presentations). It's the same than use export to pdf. can we have the same for draw. the user define at the export the compression quality and the image resolution. That's it. Size (widthe and height) of an Image should be the the same than you define it in page properties. Only the resolution change. When you export something as pdf you didn't get asked to define the width and height of the pdf it will use the document size the user had defined. just simple resolution and compression that's it.
That dialog is not suitable, because here the origin for export is a vector graphic. A jpg or png image already consists of a specific amount of pixels, a vector graphic has no pixels at all.
(In reply to Regina Henschel from comment #25) > That dialog is not suitable, because here the origin for export is a vector > graphic. A jpg or png image already consists of a specific amount of pixels, > a vector graphic has no pixels at all. pixel graphics consist of an size (width and height) and a resolution. Some apps change the size and resolution to pix width and height cause they don't care about resolution. But as you already define the paper size in draw only resolution is needed to get a usefull result. In image shrink in impress or writer, ... also have resolution and compress rate.
This bug is reported on Draw, but Writer has the same problem. Word processors like Writer work with documents made up in inch or cm / mm. So when I design a writer document, the pages are set up in cm. If I want to export such a document to a jpg or png file, the only thing I want to do is set the proper dpi setting. When I do that, the document size (in cm) should stay the same, unless I explicitly want to change it.. At present Writer seems to calculate the number of pixels the graphics file will have, based on the size in cm, en the screen resolution (96 dpi). That image seems to exist when the UI is shown. When I change the dpi setting, the size of the document in cm also changes. I will then have to change the size of the document in cm, and then Writer will recalculate the image, but based on the pixels, not with the original odt document as input! That will always result in lower quality. At least this is how it appears to be happening. If you want to make changes to the size of the document in inch or cm or pixels, that's fine with me. Normally you begin with the dpi setting, and then you change the size of the document, you can use inches, cm, or pixels as desired size. The graphics document should always be calculated from the original odt file, never recalculated from some intermediate graphics file made up out of pixels.
*** Bug 132657 has been marked as a duplicate of this bug. ***
Created attachment 160335 [details] symetrical design mockup Here is a mockup for comment #21, to make it clearer. The showed use case is 1) keep the physical size fixed (click on this row lock ToggleButton) 2) change resolution, e.g. 150 dpi (keep ratio checked, so it has to be entered only once) The sizes in pixels (the remaining row) would change accordingly. If there is an interest, the dynamics could be demonstrated with a small python/gtk application.
(In reply to edera from comment #29) > Here is a mockup for comment #21, to make it clearer. That looks pretty nice and straightforward. I guess the locked property is disabled as well as the vertical input when [x] keep ration is checked. Minor issue: you cannot change the vertical value and get the horizontal adjusted automatically. Don't get the dropdown for dpi and perhaps we can drop all the units and use what's specified in tools > options. Modification to the layout could be to have a headline "lock" with radio buttons bellow (o) physical size, ( ) pixel number, ( ) resolution. And just one aspect ration checkbox, don't see how it works for one but not the other.
(In reply to Heiko Tietze from comment #30) > That looks pretty nice and straightforward. Thanks ! > I guess the locked property is > disabled as well as the vertical input when [x] keep ration is checked. > Minor issue: you cannot change the vertical value and get the horizontal > adjusted automatically. In my mind, it is symmetrical: when "keep ratio" is checked, when one changes an entry, the other one in the same row is adjusted. (more below) > Don't get the dropdown for dpi Maybe someone would like pixels/cm ? But that can be left out for now. >and perhaps we can > drop all the units and use what's specified in tools > options. Makes sense. > Modification to the layout could be to have a headline "lock" with radio > buttons bellow (o) physical size, ( ) pixel number, ( ) resolution. OK > And just one aspect ration checkbox, > don't see how it works for one but not the other. There is a single master: the entry with current focus. The "keep ratio" works row-wise (it updates the other entry in the same row, so their ratio stays constant). Use case: 1) Lock the resolution, 2) change only the physical height (with unchecked "keep ratio" for this row) 3) then lock physical size 4) change resolution (keeping the default checked "keep ratio") With three separate "keep ratio", you spare a lot of check/uncheck. To lift any ambiguity, when a row gets focus, the other rows "keep ratio" could be hidden.
Keep ratio? What's the use case when you don't want to keep ratio?
(In reply to Tomaz Vajngerl from comment #32) > Keep ratio? What's the use case when you don't want to keep ratio? The question is probably about the resolution line. For instance there are AFM (atomic force microscopy) images that have elongated pixels. For the displayed physical size to be correct, this has to be taken into account. But I agree this is a corner case, that can wait, hence the default to "keep ratio" for resolution. Let's say it's for consistency, for now.
The graphics engine of LibreOffice is not really meant for picture manipulation, like changing ratio. I use Affinity Photo for all my picture manipulations, and then I insert the image with the proper dpi and size (in cm). This bug is about exporting office documents as png or jpg. I noticed that the documents will be exported with the display dpi (96 in my case), and then recalculated in the desired dpi (often 300 for prints). That will result in loss of quality. For instance if the page has a 300 dpi image inserted, the number of pixels will be reduced at first (to 96 dpi), and then increased again to 300 dpi. That is not the way it should be. If a document has to be exported to png or jpg, the resulting image should be calculated in one step, so in this case to 300 dpi.
At present exporting a writer document to a jpg file still does something extremely annoying. The standard resolution it gives me is 96 dpi. When I change it to 300 dpi, it changes the size of the document in millimetre!! I will then have to change the size of the document back to its original size. This is very stupid. I design a document with a certain physical size in mind, that is what you do with a word processor. When I want to save it with a certain dpi setting, I obviously want to keep the physical size of the document! Changing the dpi setting should have no influence on the physical size of the document.
*** Bug 138765 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #36) > *** Bug 138765 has been marked as a duplicate of this bug. *** I reopened bug 138765. It's similar because I want to add resolution (DPI) as a third way to control the displayed size of an inserted image, alongside scaling percentage and display dimensions, but without changing its pixels or file size. So the two dialogs would have similar Dimension and Resolution fields, and a Keep aspect ratio checkbox. My mockup is attachment 168178 [details]. Thanks for everyone's efforts!
(In reply to skierpage from comment #37) > [...] I want to add resolution (DPI) > as a third way to control the displayed size of an inserted image Your mockup is beautiful ! But is anything missing in my proposition (comment #29) ? Mine has a few improvements on the usability: - selecting, out of the three settings, the one locked, not the one changed. Otherwise how to decide which of the other two is fixed ? - independent "keep ratio" for each setting, so one does not have to switch it so often. (when changing another setting, chances are that the right "keep ratio" state is the one previously used for this setting)
(In reply to edera from comment #38) > (In reply to skierpage from comment #37) > > [...] I want to add resolution (DPI) > > as a third way to control the displayed size of an inserted image > But is anything missing in my proposition (comment #29) ? Well, it's for a different dialog. I've never exported to PNG/JPG, I'm just adjusting the displayed size of an inserted image with no intent to change how many pixels are in it. In the Image properties > Crop dialog I don't think there's a need for locking or separate keep ratios; you just pick the sizing method that's most natural and the other two update. But I could well be missing some nuance. Talk is cheap, coding is hard ;-)
Created attachment 168197 [details] symetrical design mockup, with % (In reply to skierpage from comment #39) > Well, it's for a different dialog. I fully agree with heiko that it would be better to have a unified interface. > I'm just adjusting the displayed size of an inserted image > with no intent to change how many pixels are in it. But someone else might very well want to change the number of pixels (see comment #1) There's something interesting in your mockup: the scale, in % (to set or report the quantity relative to the original value) There should be one for each entry in my mockup (changing relative scale changes the corresponding absolute value and vice-versa). New mockup with these percentages attached.
(In reply to edera from comment #40) > Created attachment 168197 [details] > symetrical design mockup, with % > > (In reply to skierpage from comment #39) > > Well, it's for a different dialog. > > I fully agree with heiko that it would be better to have a unified interface. > > > I'm just adjusting the displayed size of an inserted image > > with no intent to change how many pixels are in it. > > But someone else might very well want to change the number of pixels > (see comment #1) > > > There's something interesting in your mockup: the scale, in % > (to set or report the quantity relative to the original value) > There should be one for each entry in my mockup > (changing relative scale changes the corresponding absolute value > and vice-versa). > New mockup with these percentages attached. If you don't want to do anything with the pixels, then you are only editing the Exif header of the image. You can do that with a free tool like Exifpilot. Luckily Writer now understands all Exif headers, in the past it did not. I always use a photo editor to prepare an image before I insert it in Writer. For me, Writer should not do anything to the image. It is not a photo editor. But this is my opinion.
Code pointer was missing, so here is the dialog: svtools/uiconfig/ui/graphicexport.ui
Would appreciate the percentage idea in another enhancement request.
Aditya Pratap Singh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b524e0f2636d7983dd5aba32b2fd3e61e08aac56 tdf#115464 Added "prevent input" in export dialog It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
With LibreOfficeDev-7.2.0.0.alpha0_2021-04-17-x86_64, Export > png when changing the resolution, the physical size changes as well, while the number of pixels is kept fixed. As explained above, it would be equally valid to keep the physical size fixed and have the number of pixels changed (more px/cm means more pixels). This use case should be handled as well, and moreover should be the default, because impress works in physical sizes most of the times. See my comments above (e.g. comment #21) for a unified interface proposition.
(In reply to edera from comment #45) > With LibreOfficeDev-7.2.0.0.alpha0_2021-04-17-x86_64, > Export > png > when changing the resolution, the physical size changes as well, > while the number of pixels is kept fixed. > As explained above, it would be equally valid to keep the physical size > fixed and have the number of pixels changed (more px/cm means more pixels). > This use case should be handled as well, and moreover should be the default, > because impress works in physical sizes most of the times. > See my comments above (e.g. comment #21) for a unified interface proposition. Please file another ticket. This patch makes it clear that we have three dependent variables and there is also no mistake possible what remains constant. Changing this default is another topic (and I agree with the option).
Verified as fixed in: Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Added to release notes: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/7.2&diff=383178&oldid=382410
Sorry for opening an apparently old and closed topic ... but please someone explain to me WHY this was "fixed" ... i dont want to export pics created with Draw with 96 DPI, that is too low for my taste and it looks shabby when printed, but there are scenarios where I want the designed size of the object match the exported size exactly. NOW, because I have updated from 7.1 to 7.6 I only noticed now that this was changed. I cannot for instance now choose to export the desired size at my designated DPI (higher than 96 DPI) directly. DO I REALLY HAVE TO REVERT BACK TO AN OLDER VERSION OR USE NOW INKSCAPE AS AN UNNECESSARY STEP, is my question? Or is there a logic fault in how I think DPI and size work?