What is a printer's point?

Question

Bug introduced in 10.4 or earlier and persisting through v11.3 (misleading documentation inconsistency)

---

According to the documentation it is a basic unit for size spec. WindowSize and ImageSize says:

I think the reasoning below proves that documentation is not correct in this fundamental matter:

1. Assuming PP is this the same what Wikipedia calls Point(in typography)?

2. Assuming: PP is this the same what dot from dpi - dots per inch is

3. The relation between pixel and PP is:

   (1.) ==> 1 pp = 1/72inch

   that and (2.) ==> relation 'pp:px' is 1:1 only for 72 dpi screens

4. I have 96 dpi screen (according to facts and to what MMA says Last /@ CurrentValue[$FrontEnd, {"ScreenInformation"}])

   with 2560 x 1440 resolution then

   CreateDocument[{}, WindowSize -> {2560, 200}] should not have full screen width? Right? It could have had if I had 72dpi screen.

---

Worth to mention that for fonts MMA by default assumes you have 72 dpi screen: Fontsize is too small. Is that the case for everything else too?

That would be a very logical explanation (disappointing though), my tests are confirming that:

Framed[Grid[{{
       "This Framed is 30pp tall:"
        Framed[{}, ImageMargins -> 0, ImageSize -> {Automatic, 30}],
       #
       }},
     Alignment -> {Left, Center}, Spacings -> {0, 0}
     ], FrameMargins -> 0] & /@ {
   Style["Öj - 30pp font and default assumed 72dpi", FontSize -> 30],
   Style["Öj - 30pp font and automatic dpi ", FontSize -> 30, 
    FontProperties -> {"ScreenResolution" -> Automatic}]
   } // Column

So the first line shows that ImageSize and FontSize are consistent. And since font is ignoring your dpi then ImageSize is consistent in ignoring ;-).

This is a mess. What can I do? Changing global Magnification is not an option because your user get used to default font sizes in Input/Output etc, yet I want to display well sized Labels and Grids in GUI. Moreover, WindowSize will not be affected by Magnification.

For fonts I can define styles with FontProperties -> {"ScreenResolution" -> Automatic} inside but how can I establish a proper interpretation of ImageSize and friends?

Do I have to CurrentValue["ScreenResolution"][[1]] / 72 prefix everywhere? :D

---

Related topics:

• Font sizes in graphics
• Magnification, ScreenResolution, ScreenInformation and Printing: Please shine some Light into it!

Answer 1

There are three kinds of units for measuring on-screen length, i.e. pixels, points and physical units (like inches/centimeters/etc.). For me the confusing part is pixels vs. the so-called "points". Before investigating OP's question, I didn't know that "point" is the size of an ink-point on printer.

I have a screen with the PPI (pixels per inch) as $96\;(\rm{px/in})$. And I have a Microsoft Word installed and I assume its ruler is correct. Inspired by P. Fonseca's comment in chat, I compared Word's ruler and Mathematica's ruler with magnification of 100% and 500% both under unit of "point" (i.e. $\frac{1}{72}$inches) and centimeter. The result is: Word's ruler does display correctly (can be confirmed by comparing with an actual ruler or A4 paper) and acting correctly under magnification. While Mathematica's ruler displays wrongly exactly as if it takes a $\rm{PPI}=72\;(\rm{px/in})$.

Suppose we have a horizon line segment $L$ on screen of length $W_{\rm{px}}$ (measured in pixels). So the same length of $L$ measured in inches should be $$W_{\rm{in}}=\frac{W_{\rm{px}}}{\rm{PPI}}$$. And in "point" it should be $$W_{\rm{pt}}=W_{\rm{in}}\times72\;(\rm{pt/in})=W_{\rm{px}}\frac{72\;(\rm{pt/in})}{\rm{PPI}}$$.

Now if Mathematica uses $\rm{PPI}=72\;(\rm{px/in})$, we will get $W_{\rm{pt}}=W_{\rm{px}}\times1\;(\rm{pt}/\rm{px})$ on ruler, i.e. a pixel-wise alignment, which is exactly what I observed. (Also because of which I always thought the ruler's unit "point" means it's measuring in pixels..)

So one (ugly) solution on Windows is to set a system-wise "custom scaling level" (the drawback is quite a lot of applications, including Mathematica, will appears "blurred" at a non-100% scaling level):

Now we can check that an image of $300\,\rm{pt}$ width does take $400\,\rm{px}$ on my $\rm{PPI}=96$ screen:

Answer 2

My two cents: The one issue that massively adds to the confusion is that Wolfram continues to set the font resolution to a fixed value of 72dpi on Windows machines, even though the system in principle knows the correct resolution: Setting the ScreenResolution parameter to Automatic fixes the font-scaling issue on Windows machines. The fact that this error is still not corrected even in Mma11 is a scandal, in my opinion. It's not as if the remedy is not well known, let alone hard to implement for Wolfram. Also see my answer here.

Answer 3

Disclaimer: I have long forgotten the details of this discussion and haven't really concerned myself with such problems for a while now. For the sake of housekeeping and at Kuba's request I convert my comment-answer into a proper answer.

• 1 point is 1 pixel in the notebooks.

My experience with creating figures for publications supports this.

My experience of exporting plots and other output to PDF also supports the idea that...

• Vector graphics are generated with 72 dpi in mind.

This can be tested by...

1. Making a 72pt wide image with a 12pt sized letter.
2. Export that, e.g. as PDF.
3. Include that in a TeX source, setting the width to 1 inch.
4. The size of the letter will match the size of the surrounding text (if it's 12pt, of course).

---

Kuba: Edit 28. IV 2016, Reply from WRI:

The developer replied today to the documentation question we are having.

He agrees the statements in the 2 reference pages can be clarified.

[...]

In terms of which one is right, he said, 'We don't yet support HiDPI under Windows. On Mac, we do the right thing, which is that '1' is effectively 72 dpi, and Retina displays are treated as effectively 144dpi.' Hopefully, this clears up your question about the documentation inconsistency to an extent.

Thank you again for your patience while our developers try to clarify the documentation.