Isn't it NAB/WFM from bug 115464?

(In reply to Heiko Tietze from comment #1)
> Isn't it NAB/WFM from bug 115464?

It's related for sure.. 45 comments quite a lot to read.. and goes in all sorts of directions..

The current implementation is awful. How do I export a shape at 300 DPI with 15x15 cm/inch to PNG?

1. open Draw
2. Insert a shape 
3. File -> Export (with shape selected)
3. Check Selection 
4. Now try to generate a shape of 15x15 with 300 DPI

Created attachment 174690 [details]
Screencast

More or less what I would prefer..

(In reply to Telesto from comment #3)
> More or less what I would prefer..

And exactly not what we do. LibreOffice is not a raster graphic manipulation tool.

(In reply to Heiko Tietze from comment #4)
> (In reply to Telesto from comment #3)
> > More or less what I would prefer..
> 
> And exactly not what we do. LibreOffice is not a raster graphic manipulation
> tool.

A) The change removed pre-existing functionality. Not saying this ever worked perfectly well.. this is going backwards, IMHO

B) Please don't use the general claim about not being a graphic manipulation tool. I would say this is not about manipulation its about saving (but maybe only about semantics). 
Following your line of argument, ask myself what are those filters (like relief), those color correction tools, crop, and compress doing in LibreOffice Suite. Those belong in the 'graphic manipulation area too (and in my perception even more compared to setting DPI and size for save). There is simply a balance to balance to it.

C)If you haven option to 'export to png of a selection - like a shape - you kind of need to be able to configure Size & DPI. Shapes are not raster images. They don't have internal DPI.. else it exports on screen DPI as fallback.

D) The internal handling is already present, it's only about UI behaviour.. As far I see. And still think the screencast shows how the UI could function. Also referring to the proposals at bug 115464...

---
I admit that the Export to Image functionality being pretty broken in general. Based on the amount of flaws, you start assuming people barely use it (as there not that many complains). Not sure if this the lack of interest in principle, of people avoiding to export? 

Not flyers and posters on websites are still published in PNG format.. And Draw kind of tool to create such stuff..

> 
> ---
> I admit that the Export to Image functionality being pretty broken in
> general. Based on the amount of flaws, you start assuming people barely use
> it (as there not that many complains). Not sure if this the lack of interest
> in principle, of people avoiding to export? 
> 
> Not flyers and posters on websites are still published in PNG format.. And
> Draw kind of tool to create such stuff..

-----

Oh, I've been complaining for years.  My bug for not being able to set a Draw document's dimensions in pixels was dismissed as not a bug years ago.

Demonstrably, from what I gather -- from off-hand comments I've seen planted on bug reports I've created -- is there is no great culture of graphics enthusiasts among the developers. Their biggest concern is the spreadsheet functionality. Everything else seems to be a side matter. There should be no reason why there are bug reports outstanding more than two years old.

