Snow Leopard, setlocale and font height bug

[Julian Smart]

Hi,

This is a very strange one. A user reported that in Writer's Cafe (built
with wxWidgets 2.8.10 on 10.5 and 10.6 systems using the 10.4 SDK), some
AUI tabs and tree items had giant heights when running on 10.6 with the
language set to German. Mac OS 10.5 and below don't show this problem.

This also happens with Polish and Spanish, but not Chinese or UK English
language settings. It seems that bold fonts (for example in the help
viewer contents where book titles are in bold) are returning around 300
pixels in height from GetTextExtent. However I'm unable to reproduce
this in a smaller example, as yet.

The cause appears to be related to the wxSetlocale call (setlocale) in
wxLocale::Init. If I comment this call out (in both Init functions), the
problem goes away.

I've tried to work around it in my app by resetting wxSetlocale
(probably I should find the original locale instead of using en_GB):

if (m_locale.Init(lang))
{
// On 10.6 and above, setting the locale for some languages
// causes problems with large values returned for character
height
// affecting e.g. AUI tabs and bold tree items
#if defined(__WXMAC__)
if (UMAGetSystemVersion() >= 0x1060)
{
wxArrayInt okLanguages;
okLanguages.Add((int) wxLANGUAGE_ENGLISH);
okLanguages.Add((int) wxLANGUAGE_ENGLISH_UK);
okLanguages.Add((int) wxLANGUAGE_ENGLISH_US);
okLanguages.Add((int) wxLANGUAGE_CHINESE);
okLanguages.Add((int) wxLANGUAGE_CHINESE_SIMPLIFIED);
if (okLanguages.Index((int) lang) == wxNOT_FOUND)
{
wxSetlocale(LC_ALL, wxT("en_GB"));
}
}
#endif
m_locale.AddCatalog(wxT("writerscafe"));
}

This seems to work around the bug while allowing translations to work,
but of course it's not great from the point of view of the wrong
underlying locale being set.

Any ideas about this one would be greatly appreciated. Meanwhile I'll
see if I can isolate the bug in a sample but so far I haven't been able
to trigger it using a tree control and German locale.

Thanks,

Julian

--
Julian Smart, Anthemion Software Ltd.
28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
www.anthemion.co.uk | +44 (0)131 229 5306
Tools for writers: www.writerscafe.co.uk
wxWidgets RAD: www.dialogblocks.com
Blog: www.juliansmart.com

[Julian Smart]

Some further info: when I add log code to GetTextExtent in
src/mac/carbon/graphics.cpp, sometimes the status value for
ATSUGetUnjustifiedBounds is not noErr (so we need to check for that and
return false, although unfortunately this function doesn't have a bool
return value). If ATSUGetUnjustifiedBounds fails, we can get large
ascent and/or descent values; and occasionally when the function
succeeds, ascent and descent are zero.

If I force the locale to en_GB, then ATSUGetUnjustifiedBounds doesn't
fail or report zero heights.

Regards,

Julian

[Julian Smart]

Hi,

I've discovered that it's related to the LC_NUMERIC locale category,
which allows me to simplify my workaround to the following:

if (m_locale.Init(lang))
{
#ifdef __WXMAC__

// On 10.6 and above, setting the locale for some languages
// causes problems with large values returned for character
height

// affecting e.g. AUI tabs and bold tree items (hard to
reproduce except
// in W.C.)
if (UMAGetSystemVersion() >= 0x1060)
wxSetlocale(LC_NUMERIC, wxEmptyString);
#endif

m_locale.AddCatalog(wxT("writerscafe"));
}

I don't yet know if the problem is specific to my application but it's
possible that non-C numeric formatting somehow interferes with how font
information is read, at the wxWidgets, application, or operating system
level.