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.
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.
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).
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…
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.