Re: [AD] Loading non-unicode TTF fonts

[Michał Cichoń <michcic@xxxxxxxxxx>]

>> This issue doesn't have obvious solution. Wild guess just hide the
>> problem.
>
> Or expose the problem and a possible work-around to the user.

Possible, but will the user will be interested in such details? I
think exposing some routine in internal API will be sufficient for
power user. Rest will probably don't care.


>> My advice would be to dump damaged font.
>
> Cute, but as you can probably guess, not helpful.
> Note that the fonts are not "damaged" - they work perfectly fine in Gimp (though admittedly they don't work on OS X's native font viewer thingy). I'll take a tool that lets me "fix" said broken fonts though if you can recommend one. Doesn't fix the real problem, of course, but then I only care because of these particular fonts.

I realize we doesn't live in an ideal world and dumping resources is
not always an option.
What is damaged there is the font and it should be fixed. If FreeType
didn't managed to map characters to Unicode, what can we do?
Generally I'm against adding code for fixing unique cases.

I just found TypeLight which should be able to add missing character map.
http://cr8.netfirms.com/typelight.html

On the other hand, there can be license issues. It may forbid you to
add or modify font file, then insane world of patching the code to fix
data starts.


>> But if it is not possible I would like to see a big warning message
>> while selecting applying your workaround.
>
> There should be no problem for characters <128 if the font uses a Latin-1 or similar encoding. Perhaps that's the most conservative workaround: only display those characters that have a reasonable chance of showing up, junk the rest. It's not like it's a regression over the current behaviour, which just quietly does nothing.

How about if al_load_font() just fail if no unicode mapping is available?
I think this will be better approach to do not load such font at all
rather than load and try to fix it by guessing.