Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Display device DPI

 [1/8] from: atruter::hih::com::au at: 22-Oct-2002 9:31


I am using REBOL to generate AbiWord documents (it has a nice XML file format and supports embedded base64 PNG's). This works quite well, but embedding a PNG requires you to specify its display height and width in inches and here is where it gets interesting. I have run this on several CRTs and 120 pixels to the inch (DPI) yields a jitter free image. On LCDs the magic number appears to be 96 pixels to the inch. This got me to thinking about the issues this raises: 1) Are these DPIs (120 and 96) representative of all CRT/LCD display devices respectively? 2) Does the OS know this number (the display DPI) and how can I access it? 3) Have others hit this, or a similar, WYSIWYG / scaling issue? 4) Do other file formats (eg. PDF, Word, Open Office, etc) have similar issues (where the image dimensions are given in a unit of measure other than pixels, and a document is generated on one display device and viewed on another)? 5) Am I just approaching this from the wrong POV? Comments? Regards, Ashley

 [2/8] from: brett:codeconscious at: 22-Oct-2002 13:56


Hi Ashley, As far as I understand in general there are no real standards for a meaningful DPI measure of display screens. For me pixels are the only meaningful measure of an image on a screen. The simple act of adjusting the vertical height on a monitor shows that DPI for a screen is a risky concept. For paper though DPI makes a lot of sense. I was told in a web design course that a DPI screens was 96dpi (if I remember correctly) but it basically varied by OS and hardware and the 96dpi was basically to be treated as a rule of thumb. I don't know Abiword, I can imagine that a word processor would assume a printer is the main output device, hence the need to specify sizes in inches. How it renders a screen representation of the printable document on screen would be specific to the processor I guess. However it does it, it will likely be affected by your user's choice of display "Zoom" while viewing the document as well.
> 4) Do other file formats (eg. PDF, Word, Open Office, etc) have similar > issues (where the image dimensions are given in a unit of measure other > than pixels, and a document is generated on one display device and viewed > on another)?
I imagine so, if the printer is the main output device, then your screen is only treated as a representation (estimate) of your final output, not the final output itself.
> 5) Am I just approaching this from the wrong POV?
I'm not entirely clear what your goal is. If it is important that on screen image is very accurate then you probably need a different application from a word processor to render it properly. Alternatively maybe you can arrange it so that your documents with images are always viewed at 100% and ensure that your images do not need scaling in this situation (Ie prescale them). Regards, Brett.

 [3/8] from: atruter:hih:au at: 22-Oct-2002 16:41


Hi Brett,
> I'm not entirely clear what your goal is. If it is important that on
screen
> image is very accurate then you probably need a different application
from a
> word processor to render it properly.
My goal is to generate reports, which include images, that can be viewed, edited and printed via a simple WYSIWYG editor. PDF is good, but read only, and MS formats are obscure to say the least. HTML does not let you control page breaks, so I have been looking at XML file format editors. The "problem" is fairly simple to demonstrate. Use the following code to generate a 100x100 png: save/png %test.png to-image layout [origin 0 btn yellow 100x100 100x100 font [size: 18]] Open a word-processor of your choice and insert this image. Look at the properties of the image and note the dimensions (usually given in cm's or inches). Do the same thing on an alternate display device (eg. an LCD) and note how the same image has different dimensions. Changing the printer or screen resolution does not effect this, it seems to be a property of the display device itself (dot pitch?). The practical consequence of this is that the above image saved (using one type of display device) will appear pixelated on another. I found this out the hard way after comparing documentation (screen-shots) written on a 17" CRT (at 1024x768) and viewed on a 15" LCD (also at 1024x768).
> Alternatively maybe you can arrange it > so that your documents with images are always viewed at 100% and ensure
that
> your images do not need scaling in this situation (Ie prescale them).
Exactly what I am trying to do, using code like: ; create a 6"x6" image from a "larger" image DPI: 120 ; 96 for LCD, 100? for a notebook image-size: to-pair (DPI * 6 DPI * 6) save/png bin to-image layout [origin 0 image image-size %1.jpg effect [crop 500x0 800x800]] This works great so long as: a) you don't generate the report on a CRT then view it on an LCD (or vice versa) b) you can work out what the DPI should be This last step is easy enough. On my CRT here I load the 100x100 image from before and observe that its dimensions are 2.11cm. (2.54 / 2.11) * 100 120 DPI. Doing the same thing on an LCD yields 96DPI and a notebook yields 100DPI. Changing the screen res or printer does not seem to effect this. The real answer is to use vector graphics. In the meantime, these apps (AbiWord, MS*Word, etc) are using *something* to say "these here 100 pixels equate to x centimetres (or inches) on this here display device". I just want to access the same "magic number" these boys use! ;) Regards, Ashley

 [4/8] from: brett:codeconscious at: 22-Oct-2002 18:58


