Fallback to fonts with glyphs lacking in primary font

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a game with a definition for a Unicode glyph not present in the fonts 
used by garglk
2. Run the game
3. Glyph will display as '?'

What is the expected output? What do you see instead?

This is kind of what I expect, but the thing that would be nice would 
be--although this might slow down rendering inordinately--to attempt to use the 
primary font for normal output text, but then when the output stream hits a 
code point for a glyph it doesn't have in the primary font, it checks the 
alternate font (in my particular case, that would be Junicode, which contains 
the glyphs I use for Greek and Runic characters, and I think for most people 
writing in European languages it would be a good fit) to see if those glyphs 
are supplied there.

http://junicode.sourceforge.net/

It strikes me that if you extended the idea a little to allow a list of 
alternate font faces then you could bundle garglk with Junicode and something 
that has a bunch of Asian characters and get very broad coverage pretty cheaply.

I don't want to insist on Junicode as my primary font, because it doesn't look 
as nice as the bundled fonts in the general case (although it's really not bad).

I really don't know how feasible it is, but it looks kind of like if you 
modified the font_s struct to have an FT_Face altface member which you loaded 
with the alternate font, and then tried

gid=FT_Get_Char_Index(f->altface, cid);

at line 191 of draw.c before giving up and loading the '?' glyph if it's still 
not there, this could be done.  Or, alternatively, make altfaces a si
ngly-linked list of font pointers, and iterate through them, only printing '?' 
if the glyph is found in none of the listed faces.

Of course this would require a bit more memory at runtime, and it depends 
critically on the assumption that displaying a not-very-pretty omega is better 
than displaying a pretty "?".

And I don't know that it matters to anyone but me.

For what it's worth, though, OS X and Zoom *do* correctly render all the wacky 
characters I use as long as I make sure Junicode is on the system.  I don't 
know for sure if Windows terps do or don't.

What version of the product are you using? On what operating system?

Current garglk, Linux i386.

Please provide any additional information below.

Original issue reported on code.google.com by athorn...@gmail.com on 11 Jul 2010 at 4:13

[GoogleCodeExporter]

This should be an enhancement request, not a defect, but I don't see how to set 
that.

Also, Junicode is GPL-licensed.

Original comment by athorn...@gmail.com on 11 Jul 2010 at 4:22

[GoogleCodeExporter]

I have been dancing around the alternate fonts implementation; it's relatively 
easy to add, but more difficult to implement in an aesthetically pleasing way 
that avoids mixing glyphs from different fonts.

The new font configuration directives (propfont, monofont) make it more 
painless to specify a non-default font. Also the ability to apply bold / 
oblique to fonts makes it easier to substitute new ones, since you aren't 
constrained to fonts that come in the four requisite styles.

I also plan to add a better mechanism for font sizing. Right now the sizes have 
to be hand-tuned for satisfactory results, and the ideal size varies 
considerably between different fonts.

Issue 105 parallels this somewhat, in the related case of using line drawing 
symbols not found in the default fonts.

I probably won't tackle this until the Glk CSS standard emerges, since that may 
include a way to specify fonts more directly. I'd like to see it include a way 
to embed fonts within the game blorb, akin to the way PDFs handle font issues. 
This is fraught with potential legal issues and technical challenges for other 
interpreters, though, so I am not sanguine about its prospects.

Original comment by bcressey@gmail.com on 12 Jul 2010 at 6:34

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Passing this for now, though I do plan to revisit the font embedding question.

Original comment by bcressey@gmail.com on 17 Aug 2010 at 9:18

• Changed state: WontFix