Bug 184028

Created attachment 125658 [details]
A screenshot of what happens. Where the green bar is it should say "Load Game".

I have the same problem even with other flash sites. Enforced a re-install of
mstcorefonts without a positiv (better: any) result. I use Firefox 1.5, FC5
Test3 with all available updates. I did an upgrade from FC4 - there it wirked
very well and I was able to read text in flash animations.

Same here. I noticed that since test1 and up until test3 the problem is still
there. If I view any flash sites (http://www.motogp.com/en/motogp/index.htm) no
text will be displayed. Im up2date with the dev packages of fc5 and firefox and
nothing seems to fix the problem.

Yeah, seeing this issue with flickr organizr, flash-plugin-7.0.61-1 and
msttcorefonts installed

This:

  https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree/+bug/3204

suggests that upgrading to 7.0.61 fixed it in Debian/Ubuntu .. *shrug*

http://www.macromedia.com/cfusion/knowledgebase/index.cfm?event=view&id=KC.144b4be2&extid=144b4be2&dialogID=26586174&iterationID=1&sessionID=96301614d2dd3d474e74&stateID=0+0+26588263&mode=simple
Maybe that's it? Flashes made for Flash 8 won't work in Flash 7 without the
proper configuration... Mind you, not all the flashes all over the place could
possibly be like this. There is definetly a problem.
I updated to the new Flash and still nothing.
Firewing1

Still the same with me. I upgraded to 7.0.61 and still nothing. It seems that it
only worked for Debian/Ubuntu. 

I found a leaked torrent of FC5... So this is the final, and it's till happening. :(
Not looking good, this isn't exactly too great for FC's reputation, either...
Flash is a pretty essential part of Web these days.
Firewing1

Are you sure this is a FC specific issue?  It could be that this flash is
designed for Flash 8?

Not possibly every flash out there -- It's happening on every one. Motherload
worked in FC4, so I know it's a FC issue. Pretty sure it's font-related.
Firewing1

Actually, can someone confirm it's still working in FC4? I guess they always
could have edited & saved the same for Flash 8...
Firewing1

It's certainly happening on plenty of flash pages that worked in FC4.  E.g.,
homestarrunner.com, lots of sports game live update, etc.  And it went directly
from working to not working when I installed FC5test3 and hasn't worked since.

Hmmm... This is good info to know -- It's a universal problem it seems and not
b/c of hardware or a broken package... But, anyone still using FC4 that can
confirm the pages are still currently working in the FC4 release?
Firewing1

Created attachment 126397 [details]
Webpage with no text. Worked under Core4.

This is with all available updates and new flash plugin. Old flash plugin on
FC5test3 rendered the same way.

Could it be an Xorg 7 (font) problem?
Firewing1

Interesting theory Stewart.  We need to zero in on the actual cause of this
problem...

It might be useful to test a firefox-1.5.x RPM rebuild on FC4 to see if the
problem happens there too.

I dunno -- But I tried Firefox source, Firefox RPM from the Fedora repos and
from Dries (i think it was? Something from RPMForge...), plus in mozilla 1.7 and
it still occurs in all of them. When installing from the Flash tarball, it gives
me a warning about requiring 2 font packages. ttfonts and uwr-fonts, if I
remember correctly. The latter is installed but ttfonts if not to be found for
anything newer than FC2...
I'm guessing here, but I think it is this Xorg font problem as the firefox
package remained the same (I was using 1.5.0.1 in Core 4) from Core 4 > 5 and
the only big diff that could explain this text probem is Xorg...
Edit: This should help. My daily backup utility does a rpm package list, and I
found one from my old FC4 install. Here's any RPM that I had in FC4 containing
the work "font":
-----------------------
bitstream-vera-fonts-1.10-5
xorg-x11-font-utils-6.8.2-37.FC4.49.2
fonts-xorg-base-6.8.2-1
ghostscript-fonts-5.50-13
urw-fonts-2.3-1
bitmap-fonts-0.3-4
mathml-fonts-1.0-19.fc4
chkfontpath-1.10.0-4
fonts-xorg-100dpi-6.8.2-1
fonts-xorg-75dpi-6.8.2-1
mplayer-fonts-1.1-3.2.fc4.rf
fontconfig-2.2.3-13
-----------------------
Here's all packages containing "font" from my current FC5 install:
-----------------------
xorg-x11-fonts-75dpi-7.0-3
msttcorefonts-1.3-4
libXfont-1.0.0-2.2
urw-fonts-2.3-6.1
fontconfig-2.3.94-1
xorg-x11-fonts-base-7.0-3
xorg-x11-fonts-misc-7.0-3
xorg-x11-fonts-Type1-7.0-3
libfontenc-1.0.1-1.2
xorg-x11-font-utils-1.0.1-3
ghostscript-fonts-5.50-13.1
xorg-x11-fonts-truetype-7.0-3
xorg-x11-fonts-ISO8859-1-100dpi-7.0-3
mplayer-fonts-1.1-3.lvn5
bitmap-fonts-0.3-5.1
chkfontpath-1.10.1-1
xorg-x11-fonts-ISO8859-1-75dpi-7.0-3
libXfontcache-1.0.1-1.2
bitstream-vera-fonts-1.10-5.1
xorg-x11-fonts-100dpi-7.0-3
-----------------------
The basically same packages except Xorg is not v7 in FC4.
Would you like me to post the full RPM lists from both systems?
Firewing1

I used an RPM of firefox 1.5 on FC4 (built at freshrpms.net, in their testing
directory) and fonts worked perfectly fine on flash.  It was a non-pango,
non-cairo firefox, I believe.  (MOZ_DISABLE_PANGO doesn't seem to make a
difference, though.)

This could be a cairo issue or a pango issue.  Could be a fontconfig issue, as
fontconfig changed a LOT from FC4.

OK, I checked the non-cairo firefox 1.5 built on FC4 that displayed fonts fine
using flash on FC4.  Fonts still don't work, even on ones that worked with the
same firefox 1.5 build the day before I installed FC5test3.

This makes me think that it's a fontconfig issue, perhaps.  Although I'm a bit
confused since I do actually have the MS TT fonts installed, and find them with
fc-match and all.

It's XFS. Can we please have it disabled in FC6!
A kind member at fedoraforum.org showed me the solution:
Replace this line
    FontPath "unix/:7100"
in /etc/X11/xorg.conf with:

    FontPath "/usr/share/X11/fonts/misc:unscaled"
    FontPath "/usr/share/X11/fonts/75dpi:unscaled"
    FontPath "/usr/share/X11/fonts/100dpi:unscaled"
    FontPath "/usr/share/X11/fonts/Type1"
    FontPath "/usr/share/X11/fonts/TTF"
    FontPath "/usr/share/fonts/default/Type1"

Firewing1

Great! Now it works! Thanks to thebluesgnr at FedoraForums! :)

