heliclei/cocos2d-x — pull request #149 by cocosQA (2014-04-25 20:53:37+00:00)
Title: Updated CCImage.cpp to resolve failure to load custom fonts from ttf file on windows

The bug is described here:
http://www.cocos2d-x.org/forums/6/topcis/32189

Basically the windows only singelton BitmapDC is used by all image objects
when drawing text. The call to BitmapDC.setfont is expected to load the
font from a ttf file and then use that font.

However the call to AddFontResource was incorrectly inside a block that is
only called when the previously loaded font is being removed. As a result
the ttf file is not added and the next call to 'CreateFontIndirect' would
fail to find the font.

The change I made was to move the code that actually handles clearing the
existing font to its own private method: BitmapDC::removeCustomFont. This
function is called by the BitmapDC destructor and by setFont before
loading a new font.

Now the actual font creation will always occur after the old font is
removed.

NOTE:
I'm very new to cocos2d-x and I'm currently working on a project with
v2.2.1 when I encountered this bug. I did some minimal testing of my fix
but I am not set up to do extensive regression tests on v3.

Additional Issues with the code I can see but did not address:
1) The windows API states that the WM_FONTCHANGE should be broadcast to all
windows and not sent to the current window as is done in the actual code.
I did not touch since the code currently seems working, and I am not sure
if this is an oversight or by design.

2) Failures to load a font from TTF file are not reported. So passing an
incorrect path to a ttf file will silently fail although
AddFontResource will create a valide error message.

3) Windows loads fonts in two stages. first AddFontResource accepts a path
to a font file and loads it. Then CreateFontIndirect will pass a font name
and load it from the first matching resource.

With the current code if the user uses a path to a ttf file for instance
`fonts/XXXX.ttf` The code assumes that XXXX is the name of the font inside
the file. But there is no gurantee that this is the case. In the samples
supplied there is a font called `Marker Felt.ttf` however the font in the
file is called `Felt` as a result it is impossible to load this file in
windows. The code will load the ttf file but proceed to try and load a
resource called `Marker Felt` when it should be loading `Felt`.
(Renaming the file to Felt.ttf solves this issue)

4) The current code will always keep only a single font resource. So using
a second font will cause the system to destroy the old font first. The
expectation of the API is that fonts will be loaded once and then reused.
However I'm not aware of any actual performance impact currently.