Before we go too deep, how is the feature of different weights handled? i.e. Light, Medium, Heavy, etc… ?
What about Condensed and all that jazz?
Before we go too deep, how is the feature of different weights handled? i.e. Light, Medium, Heavy, etc… ?
What about Condensed and all that jazz?
You would use the font name and style name strings to get to the font with the desired weight you want.
You can see that in screenshots here:
Windows: http://www.juce.com/viewtopic.php?f=2&t=8593&sid=62b420f9f9ddfaa97bd22fb8366b929d#p48494
Mac: http://www.juce.com/viewtopic.php?f=2&t=8593&sid=62b420f9f9ddfaa97bd22fb8366b929d#p48614
I have re-written my code to extend the existing font API rather than use a completely new API, so it should no longer break everyone’s GUI code any more.
The changes have been passed on to Jules.
Just wanted to let those who don’t follow the git log closely that these changes have landed in Juce.
You should now be able to access all the fonts on your system and certain fonts on Windows should now display correctly.
The Juce Demo has been updated to demonstrate this new capability.
Thanks Jules for getting this in there!
Something that’s probably related to this: with the most recent version, on iOS the “default font” seems to have disappeared. In earlier versions, this used to work:
void paint(Graphics &g)
{
g.drawText("blablabla",...);
}
Now when you do that on iOS, there’s nothing to see. But, e.g., this works:
void paint(Graphics &g)
{
g.setFont(Font("Arial",20));
g.drawText("blablabla",...);
}
That’s a bit odd…
What happens if you do:
void paint(Graphics &g)
{
g.setFont (Font());
g.drawText("blablabla",...);
}
?
I did a Font(20) first, didn’t help. Also I see no text on TextButtons anymore if I don’t specify a font. Plus, when in landscape mode, the popup menu of a combo box is shown at the wrong place, but that probably has to do with the Display rewrite.
All seems ok in the simulator… How can I reproduce it?
Very strange indeed. Here is a screenshot of the Juce demo in landscape mode on the iPad simulator (xcode 4.3.2, OSX 10.7.3). See the popup menu displacement?

The fonts are there though. Then, there’s this simple test program:
/*
==============================================================================
This file was auto-generated!
It contains the basic outline for a simple desktop window.
==============================================================================
*/
#include "MainWindow.h"
class ContentComponent : public Component
{
public:
ContentComponent(){};
~ContentComponent(){};
void paint(Graphics &g)
{
int width = getWidth();
int height = getHeight();
g.setColour(Colours::blue);
g.fillAll();
g.setColour(Colours::white);
g.setFont(Font(100));
g.drawText("TestTestTest", 0, 0, width,height , Justification::centred, false);
}
};
//==============================================================================
MainAppWindow::MainAppWindow()
: DocumentWindow (JUCEApplication::getInstance()->getApplicationName(),
Colours::lightgrey,
DocumentWindow::allButtons)
{
ContentComponent *CO = new ContentComponent();
setContentOwned(CO, false);
setFullScreen(true);
setVisible (true);
}
MainAppWindow::~MainAppWindow()
{
}
void MainAppWindow::closeButtonPressed()
{
JUCEApplication::getInstance()->systemRequestedQuit();
}
On the simulator (and the iPhone), what I see is

As an OSX application, what I see is

which is the way it’s supposed to be.
Nope, can’t reproduce this.
Can you give me a change I could make in the juce demo app that triggers it? Or a complete project I could run?
There’s nothing that triggers it really… I just did a fresh clone of the latest bleeding edge into a brandnew juce directory again, compiled the demo for iOS, ran it on the iPad simulator, did a hardware -> turn right to go into landscape mode, opened the combo box and saw the list at the same off location again.
The test project is also just an introjucer-created GUI project, with the content component as shown in the code snippet above. Nothing else. I really have no idea what’s going on here.
In juce_Font.cpp, we have this bit here:
const String& Font::getDefaultSansSerifFontName()
{
static const String name ("<Sans-Serif>");
return name;
}
which is not interpreted correctly here. If I replace it with, e.g.,
const String& Font::getDefaultSansSerifFontName()
{
static const String name ("Verdana");
return name;
}
the text in my app is displayed as expected (also on TextButtons and so on). Does this give you any ideas?
You’re off the mark there - that string is only used as a placeholder, not a real name. The important bit is in juce_mac_Fonts.mm, line 1124, where it gets replaced with the real name. On my system that all works… perhaps you don’t have helvetica installed?
It’s installed… if I do g.setFont(Font(“Helvetica”,20)), everything’s good.
Seeing that the text on a TextButton is also not displayed, I put a breakpoint in LookAndFeel::drawButtonText, at this point here:
Shouldn’t the replacement with the “real” font typename have taken place here already? Because at that point, the typefaceName of font is still …
No, the Font object can use the placeholder name, the substitution only happens when something actually needs a Typeface object. If you want to step through and see what’s going on, the place to look would be like I said: juce_mac_Fonts.mm, line 1124.
That line there indeed replaces the TypefaceName to Helvetica. But then, in line 1131:
#if JUCE_IOS && ! JUCE_CORETEXT_AVAILABLE
// Fonts style names on Cocoa Touch are unusual like "Arial-BoldMT"
// No font will be found for the style of "Regular" so we must modify the style
if (newFont.getTypefaceStyle() == "Regular")
newFont.setTypefaceStyle (faceName);
#endif
After that bit, the TypefaceStyle is set to . Is that the way it’s supposed to be? I thought the style would be something like Italic, Bold,…
EDIT: when I attach an OpenGLContext, I don’t see any fonts at all, not even when specified via Font(“Helvetica”…). What the *** is wrong here? This is really the most frustrating experience in my five years of JUCE usage (which you should take as a compliment!).
Ok, it’s the deployment target… I had set it to iOS 3.0, but it has to be 3.2 or higher for the fonts to be displayed. iOS 3.0 still worked with JUCE 1.54 but now, not anymore. Fair enough, I can live with that.
Ah, right. Yes, I’ve only been testing on systems with CoreText available.
TBH I think that I should probably make 3.2 a minimum requirement now. I don’t think there can be many devices at all out there still using iOS3.0.