Comment 38 for bug 207198

I am attaching some debug output for this bug. The debug dump was made by the following command:

  FC_DEBUG=1029 firefox http://google.com > debug_output

when firefox finished loading the initial page at google.com, I then clicked on a shortcut to http://1g1g.com (a flash music player); once the flash page fully loaded, I closed the firefox session.

I did this test with the original 49-sansserif.conf on Karmic (attachment old_49-sansserif.txt.gz), and also a modified version by replacing the append_last family from sans-serif to WenQuanYi Zen Hei (attachment new_49-sansserif.txt.gz). The later case can display Hanzi glyph properly with Zen Hei, but the first one show empty squares (firefox turned out using Dejavu Sans to show all characters).

If you do a diff of the two outputs:
  diff new_49-sansserif.txt old_49-sansserif.txt > fontdiff.txt

search for "40894c41397" in fontdiff.txt, and read the following couple of diff blocks, you may see some major differences: because the original 49-sansserif.conf sets sans-serif as the fallback, this will keep propagate and prepends DejaVu fonts in front of this alias, and makes the results different (search for 41022c41617). I only don't understand where "Eras Bold ITC" comes from (search for "44861d43291" in fontdiff.txt).

From this, it appears to me that flash failed to render the Hanzi glyphs because it does not do fall-back operations: whatever first match fontconfig come up with, it simply use it to render all text. Setting "WenQuanYi Zen Hei" as the fall-back in 49-sansserif.conf accidentally stopped the propagation of sans-serif alias and freezes the best match to a font happening to have CJK glyphs.

Does this sound reasonable? any other findings?