Recent

Author Topic: Pixels versus Points  (Read 1434 times)

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2514
    • havefunsoft.com
Re: Pixels versus Points
« Reply #15 on: July 19, 2020, 05:51:46 pm »
Shouldn't:
Code: Pascal  [Select][+][-]
  1. Panel1.Width := Round(96 * 3.5);
result in a panel 3.5 inches wide on screen?  If I measure with a ruler, its about 2.68 inches.
For this you have to do the "calibration".
No matter what the actual physical size, the system would always report either DPI.
Also, I can change a resolution of the screen - DPI stays the same, even though from the real world point of view, the number of pixels stays the same.

The "calibration" should provide you the actual width and height of the monitor. (i.e. in inches).  (Another way is to use API to get the physical dimension... but sometimes they might not be reliable)
Using this value and the actual screen pixel size - you get your own real-world accurate Pixel Per inches value.
As a result you will able to calculate the number of pixels to match the real world pretty easy.

I've seen such approach used in real life.
The method was used to calibrate tablet (touchscreen) devices.
The software was written to adjust to UI components to the physical size (to be useable by human fingers).
« Last Edit: July 19, 2020, 05:53:53 pm by skalogryz »
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

Dan3468298

  • Full Member
  • ***
  • Posts: 125
Re: Pixels versus Points
« Reply #16 on: July 19, 2020, 07:08:49 pm »
By 'calibration', do you mean this is a pascal command?  I can find no reference to it if so.   Furthermore, say if I am not concerned with exact physical measurement on the screen/form, can I assume when I copy panel canvas to printer canvas everything will scale properly and printed output will measure width 3.5 inches?  I am trying to achieve the classic WYSIWYG from screen to printer.  Thx.
MacOS 10.15.5/Lazarus 2.0.10 Build 2020-07-07

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2514
    • havefunsoft.com
Re: Pixels versus Points
« Reply #17 on: July 20, 2020, 04:56:29 am »
By 'calibration', do you mean this is a pascal command?
no. by 'calibration' i'm referring to acquiring the actual physical size of the display screen.
Again, there might an API (pascal command) for that. There might be not.
IIRC, on Windows there's no reliable way of getting the screen size. not sure about macOS


I am trying to achieve the classic WYSIWYG from screen to printer.
For WYSIWG you don't need to know the actual DPI of a monitor. Nor you need you the physical size of the monitor. None of that is needed. All you need is:
1) to maintain proportions
2) use the physical size bound measurements while design

Think of a text editor. It allows the text placement and formatting. All of the measurements are done in points with the assumption of classic 72 ppi.  (The other measurements is width of the destination paper, paragraph offets etc.)

On the screen these 72 ppi are translated and maintained to match the screen 96 dpi. Since the proportions are the same, you can always see the similar text layout, no matter what the end printer DPI is (300, 600 or else) and whatever the editor ZOOM factor is. (once can zoom, so the 10pt font can look like 96pt font size).

But, since! your business is labels ("Label It!" right?)
you might want to have the feature as "zoom to real life" in your screen.
In order to do that, you might need to prompt the user to measure their screen size and specify the actual length. After that you will be able to calculate the proper pixel size.
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2514
    • havefunsoft.com
Re: Pixels versus Points
« Reply #18 on: July 20, 2020, 05:00:47 am »
for macOS CGDisplayScreenSize function is available.
However, it only return accurate results, if EDID is provided by display.
Otherwise the results are inaccurate and the user would need to make a real-life measurements to get accurate results.

hmm.... Win MSDN version... hmm
« Last Edit: July 20, 2020, 05:03:04 am by skalogryz »
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

Dan3468298

  • Full Member
  • ***
  • Posts: 125
Re: Pixels versus Points
« Reply #19 on: July 20, 2020, 02:22:18 pm »
This brings me back to Points.  So fonts on computer are assumed at 72 PPI so a font of size 10 prints at actual 10 point on printer and is scaled to look nice on computer monitor to maintain proportion of font to page.  Thanks!
MacOS 10.15.5/Lazarus 2.0.10 Build 2020-07-07

lucamar

  • Hero Member
  • *****
  • Posts: 3019
Re: Pixels versus Points
« Reply #20 on: July 20, 2020, 03:18:32 pm »
You should read Wikipedia's articles on Dots per inch and Pixel density. It's all quite well explained there ;)
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.8/FPC 3.0.4 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

Dan3468298

  • Full Member
  • ***
  • Posts: 125
Re: Pixels versus Points
« Reply #21 on: July 20, 2020, 09:59:52 pm »
Thanks.
MacOS 10.15.5/Lazarus 2.0.10 Build 2020-07-07

kupferstecher

  • Sr. Member
  • ****
  • Posts: 406
Re: Pixels versus Points
« Reply #22 on: July 21, 2020, 12:02:55 am »
You can disable scaling though, if that is what you want.
The designtime dpi scaling should rather be a project setting like the runtime scaling and not an IDE setting.

 

TinyPortal © 2005-2018