- Start with a clean profile - Go to a page with the font specified as sans-serif (a file with <div style="font-family: sans-serif; font-size: 100px">Foo</div> is sufficient) - Go to Preferences/Content/Fonts & Colors/Advanced - Note that sans-serif is set to sans-serif if you really know fonts, you might note that the page is not displaying with the system sans serif (Bitstream Sans) but rather with Nimbus Sans L, so something somewhere is specifying Arial or Helvetica. - Pop up the drop down, select sans-serif again, then click OK on the dialog. - Watch the font on the page change. The font on the page is now actually displaying with the system sans serif.
Could you please provide some specific URL you have on mind, so that we are talking about the same thing?
echo "<div style="font-family: sans-serif; font-size: 100px">Foo</div>" > /tmp/foo.html Then "file://tmp/foo.html" will be a specific URL.
I mean file:///tmp/foo.html
Created attachment 146919 [details] HTML file Can fully confirm. Attached is the example page provided by reporter, converted via File/Print in Firefox (firefox-1.5.0.9-6.el5) and ps2pdf to PDF, and for comparison the same page created with OpenOffice.org Writer (openoffice.org-writer-2.0.4-5.4.16). Inspecting PDF files both visually and with pdffonts, it is clear that really Firefox uses NimbusSansL-Regu instead of sans-serif (which should be probably DejaVu Sans or Bistream Vera Sans -- what's the default for RHEL5b2).
Created attachment 146921 [details] Rendered to PDF [matej@hubmaier ~]$ pdffonts test-224483-firefox.pdf name type emb sub uni object ID ------------------------------------ ------------ --- --- --- --------- LWWHKC+DejaVu_LGC_Serif.Book.0.0.33ad8.0.Set0 Type 1C yes yes no 8 0 HSAEUE+Nimbus_Sans_L.Regular.0.0.18c3c.1583.Set0 Type 1C yes yes no 10 0 [matej@hubmaier ~]$
Created attachment 146924 [details] Comparison text written in OOWriter
Created attachment 146925 [details] attachment 146924 [details] rendered in PDF (via "File-Export to PDF") Notice shapes of letters F and Q both in rendered HTML and ODT -- they are widely distinct between HTML and ODT rendered sans-serif font.
Comment on attachment 146925 [details] attachment 146924 [details] rendered in PDF (via "File-Export to PDF") [matej@hubmaier ~]$ pdffonts test-224483.pdf name type emb sub uni object ID ------------------------------------ ------------ --- --- --- --------- BAAAAA+DejaVuLGCSans TrueType yes yes yes 14 0 CAAAAA+BitstreamVeraSans-Roman TrueType yes yes yes 9 0 NimbusSansL-Regu Type 1 yes no yes 19 0
Behdad, any comments -- I guess sans-serif magic falls into your area, right?
Humm, what about the font for Latin? This is absolutely firefox madness. I remember seeing it toss various font families at Pango to render anything... Will check it out.
Fedora Core 6 is no longer supported, could you please reproduce this with the updated version of the currently supported distribution (Fedora 7, 8, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as CANTFIX. Setting status to NEEDINFO, and awaiting information from the reporter. [This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or Gecko. If you see any other reason, why this bug shouldn't be closed, please, comment on it here.]
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA. {This is mass-closing of all obsolete bugs; if this bug was in your opinion closed by mistake, please, reopen it with additional information; thanks a lot and I am sorry for bothering you in such case.}
There is no insufficient data. If you think the bug is fixed in the mean time, confirm that and close fixed. If you think this should be tracked upstream, say so and forward upstream and close upstream. If you think it's not important enough to fix, say so and close wontfix. Closing random bugs, specially those opened by Owen Taylor doesn't help :).