It is unfortunate that JUCE fonts are specified in pixels rather than how every other piece of software, GUI, and programming API specify font sizes (in points).
Can we please get Font::setPointSize() which will have the effect of producing glyphs which are exactly the same size as what you would get if you used a native operating system API to create a font?
Thanks!
Yes, yes, yes, and I am sure many others need this. At this time, I have to scale the Juce font sizes to match the 20 years of code that used point sizes. Every other platform uses point sizes.
+1 for this
Anyone else?
I’m not arguing against this, but out of interest, why do you say you need it?
Over the years I’ve written a helluva lot of code that draws text in all manner of situations, and have never once cared about the point size. I’ve always either had a space into which the text must fit, in which case I care about its maximum overall height; or I’ve tweaked the size by eye to make it look nice, in which case I’m just adjusting a number and don’t care what its units are…
I have Photoshop templates which lay out a user interface, I’d like to use the point sizes specified in the document directly in my code. Otherwise, it is a torturous trial and error process of mapping the point sizes in Photoshop to JUCE’s bespoke specification.
But regardless, specifying type by its point size is the industry standard method (operating system APIs all work in points, as does FreeType). When dealing with pre-existing code that thinks about fonts in point sizes (or in my example an external application like Photoshop), it is a constant annoyance to not be able to specify the size in points.
I’ve looked at the native code for dealing with fonts, I believe it should be a somewhat straightforward task to calculate a simple coefficient for multiplying the desired point size and turning it into the value that JUCE expects for font size in pixels. The calculated coefficient would be specific to the font (likely some formula involving the font height or other available metrics).
I’ll give you a reason we NEED it. Because it is the correct way to represent font sizes. Let me give you a real world example. Let’s say I have 10,000 users that have used a 12 point font (on both MAC and PC) for small text and a 14 point font for larger font text, for many years. If I create my next upgrade with Juce, every single one of them has to play with the font sizes until they find the one that matches what they are used to, or I have to fudge each size, every time I set a font size. I am currently doing this at this time. To my customers, this would appear to be very unprofessional for my commercial products. Yes this is not a big problem in plugins, but hopefully Juce will be used for more that plugins. Also, maybe this could fix the music Font sizes which are miniature in Juce. There are plenty of text fonts that go with the music fonts that have the same problem. I can send you them if you wish.
Please read this for an explanation of your music font problems.
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/font/pdfs/5045.Sonata.pdf
section 4, for the reason.
Oh wow, this is very interesting:
So basically what they are saying is that when you specify a point-size of the Sonata font, it translates directly into a prescribed size based on the vertical staff distance? If this is true, then getting such fonts to display correctly in JUCE would be quite difficult (if not impossible, without writing native code to extract font metrics and “undo” whatever JUCE is doing to base its calculations on pixels).
Well it sounds to me like this simple addition is long overdue. The good news is that no existing code has to break, we just need a new Font function that lets you specify the size in points as an alternative to whatever home-brew JUCE is using currently. Thinking about it further, it makes sense now because in my FreeType hinting implementation I had to conjure up some magic numbers to scale the JUCE font size in order to get things to match the system.
I keep reading quotes like [quote]display correctly in JUCE would be quite difficult[/quote] If it were easy everybody would be doing it. This is what makes us professionals. We solve the hard problems. I never planned on rewriting parts of JUCE but I guess there is no other choice. I have a product that should be in the hands on a million uses with two to three years, so I need it to look professional. I have committed to JUCE for the time being, and I hope someone, with better JUCE knowledge than I, will step up to the plate and solve these font programs. And while they’re at it, somehow turn off the anti-aliasing. Light 12 ‘pixel’ fonts look terrible against dark and gradient backgrounds.
BTW, I think JUCE is an incredible piece of work. It just needs a few quirks fixed.
FYI, I’ve added a Font::withPointSize method now. Hope it does the trick.
This looks very exciting, and you are going into the typeface metrics (which is platform specific) to calculate the point size to JUCE size coefficient. Quite impressive!
Can you possible add a checkbox or drop down to the JUCE demo so that we can specify the font size in points?
Huh? In the demo app? Where…?
The “Fonts and Text” panel, has a Size slider which uses the pixels specification. It would be nice to have a checkbox or dropdown to allow the specification to take place in points. Then it would be possible to compare the output of JUCE fonts against other applications or the system more easily. And if anyone reports a problem with a font there’s an easy go-to standard way to analyze it (by running JUCE demo).
Also, there should be a Font::setPointSize as well as the function that you added, this way we don’t have to assign the font object:
ugly:
font = font.withPointHeight ((float) sizeSlider.getValue());better:
font.setPointSize ((float) sizeSlider.getValue());Tried the new routine, unfortunately it doesn’t match the Windows output:
[attachment=0]FontPoints.png[/attachment]
In fact, comparing the output of setFontHeight() versus withPointHeight() there seems to be no change whatsoever (I compared them).
Maybe my maths wasn’t quite right… I had to implement this about 5 times for all the different platforms and only tested each one briefly, so unsurprised if there were some initial gremlins. Busy with other stuff today but will return to it when I get chance…
Let me look into it a little more deeply so I can help narrow it
Jules,
I appreciate you making the change, and as a developer, I understand how one little change leads to several others, like the request to put the set point size in the demo app, etc. But again, I appreciate the change and this will help many, once it works correctly. I will work on the TextEditor to add Justification. I already added the ability to select characters/words and change their font, and the ability to retrieve the text with font info and replace the text with new info. I don’t believe much more is needed for basic Text editing. Once finished I’ll send it to you and let you handle implementing it, if you wish.
Thanks Vinnie!