[Libreoffice-bugs] [Bug 115464] UI of export to PNG and JPG misleading for resolution

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=115464

--- Comment #9 from edera at gmx.fr ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20180608/198ebf85/attachment.html>