AlertWindows and Tooltips display wrong characters


#1

Hey Jules, latest tip has messed up characters in AlertWindows and Tool Tips. Happens in my own app, Introjucer and Juce Demo. I’m on Snow Leopard. I’ve attached a screenshot of an AlertWindow from my own app and tool tip from the demo.
[attachment=1]AlertChars.jpg[/attachment]
[attachment=0]ToolTip.jpg[/attachment]


#2

No such problems for me… Are you definitely on the latest version?


#3

Hmm, that’s strange. Yeah, I cloned the repo last night. I tried re-cloning again this morning and built the introjucer, fired it up and it’s still doing it. Here’s a screenshot of some help text in Introjucer.

[attachment=0]IntrojucerHelpText.jpg[/attachment]

This is the command I use for cloning: git clone --depth 1 git://juce.git.sourceforge.net/gitroot/juce/juce

To double check I just tried rebuilding introjucer with my previous version of juce (v2.0.21 - from a few weeks ago I think) and the text comes up fine. I’m using Xcode 3.2.


#4

Hmm, you say you’re on Snow Leopard though. Must be a difference between the APIs… Unfortunately I don’t have a machine to test that on any more. (is Snow Leopard 10.5 or 10.6? Wish people would just use the numbers rather than names, I can never remember which one is which…)


#5

Oh sorry about that, I’ll use numbers from now on. Snow Leopard is 10.6.


#6

You probably know this already Jules but OSX can boot from an external drive. I keep a cheap 160GB drive with lots of partitions with factory installs of 10.5, 10.6 & 10.7 on for testing purposes to make sure that the developer tools don’t install any extra dynamic libs etc. which my software may be relying on. I also have a dev version of 10.6 which I keep around.

You can also do this with partitions of your internal HD, just hold option when you boot.


#7

After some investigation I have found the following:

Problem appears to be in CoreTextTypeLayout::createCTFont. If I get rid of cfFontStyle in the dictionary the characters show up “properly”. The reason I quote that is because I’ve also noticed some strange behaviour. If I replace the initialization of cfFontFamily and cfFontStyle with hardcoded strings, using the cfFontStyle then works.

This works:

CFStringRef cfFontFamily = CFSTR("Lucida Grande"); CFStringRef cfFontStyle = CFSTR("Regular");

Also, using a hard coded cfFontStyle with the font.getTypefaceName().toCFString() works.

CFStringRef cfFontFamily = font.getTypefaceName().toCFString(); // CFStringRef cfFontStyle = findBestAvailableStyle (font.getTypefaceName(), // font.getTypefaceStyle()).toCFString(); //CFStringRef cfFontFamily = CFSTR("Lucida Grande"); CFStringRef cfFontStyle = CFSTR("Regular");

But interestingly, I get a different looking font if I switch between font.getTypefaceName().toCFString() (returns Lucida Grande) and hard coding “Lucida Grande”.
Using font.getTypefaceName().toCFString();
[attachment=0]toCFString.jpg[/attachment]
Using CFSTR(“Lucide Grande”)
[attachment=1]CFSTR.jpg[/attachment]


#8

Hardcoded font family works with findBestAvailableStyle as well. So changing both or just either value to use CFSTR will keep the wrong characters from showing up. Is anyone else getting this behaviour on 10.6 with Xcode 3.2?


#9

Hey Graeme,
Things look near correct on 10.7 with Xcode 4.2.1. However, I am seeing the same thing you are when I use 10.6 with Xcode 4.0.1.
The screenshots (Alert Window, Tooltip) are a dead give away that it is some sort TextLayout issue.

I have investigated the problem, found and fixed the bug that is causing this. However, during the investigation I stumbled on to two other mac text bugs which I am in the process of fixing.
Once I fix all three, I’ll send in my changes to Jules. So hopefully everything should be back to looking normal soon.


#10

Awesome, thanks!


#11

Hi Graeme,
Just wanted to let you know I found and fixed the two bugs. I have sent in my changes to Jules.
The third thing wasn’t actually a bug, I was wondering why Juce was rendering all the TextLayouts glyph by glyph rather than using the Core Text/Core Graphics fast path but this was actually by design. The fast path is accessible when using the draw method on AttributedString.


#12

Great! Thanks for the update Sonic. I’ll look forward to seeing the changes you made.


#13

Jules commited the changes so things should be fixed now on 10.6.


#14

Fix is confirmed with the latest tip. Thanks!