Best thing to ever happen would be if the Document Foundation hired the creator of Paint.net, Rick Brewster, to undertake a a complete and comprehensive from-the-ground-up overhaul of the raster processing in LibreOffice, starting with the transparency treatment in MS Windows, and to finally build some honest-to-God layering rather than what passes for layers now in LO (can't move layers around, can't set transparency properties on layers, but I can still paste content onto a locked layer, that's unique, oh, and hidden layers export ANYWAY).

I like using open-source products, LibreOffice, GIMP, Digicam, Krita, and Inkscape among them. And I'm vocal when they need improvement. 

This is one of those times.

(In reply to xordevoreaux from comment #6)
> Demonstrably, from what I gather -- from off-hand comments I've seen planted
> on bug reports I've created -- is there is no great culture of graphics
> enthusiasts among the developers. Their biggest concern is the spreadsheet
> functionality. Everything else seems to be a side matter. There should be no
> reason why there are bug reports outstanding more than two years old.

There is a lack of developers in general.. And even more interest Draw :-(

However I do ask myself to what end does Draw exist. How it's supposed to be used. I see it as a tool to create posters, flow diagrams (visio) etc. Which you need to export to publish (also only on websites.. which makes images the logical choice..). If you can't properly export, it becomes pretty much useless (in my perception). You might convince me otherwise.. 

So sure LibreOffice Draw isn't GIMP, Paint.net. However I ask myself what the initial goals where (mission/vision) was while developing Draw (except showing off being able to create something like this). What was there intention? What type of program where the mimicking (at least I assume that was the case?). [Which can be used as reference of expected functionality] What was the targeted audience? Note: I see Draw as more or less a spin-off of Impress. 

I my perception export being quite essential (including resolution and size). And well layers & transparency pretty relevant to create posters too.

The 'IST' situation is clear, the 'SOLL' not so. Those are - without development resource - only aspirations/idealizations. But well you need some kind of vision to start with. 

And without such outlook (aspirations) it's really hard to discuses something in meaningful way. I still think "LibreOffice is not a raster graphic manipulation tool" being  rather evasive "half truth" and missing the point. And being used as a clincher.  Exporting a vector to a raster graphic is pretty normal thing to do, in my perception.

And regarding to export.. I'm pretty sure the backend is capable of handling the export in the desired way.. It is mostly the GUI (and maybe some hidden bug in the image export code)

(In reply to Telesto from comment #0)
> Description:
> UI: PNG export dialog has radio button doesn't allow 'dimensions' or 'DPI'
> to be set both

I have no problem getting the desired DPI _and_ dimension.
First click on resolution and set the DPI.
Second click on dimension and change width or height.

Example: If I set 300dpi and then width 10inch x height 6.88inch, LibreOffice generates an image with 3007 pixels x 2067 pixels. That is correct besides small rounding errors.

Created attachment 174745 [details]
Screenshot

(In reply to Regina Henschel from comment #8)
> Example: If I set 300dpi and then width 10inch x height 6.88inch,
> LibreOffice generates an image with 3007 pixels x 2067 pixels. That is
> correct besides small rounding errors.

A BIG *oops* / Mea culpa.. you're right on that point.. I might gone somewhat off-track.. [Offtopic: PNG doesn't write DPI at all; know fact] Back to comment 0...

A) Radio button does suggest it's or/or. I don't see what the value is of having with radio buttons. (I see it as wrong usage of radio button: not clear why it's chosen at all)

B) The dialog has number of assumptions.
* It's uses aspect ratio by design. This is non-optional (which makes it less flexible). And even worse this isn't communicated; only after it's to late (by touching it) 
* It uses match size to DPI by design. Under the assumption that's desired? The default is based on screen resolution (for shapes).. In my case 96 DPI. that's very low by definition.. So need to bump it up. And go back to Size and set it again (inconvenient; it's simply a workaround). You need to know in advance that DPI influences the size (again lack of communication of the UI). And remember the original size to be able to put it back. And not everybody is good in remembering (in general) or maybe especially numbers. And well I mostly work top down :-). Happens when reading a book, or filling a form.. 
 
I personally think both options should be given: depended and in depended.

C) If you type DPI [no, I don't scroll up from 96 (my default) to 300] the 'size' field isn't updated. If you press OK you will get 3,20 x 3,20 cm. This is a thing/limitation with those spin-boxes. As long as the cursor being inside it, nothing will update.. Not sure if something has changed in the last 9 months or so :-(. The feedback is awful


Lets add another dialog of IrfanView; the set size in percentage is also nice to have, BTW

All those things are pretty much GUI problems at a level of 'easyHack' LibreOffice pretty much capable of handling it. It's only the GUI not exposing this. Which makes even harder to accept the current being decent state. Especially there being plenty of other software capable to do so.

So I'm really not getting the objection/ refusal. Is it about a "floodgates principle"; https://en.wikipedia.org/wiki/Floodgates_principle. And me not seeing the floods for more requests? Or fear of opening some can of worms?  This appears really contained in scope, IMHO.. 

The only problem which goes outside easy hack is the spinbox not updating issue. started with welding.. and also affecting Table dialog (column width). And likely another few area's..

Telesto, I agree with you, that the current UI is not good, because it provides unexpected results. But the previous UI wasn't better.
Unfortunately it is too late for LO7.2 to change the UI.

But for LO 7.3 there is time enough to find a better solution.

Idea for example: Add a toggle button with connecting bracket between connected settings with the meaning "automatic adapt connected setting" vs "do not connect settings but keep value in the other setting". Such connection exists between "width" and "height" and it exists between "resolution" and "dimension".

I support setting the bugreport to "new".

(In reply to Telesto from comment #5)
> B) Please don't use the general claim about not being a graphic manipulation
> tool. ... There is simply a balance to balance to it.
Yes, it is. And dealing with the resolution is beyond but...

> C) ... Shapes are not raster images. They don't have internal DPI..
...is a strong argument.

(In reply to Telesto from comment #7)
> However I do ask myself to what end does Draw exist.
Here is the answer: https://design.blog.documentfoundation.org/2016/04/01/the-many-faced-god-part-2-how-libreoffice-draw-is-expected-to-evolve/

(In reply to Regina Henschel from comment #10)
> Idea for example: Add a toggle button with connecting bracket between
> connected settings with the meaning "automatic adapt connected setting" vs
> "do not connect settings but keep value in the other setting". Such
> connection exists between "width" and "height" and it exists between
> "resolution" and "dimension".

No objection, sounds like an easy to understand solution. But DPI and size are not independently. You might be able to change the DPI first but the other way around it doesn't work. So before we introduce the connect toggle we need to work on the backend. 

Tomaz, what do you think?

Another request which slightly messes with the principle of one bug/topic for each report. But UX likes to combine things regarding the same dialog/UI.

-- Based on bug 144279 
The DPI spinbox shows integral numbers. However if you switch from Dots per inch to Pixel per CM the spinbox shows a rounded value (37), while internally the resolution is still exactly 96 PPI

The dialog would be more self-explanatory if the spinbox did show some digits after the comma (Corel Paintshop has 3). This would explain the result by itself. And make it possible to input stuff behind the comma. If you touch the spinbox you lose the Dots per CM equivalent of say 96 DPI and you can't go back.. Yes, switching to DPI and go back to cm..  

------
- More detailed:
> You see that 96 pixels per inch doesn't mean some "round" number of pixels
> per cm: 96 PPI = 37.7952755905512... pixels per cm. When you switch from in
> to cm in the resolution, the control shows a rounded (down) value, but
> internally the resolution is still exactly 96 PPI - which is *correct*,
> because user might need just to check some different units without actually
> change the resolution. However, when user starts to *modify* the resolution
> using the new units, the new value is the integral number of pixels per unit
> - and when you select 37 again, it is true 37 pixels per cm, not the initial
> 37.7952755905512... which you started with. Hence the difference in the size
> - which is again OK.

> Here is the answer:
> https://design.blog.documentfoundation.org/2016/04/01/the-many-faced-god-
> part-2-how-libreoffice-draw-is-expected-to-evolve/
> 
I'd like to add my 2 cents regarding that document that's more than half a decade old, times change, and the bugs I lodge against LO Draw probably would never have been issues, or even ever crossed the minds, of end-users in 2016.  

In 2016, LO draw didn't have fuzzy shadows, glowing effects, or several other features that it has today. Did anywhere in that half-decade document call for such?

Can we put ancient documentation aside and the locked-in mentality that goes with it and look toward the future? Because I've a whole list of approved enhancements waiting in the wings for a programmer to pick up eventually, and I've love for one day for those to be incorporated DESPITE not being in that ancient document.

Thank you.

*** Bug 146552 has been marked as a duplicate of this bug. ***

I looked at bug 140473 today and it might be related to this whole topic.

The "lock" between related setting was also part of the proposal in bug 115464. It should be a familiar UI element and helpful to understand the workflow.

*** Bug 151649 has been marked as a duplicate of this bug. ***

*** Bug 152090 has been marked as a duplicate of this bug. ***

Still in favor of the solution posted at bug 151649 comment 0 by Mike Kaganski 

Created attachment 183155 [details]
Screenshot of PNG export options dialog

The issue is for image export options dialog. It is available using the following procedure:

1. In any document, choose File->Export, and choose PNG (or JPEG, or WebP).
2. Relevant "<Graphic format> Options" dialog opens, which has two control groups at the top inside "Size" section, connected with radio buttons: "Modify dimensions" and "Modify resolution".

The UI is confusing: the radio buttons create impression that you may change *either* one, *or* the other, but not both - but that is not the case: you may, for instance, first change dimensions, then activate the other radio button and change resolution, and the resulting image would use *both* changed values.

The radio buttons should be removed, and only labels should stay. Both groups of controls should be active at all times.

That's not true - I always get the wrong file size unless I set the dimensions to "Pixels"!

E.g. in "Draw", I create a page 30 x 20 cm landscape and place some high-res photos on it.

When I export this page as JPG, I can select "Modify dimensions" (default 30 x 20 cm) or "Modify resolution" (default 96 dpi).

When I select the first choice, I get an image file with the dimensions 1134 x 756 pixels. Seems to be correct for 96 dpi.

When I select the second option and set it to 300 dpi, I also get an image file with 1134 x 756 pixels, which is totally wrong of course!

The "width and height" of the image should always stay 30 x 20 cm, even if I change the dpi, so that I can get a high-resolution output file!

When exporting JPG (and other files that are aware of dimension AND dpi), it must be possible to specify BOTH, dimension AND dpi and not one OR the other!

A work-around is to set the dimension to 3543 x 2362 pixels - which corresponds to an image of 30 x 20 cm with 300 dpi. This produces a correct high-res file. However, Draw should handle that correctly (and professionally), of course, so that I can define my output file to be 30 x 20 cm with 300 dpi...

Anyone who has ever worked with image file formats that are size and dpi aware knows that it's not one or the other, but both that define a correct image. It's an absolute basic feature of these file formats and I can hardly believe that a program called "Draw" does not handle this correctly... especially when this bug has been reported more than a year ago already...

*** Bug 155889 has been marked as a duplicate of this bug. ***

Changing summary to hopefully better reflect the issue, as in my testing this is a one-way link between Dimensions and Resolution.

My preferred solution would be:
- no radio button that make the settings look exclusive to each other
- a "lock" tick box like in other dialogs
- values that instantly update so there is visual feedback

This issue generates reports that don't look like duplicates at first sight, e.g. 155889 

Reproduced in:

Version: 7.5.4.2 (X86_64) / LibreOffice Community
Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: fr-FR (en_AU.UTF-8); UI: en-US
Calc: threaded

*** Bug 150310 has been marked as a duplicate of this bug. ***

@Heiko
(In reply to Heiko Tietze from comment #16)
> The "lock" between related setting was also part of the proposal in bug
> 115464. It should be a familiar UI element and helpful to understand the
> workflow.

Small bump. The lock has been implemented for the Position and Size dialog....

*** Bug 144167 has been marked as a duplicate of this bug. ***

With 6 duplicates, setting priority to "high". This dialogue is evidently very confusing to users.