Hi Jules,
While using the text editor i found that size of glyph is different from standard applications.
Please find the image attached which compares Arial font of 150 size with Microsoft word.
regards
Bala
I wouldn’t trust what you see on the screen in Word to reflect any kind of reality! Their point size refers to the printed result, not what it shows you on the screen, so who knows what zooming and scaling they’re applying to it…
I checked it with couple more applications (Adobe Photoshop, Bit fonter, Microsoft Word, Mac Font book). All seems to perfectly match up except JUCE. Is there any specific scale percentage to match with other apps?
Maybe you’ve specified an overall font scale factor in windows? That would affect (some) other apps but juce ignores the font scaling (because it’d mean that your font sizes would change on different windows installations, while your other non-scaled images wouldn’t, and your UI would end up looking wonky on some machines)
But it begs the question of why anyone would possibly care about whether a font matches the size of fonts in Word??
We have designed pattern images for fonts from Bitfonter. When i tried to apply the pattern images to JUCE font the result is not as expected.
I don’t know if this is the reason for the problem, though it might be.
Windows defaults to 96DPI (PPI actually) for font rendering, even though most monitors are designed for 72. This value determines the relationship between point size and physical size.
You can check this by going to display->settings->advanced. Where it says 96DPI, you can choose to configure it yourself with an onscreen ruler.
If you play around with it, you will probably find that the 75% / 72 DPI is the one where the on-screen inch matches a physical inch.
Macs use 72 DPI, and on Linux it depends on the distro.
I think this bug has been known for a long time, mdsp mentioned it the 3rd July in this Thread: http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=2678&start=15
But on the other side, I’m not so sure if it would make sense to now change this behaviour as many JUCE apps already base themselves on the wrong font size. One possibility would be to add a #define USE_CORRECT_FONTSIZE_RENDERING_ON_WINDOWS or something like that.
I wouldn’t mind a hard fix for linux as well. My app displays with a wide range of differing font sizes across the various linux distros in my department. On one, the font size is absolutely tiny, and looks weird[1].
I agree with zamrate that a define would be needed so as not to break all existing code, but I’d suggest a more generic IGNORE_NATIVE_FONTSIZE_SCALING flag that allows JUCE to use its own intelligence when scaling fonts.
[1] I use a lot of scale font to fit too, so that’s really wierd. I’ll upload screen grabs of two different linux boxes side by side if it helps show what I mean.
Sounds like there’s a need for a better overall solution for this. Not sure what it is though…
I didn’t realise that linux was scaling the fonts - the way I want it all to work at the moment is for it to ignore the scaling. Will need to fix that…
Maybe just adding a method to find out the user’s current scale factor would be useful, and then you could choose to apply that to your font sizes if you want.
Any traction on this? Did some digging but don’t see evidence of a solution being implemented.
Don’t think I’ve looked at it, sorry!
If I can safely assume 72dpi on Mac then I’ll likely scale Win fonts based on the current dpi setting so screen rendering matches that of a 72dpi display. I’m just unsure whether or not I can safely assume 72dpi on Mac. Nor have I found a means of actually getting the current setting on OSX. Anyone have thoughts on either?