Yes now it works!!!  Many thanks!!

Can confirm this as well.

Interesting.  With the font server used in xorg.conf, things like xfontsel which
I am pretty sure use the old font system still work fine and show the fonts. 
But the flash plugin no longer finds them.  Hmm.  Specifying the directories
directly works fine.

The plugin seems to trying to load the fonts itself by looking through the
directories returned by XGetFontPath()

with only FontPath "unix/:7100" in xorg.conf, you see this in strace:

open("/usr/X11R6/lib/X11/fs-xtt/config", O_RDONLY) = -1 ENOENT (No such file or
directory)
write(39, "\x34\x02\x01\x00", 4) = 4
read(39, "\x01\x00\x97\x00\x03\x00\x00\x00\x01\x00\x3c\x09\x78\xe8"..., 32) = 32
readv(39, [{"\x0a\x75\x6e\x69\x78\x2f\x3a\x37\x31\x30\x30\x00", 12}, {"", 0}],
2) = 12
open("unix/:7100/fonts.dir", O_RDONLY) = -1 ENOENT (No such file or directory)

i.e. it's looking for fonts.dir in each of the paths returned by XGetFontPath()

if you bypass xfs in xorg.conf by adding the font paths directly, you see:

open("/usr/X11R6/lib/X11/fs-xtt/config", O_RDONLY) = -1 ENOENT (No such file or
directory)
write(39, "\x34\x02\x01\x00", 4) = 4
read(39, "\x06\x01\x8c\x00\x17\x8e\x97\x2b\x4c\x00\x00\x00\x01\x00"..., 32) = 32
read(39, "\x01\x00\x8d\x00\x2b\x00\x00\x00\x05\x00\x4e\x09\x50\x54"..., 32) = 32
readv(39, [{"\"/usr/share/X11/fonts/misc:unsca"..., 172}, {"", 0}], 2) = 172
open("/usr/share/fonts/default/Type1/fonts.dir", O_RDONLY) = 40



Now, this explains why adding the font paths to xorg.conf fixes the problem, but
it doesn't explain why it worked on FC4 which would have been configured to use
xfs too.

Oh, I'll note that the documentation for XGetFontPath() clearly says that "the
strings are implementation dependant and not intended to be interpreted by
client applications" *cough*

