hallo Armin
new comments inline on your remarks
On 3/02/2016 14:10, Armin Le Grand wrote:
Hi,
comments inline
Am 03.02.2016 um 12:35 schrieb SOS:
On 3/02/2016 11:32, Chris Sherlock wrote:
On 3 Feb 2016, at 7:24 PM, SOS <sos@pmg.be> wrote:
On 3/02/2016 3:55, Kohei Yoshida wrote:
On Wed, 2016-02-03 at 10:52 +1100, Chris Sherlock wrote:
The other question is: why would we not want to the actual DPI and
screen resolution?
My understanding is that, historically, the OS provided a function to
query DPI but what gets returned from such function was not always
accurate (or always not accurate depending on who you ask). So, the
workaround at the time was to assume that DPI is always 96 (and
hard-code that value) regardless of what the OS told you, which
worked
just fine because the monitors used back in the day had the same
screen
resolution.
Mostly DPI is found in the header of a pixelfile (taken by camera).
Unfortunately it's not the photographer who gets to decide about
the needed DPI.
DPI is actually a wrong definition for documents, Dots Per Inch is
a definition used by output devices. Screens need a PIXEL par DOT
but for print devices there is no precise correlation between the
number of dots used by the device and the pixels needed in the
image for having a maximum image-view quality.
The print industry has come to some standards by trial and error.
- monitor screens need 96 - (220-retina) pixels per inch
- laser printers need 150 pixels per inch (up tot 2000 + dots)
- offset printers need 254 -300 pixels per inch (up to 3000 dots)
Definitely true :-) Only in OS X’s case, it doesn’t actually report
back the correct resolution unless you ask for the backing
coordinate system.
The PPI business is a red herring I think I’ve introduced into this
discussion I’m afraid. We calculate the PPI ourselves (and call it
DPI) based on the reported pixels, and the size of the screen in mm
(which we obviously convert to inches).
its a bit the wrong discussion: what we see on screen has no
relevance: the user can "zoom" the document until he is happy with
the image quality on screen
But in the current situation, LO users has no idea how big (size) he
can place a image in a document.
When the doc is intented for online use (email and Web) then there is
a minimum of 96 pixels par inch needed. More is no problem but is in
many cases a overkill.
Who is editing a "book" or a "magazine" need minimal 254 pixels par
inch to has a good image quality after printing.
When using less pixels the book pages are looking fine on screen put
shall have a creepy print quality
So having a new "DocumentProperty" indicating the needed pixels (for
printing) make it possible to make the "size" calculations before
inserting.
It is relevant. If you have a vector graphic and it gets converted to
bitmap, the DPI from the system is used to define the resulting pixel
size. Conversion to bitmap happens more often than it might seem.
Examples:
- user chooses to do so (context menu, convert to bitmap)
- some exporters who are not capable using vector graphics
- PDF, e.g. PDF/1A which is not allowed to use transprencies and
solves by creating bitmaps where graphics and transparent parts overlap
- 3D renderer which targets to bitmaps (chart, 3D objects)
Thus, the system DPI is essential. If on Mac, the bigger DPI will be
used, it will enlarge all these conversions.
Thats the problem withn this "system DPI"
for screen viewing is 96 DPI OK but far to less when the document needs
to be printed
we need a replacement for the system DPI who is a value who must can
differ par document
HTH!
I guess I’m curious as to what is relying on the screen resolution
and PPI.
Although… it’s funny that we have the function
SalGraphics::GetResolution, but that returns the PPI!
Chris
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Context
Re: DPI and screen resolution on OS X · Alexander Thurgood
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.