Message Boards Message Boards


Fix incorrect DPI setting for rendering fonts in Mathematica ?

Posted 5 years ago
10 Replies
18 Total Likes

We all know that since time untold the Mma frontend uses an incorrect DPI setting for rendering fonts. As a consequence, while there must be literally hundreds of thousands of Windows (or Mac) applications that will render, say, a 12-point font as a 12-point font, the Mma frontend renders the font as a 9-point font.

What is worse, there is no good way to fix the issue as a user. Sure, I can set the magnification globally to 1.33, with the result that any graphics in the Mma documentation will look bad, and need to be regenerated to render properly. Or, I could set the ScreenResolution parameter in Formatting Options->Font Options->FontProperties to "Automatic" (which indeed would be the right thing to do), but, oh joy, now I will have text labels cut off in various palettes. Oh, and let's not even get started about the fact that, since various frontend dialogs (such as, e.g., MathematicaClosingDialog.nb) are using fixed-size windows, your menu bar may be wrapped into a second line if you dare to customize your Windows menu fonts. Well, at least that's not an issue in Windows 10, since Microsoft doesn't allow you to customize those fonts anymore, but I digress...

In brief, the Mathematica frontend is a disgrace, which is all the more disappointing given the potential it could have, and given the fact that this would be so easy to fix for Wolfram. All they would have to do is set FontProperties to "Automatic" by default, and then adjust all of the built-in palettes and Help notebooks to format and render properly at the resulting size. Why in all the world Wolfram refuses to do this is beyond me.

10 Replies

Hi Dietmar welcome to the WR community.

I'm not sure what you are experiencing. If I set (for example) the style of the ticks to 18, and compare that to a text-document with 18 as well they look the same to me! Could you provide some examples (images)? Certainly, when you export something it should have the correct font size. I never had a problem with that, I actually rely on it being exact often.

enter image description here

It depends on the resolution of your monitor, see detailed analysis of this issue here:

I changed resolution on my screen, to some 'native' resolution, some different HiDPI settings and it does not depend on your resolution on a Mac (El Capitan).

On Windows it might be different though...

I am aware of the discussion linked to on stackexchange, and, no, this has nothing to do with monitor resolution. It is possible that this problem does not exist on a Mac, IF Macs internally use 72DPI as their display resolution. I will note that, via the FontProperties setting I had mentioned in my first post, the frontend indeed provides a mechanism (the "Automatic" setting) to properly set the DPI. However, the frontend does not use this, and instead uses a hard-coded 72DPI.

As for the first response to my post, I'm not sure what was unclear about my post, but the problem I am describing is well known (at least to all Windows users, and it has been present in ALL versions of Mathematica for many, many years). Below is an example using the default text font, which is supposed to be 14-point Arial. Mathematica is on the right MS Word on the left. The Mathematica font is roughly one third too small.

enter image description here

I'm quite sure Mac uses different DPI settings as well; I have a retina screen of 2880x1800, but I'm using a 'resolution' of 1680x1050, this is achieved by rendering at 3360x2100, and then downscaling that to my monitor native resolution. I guess this is Windows-specific bug, as opposed to what you say in your opening post.

Once again, Monitor resolution has nothing to do with this; the frontend on Windows machines will render fonts at the wrong size on any monitor, and at any display resolution setting. The DPI setting that is at issue here determines how fonts are translated into display units, and since no normal Windows machine uses an internal display resolution of 72DPI (note that, of course, the "DPI" here are virtual DPI), the font display is wrong on every Windows machine on the planet. Second, sure, it's a Windows bug, but it is one that has been around for many, many years, and people have been complaining about it for just as long. Wolfram has never bothered to address this. Why is that?

What I was trying to say it that you can run the same virtual resolutions on Mac with different DPI, you can have 1440*900 normal DPI and HiDPI. Basically doubling the DPI. I checked (with a special plugin for mac) for this, and it does 'detect' the DPI change in Mac and render text accordingly. (i think this was introduced in v9 or v10, before that it would not support hidpi).

For Windows, I'm not sure, but there is also a global one, it might not be detected properly, or it is just fixed to 72 for some reason. I can't really answer what their motive is to not address it, it might be technical, it might be disregard... Have you submitted this as a big report, and if so, what was the reply?

I have submitted this years ago, and so have many others I'm sure. The issue was acknowledged (obviously, there can be no debate on the fact that this is wrong), but no action taken. If anyone can find an explanation other than disregard, I would be interested.

The issue can be fixed simply by setting the global FontResolution parameter to "Automatic" as described above. It will require re-coding all built-in palettes and such so that buttons, frames and windows are properly sized, however. Alternatively, the notebooks encoding these elements could simply be set to a private FontResolution value of 72DPI, in which case no further changes would be required.

Right now the only solution is for the user to go into Option Inspector and manually change the setting for each and every new notebook.

P.S.: Just to make this completely clear: There is no discussion, about the established fact that fonts are displayed incorrectly by the Mathematica frontend on Windows machines. I repeat, to my knowledge, Mathematica on Windows is the only application, among what must be hundreds of thousands of Windows applications that display fonts on the screen, that cannot manage to render the fonts at their proper size. The question is, why do Windows users have to put up with this?

I also had the same issue and thanks to Dietmar's post I discovered the solution. But it is NOT to set Formatting Options->Font Options->FontProperties to "Automatic" (this seems to have no effect at all), but to set it to a specific value like 116. This solved all the problems (the Preferences dialog is perfectly readable now). As for the palettes --- yes, they are all broken, but who cares? I wouldn't use them, because:

a) The proper way to input source code is using only ASCII text symbols (and, on a totally different topic: never use space for multiplication, always use "*" --- if the creators of Mathematica understood this back in 1986 they wouldn't have made the wrong design decision of using square brackets for function arguments and would have stuck to the normal notation f(x,y) --- this reason for f[x,y] is confirmed in the excellent book by Stephen Wolfram "The Mathematica Book" (2003). )

b) Even when succumbing to the temptation to go beyond ASCII (e.g. to use Greek letters, logical and/or etc) one should simply learn the way to enter them from the keyboard via ESC...ESC way.

Btw, the above is not really a criticism of Mathematica. I personally sincerely believe Wolfram Mathematica to be the most useful and most important scientific software ever written! And I am so grateful to Wolfram for making it freely available on the Raspberry Pi! :)

UPDATE: I assumed Dietmar is only referring to the palettes for inputting formulas etc. But if he is referring also to GUI elements which may have been created by the notebook itself, then, yes, that is a serious bug, I agree.

Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
or Discard

Group Abstract Group Abstract