Note, "bad XGetFontPath() assumptions" probably *isn't* what broke text
rendering in FC5 ... because it was the same code on FC4, wasn't it?

Presumably another code path (either as a fallback to the XGetFontPath() code or
perhaps the XGetFontPath() code *is* the fallback) worked okay on FC4

So, yes "bad XGetFontPath() assumption" is a bug we'd like to get fixed in the
plugin, but this bug should be about getting the *other* code path working like
it did on FC4

If someone could attach an "strace -fx" of firefox on FC4 loading the plugin and
rendering a page that's broken on FC5, we might be able to figure out what was
going on with FC4

*** Bug 186600 has been marked as a duplicate of this bug. ***

Note--

It works with FC5 running with the old xorg-x11-xfs package (and the necessary
xorg-x11-libs installed). 

xfs must be symlinked to somewhere in the search path, since it's in the
/usr/X11R6/bin directory which is no longer searched.  The massive directory
shift probably affected this-- sounds like from the above that the app is
searching in directories in the /usr/X11R6 tree which no longer exists in FC5. 
Will do an strace and attach.

The plugin hardcode the locations for the xfs config file:
/usr/X11R6/lib/X11/fs/config and
/usr/X11R6/lib/X11/fs-xtt/config

ln -s /etc/X11/fs/config /usr/X11R6/lib/X11/fs/config
fixes the problem on FC5.  I can attach the relevant strace if you really want,
but that's the problem. 
Stuff from strace, with no symlink on FC5:

28333 open("/usr/X11R6/lib/X11/fs/config", O_RDONLY) = -1 ENOENT (No such file
or directory)
28333 open("/usr/X11R6/lib/X11/fs-xtt/config", O_RDONLY) = -1 ENOENT (No such
file or directory)
28333 write(38, "\x34\x03\x01\x00", 4)  = 4
28333 read(38, 0xbffe5844, 32)          = -1 EAGAIN (Resource temporarily
unavailable)

On FC4 or on FC5 with the symlink:

27793 open("/usr/X11R6/lib/X11/fs/config", O_RDONLY) = 40
27793 fstat64(40, {st_mode=S_IFREG|0644, st_size=1372, ...}) = 0
27793 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb2a01000
27793 read(40, "#\n# xfs font server configuratio"..., 4096) = 1372

etc. as it finds the config file where it wants.

Bad, bad behavior on the part of the plugin, but there you go.

(In reply to comment #30)
> The plugin hardcode the locations for the xfs config file:
> /usr/X11R6/lib/X11/fs/config and
> /usr/X11R6/lib/X11/fs-xtt/config
> 
> ln -s /etc/X11/fs/config /usr/X11R6/lib/X11/fs/config
> fixes the problem on FC5.

Good call, it must be parsing the config file to find the font path and falling
back to XGetFontPath() when that fails.

"/etc/X11/fs/config" is shorter than "/usr/X11R6/lib/X11/fs/config", and both
seem to be a "C null-terminated strings". In such a case it is possible to edit
binary file...

Is such a way allowed? (i.e. are there some legal issues with such "binary"
editing?)

I personally did that on my own laptop because I didn't want to use the symlink
hack.  But it is against the license agreement to modify and distribute their
binary.  They wouldn't let us modify the binary of an earlier version in Bug
#155230 to prevent the plugin from disabling execshield in the browser.  Even if
we could modify the binary, the binary would be broken on all previous distros
if we did this.

It is Macromedia's responsibility to fix this in the proper way in their next
release.
 

Even with the symlink in place, I still see missing fonts for some flash sites.

In order to fix the fonts for finance.google.com, I had to add FontPath entries
to /etc/X11/xorg.conf as decribed here:

http://www.fedoraforum.org/forum/archive/index.php/t-97330.html

Bryce:

The only reason that adding FontPath entries to /etc/X11/xorg.conf would work
and adding the symlink wouldn't is if xfs is either not running, or if the
directories you're adding as FontPaths don't appear in /etc/X11/fs/config either.

Something interesting (or perhaps not) that I just noticed when going to create
the symlink: on my FC5 system, with /usr and /etc on the same filesystem, the
two files are actually hardlinked!  I am not sure what caused that (I know it
wasn't a direct action by me), but something in one of the FC5 updates made that
happen.

*** Bug 199006 has been marked as a duplicate of this bug. ***

This looks like it's fixed in the Flash Player 9 beta that you can get here:

http://labs.adobe.com/downloads/flashplayer9.html

everything looks good here http://www.miniclip.com/motherload.htm