To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=4499
------- Additional comments from [EMAIL PROTECTED] Sun Mar 16 09:51:22 +0000
2008 -------
@discoleo
"1.) DPI and LPI are printer measures"
I strongly disagree with this statement in the context of a bitmap export. You
have a print-oriented view, but this bug is not about printing it's about
exporting to a file so the target are other computer programs not just printers.
For a computer program "DPI" (as used both by proprietary programs such as Visio
and FLOSS programs such as the Gimp) is the ratio between the image dimension in
pixels (pixel being the basic bitmap unit) and the image dimension in inches
(physical unit, used to measure other parts of the document). If you don't
associate the correct DPI info to an image file conversion to a pixel oriented
space (vector export to bitmap) or to a physical unit oriented space (bitmap
insertion in Office document, printing a bitmap file) will give unexpected
results.
LPI does not exist in this context. It may be relevant for printers but not at
the computer bitmap export stage.
So when you resize a bitmap or export to a bitmap file, you need to expose three
sets of values
1. the image size in pixels
2. the image size in physical units (inches or millimeters depending on the
locale)
3. their ratio in DPI
Changing 1. changes 2., changing 2. changes 1., changing 3. changes 2.
The user can follow several strategies to select the DPI value:
1a. size the image "as on-screen", using the DPI ratio of his current screen
(Current OO.o strategy. Unsuitable for many usages but valid in some contexts
1b. size the image for a generic streen target, using common screen DPI values
such as 75, 96 or 100 dpi
2. size the image with a print target in mind, using common print DPI values
(150, 300, 600). (2400 in this context is totally insane, you don't map a pixel
to a print point, what printers do is take the bitmap file DPI value to compute
it's expected print size, and then interpolate pixels in print points to respect
this size)
3. just cram the maximum number of pixels into a specific physical size, avoid
any interpolation in the current program to preserve pixel info, rework the
bitmap in somewhere else. This will result in very strange one-of-a-kind DPI
values but is a valid use-case newertheless
Therefore a good bitmap export dialog (not a print dialog disguised into bitmap
export) would look like this
Export
( ) Selected (o) Visible area ( ) Whole page¹
¹ Usually one does not want to export huge bands of nothing around a drawing
Image size
(o) Custom
Width [ ]
Height [ ] [link¹] <Unit dropdown²>
¹ linking locks the ratio means changing width also changes height to
preserve their ratio
² with pixel as default, physical units as alternatives. Changing the unit
converts the Width/Height values to the new unit
( ) Scale to standard paper size
Size <A0,A4... dropdown>
Margins¹
Top [ ] Bottom [ ] Left [ ] Right [ ] ²
¹ When you target a paper format, you need margins
² In locale-dependant physical units, since standard formats use physical
units
Resolution
( ) Custom
X Resolution [ ]
Y Resolution [ ]¹ [link²] <unit³>
¹ Yes it is valid to have different values for X and Y in this context
² Linking forces the same value on the other dimension when one is modified
³ Unit being pixel/inches by default (what is commonly called dpi) with
pixel/mm… as alternatives. Changing the unit changes the value of X/Y (converts
them to the new unit)
( ) Use screen/web-oriented resolution
<dpi value dropdown¹>
¹ Default value: current screen settings
Alternates: usual screen DPI values (72dpi, 75dpi, 96dpi, 100dpi, 125dpi)
If "scale to standard size" was not selected before changing a value
there does not change the image size in pixels but the image size in physical
units.
( ) Use print-oriented resolution¹
Resolution <dpi value dropdown²>
¹ Auto-selected if "Scale to standard paper size" is selected before
² Default value: last selected one, 150dpi initially otherwise
Alternates: usual print DPI values (300, 600, etc)
If "scale to standard size" was not selected before changing a value
there does not change the image size in pixels but the image size in physical
units.
And then you have the usual transparency/interpolation algorithm options this
bug is not concerned with
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