Hi Ashley,
> Open a word-processor of your choice and insert this image. Look at the > properties of the image and note the dimensions (usually given in cm's or
<<quoted lines omitted: 6>>
> documentation (screen-shots) written on a 17" CRT (at 1024x768) and viewed > on a 15" LCD (also at 1024x768).
I have access to a desktop with CRT and a laptop but I could not replicate the problem. Still how the Word processor arrives at a conversion of 100 pixels to 2.65cm (for me) is a good question. I'm guessing that a Windows API call is necessary to find the device units. What happens on Linux I don't know. For Windows, something around here may help you: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcons _88s3.asp?frame=true EEK! :^) Regards, Brett.

 [5/8] from: doncox:enterprise at: 22-Oct-2002 10:33


On 21-Oct-02, [atruter--hih--com--au] wrote:
> 1) Are these DPIs (120 and 96) representative of all CRT/LCD display > devices respectively?
Traditionally, CRTs had 72 dpi, but this seems to have crept up in recent years. 72 dpi gives you pixels matching points, which is good for DTP. In practice, now, two users with the same OS and the same CRT monitor will set the screen to different resolutions, and so have different dpi on screen. A printer will have much higher dpi than any display.
> 2) Does the OS know this number (the display DPI) and how can I access > it?
Only if it knows the size in inches of the user's monitor, which isn't likely if you think about it.
> 3) Have others hit this, or a similar, WYSIWYG / scaling issue?
It happens all the time in Photoshop.
> 4) Do other file formats (eg. PDF, Word, Open Office, etc) have similar > issues (where the image dimensions are given in a unit of measure > other than pixels, and a document is generated on one display device > and viewed on another)?
If you are preparing an image for a web page, you have absolutely no idea how big it will be on the client screen in inches/mm. If you are preparing an image for print, you have to decide the dpi you need for print quality, and the size on paper, and work back to the resolution needed in pixels to get that result. Some image files have dpi information in the header and others don't.
> 5) Am I just approaching this from the wrong POV?
Possibly. Regards -- Don Cox [doncox--enterprise--net]

 [6/8] from: g:santilli:tiscalinet:it at: 22-Oct-2002 12:07


Hi Ashley, On Tuesday, October 22, 2002, 1:31:04 AM, you wrote: ahca> 4) Do other file formats (eg. PDF, Word, Open Office, etc) have similar ahca> issues (where the image dimensions are given in a unit of measure other ahca> than pixels, and a document is generated on one display device and viewed ahca> on another)? Usually, yes. This is to make it appear always the same dimensions. If you used pixels, the image would look very small when printed, and very large on a low resolution display. So, you just tell it how big it is, and the software scales it to the right size on any device. Of course, how well it does the scaling depends on the software. In PDF you can decide if you want interpolation or not. ahca> 5) Am I just approaching this from the wrong POV? You usually should think in terms of what your document is, not what it looks on a particular device. I.e. a 10x8 inch photo should be 10x8 whether you are looking at it on paper, or on screen. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [7/8] from: greggirwin:mindspring at: 22-Oct-2002 11:13


Hi Ashley, The video driver is what determines the DPI for your screen. It doesn't matter what kind of monitor you have (though some LCDs provide their own driver so...) Here are some historical DPI values for common video settings: EGA 72 dpi VGA 96 dpi SVGA 96 dpi 8514 Large 120 dpi 8514 Small 96 dpi If you change to Large Fonts on Windows, you should see the DPI change as well (from 96 to 120). Brett got you in the ballpark with GetDeviceCaps. The elements you're interested in are LOGPIXELSX/Y. If you have View/Pro, try the following and let me know if it works. --Gregg win-user: load/library %user32.dll win-gdi: load/library %gdi32.dll get-dc: make routine! [ hWnd [integer!] ; handle to window; 0 for screen DC return: [integer!] ] win-user "GetDC" get-device-caps: make routine! [ hDC [integer!] ; handle to DC Index [integer!] ; index of capability return: [integer!] ] win-gdi "GetDeviceCaps" LOGPIXELSX: 88 LOGPIXELSY: 90 ; Have to use an intermediate variable here. REBOL doesn't like ; using the return result inline. print screen-dc: get-dc 0 print get-device-caps screen-dc LOGPIXELSX print get-device-caps screen-dc LOGPIXELSY

 [8/8] from: atruter:hih:au at: 23-Oct-2002 9:42


> If you have View/Pro, try the following and let me know if it works.
Thanks, that is *exactly* what I was after. The three CRTs I tried all showed 120x120, while the laptop I tried showed 96x96. I am wondering what kind of display won't have X = Y? ;) Regards, Ashley

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted