I see squares in the latest Cairo build where I see the characters displayed normally in 1.5. Some pages for comparison: http://www.alanwood.net/unicode/mathematical_alphanumeric_symbols.html http://www.alanwood.net/unicode/arrows.html http://www.alanwood.net/unicode/mathematical_operators.html http://www.alanwood.net/unicode/geometric_shapes.html

I also see a block where the dash should be in some of the flags here in bugzilla like blocking‑aviary1.0.8.

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

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060223 Firefox/1.6a1 The top page of Google in Japanese shows all Japanese characters replaced with dots.

this fixes a bunch of cases where we don't currently do fallback fonts correctly by using mlang and creating a linked font. I've removed the std::vector usage and replaced it with nsTArray. I've made gfxFont's be refcounted. I've added a new API to cairo to allow fonts to be created with a HFONT. We had to do this because we need to be able to create our own custom fonts and have cairo use them. Having a LOGFONT isn't enough. This patch also has a font enum implementation for windows. I've made a few performance fixes for text measuring and such in this patch as well which should help a little. I've removed the string copies in gfxWindowsTextRun as well. Sadly, this patch doesn't fix very many of the sites listed in this patch that are using symbol or bitmap fonts. That is next.

updated patch with fixes from irc

The patch seems to have caused the following on my Win32/cygwin/MinGW system :- In file included from e:/mozilla/source/mozilla/gfx/thebes/src/gfxPlatform.cpp:4 1: ../../../dist/include/thebes/gfxWindowsPlatform.h:47:19: mlang.h: No such file o r directory In file included from e:/mozilla/source/mozilla/gfx/thebes/src/gfxPlatform.cpp:4 1: ../../../dist/include/thebes/gfxWindowsPlatform.h:65: error: ISO C++ forbids dec laration of `IMultiLanguage' with no type ../../../dist/include/thebes/gfxWindowsPlatform.h:65: error: expected `;' before '*' token ../../../dist/include/thebes/gfxWindowsPlatform.h:75: error: `IMultiLanguage' wa s not declared in this scope ../../../dist/include/thebes/gfxWindowsPlatform.h:75: error: template argument 1 is invalid ../../../dist/include/thebes/gfxWindowsPlatform.h:75: error: ISO C++ forbids dec laration of `mMLang' with no type make[6]: *** [gfxPlatform.o] Error 1

huh. that is exciting. not sure what to do about that. I haven't really done any mingw builds ever, but doing a quick google search makes it look like there is might be some mingw mlang support somewhere. Anyone know?

I filed bug 328499 for the mingw build issue.

I dealt with my mlang.h and usp10.h problems, but I still get a compile error. The patch for the error is, I believe, the patch attached to Bug #328499.

It's still somewhat broken with build 20060309. I'll attach two capture, one that shows the problem, and the other that's went OK just by slightly resizing the FF window. This shows the problem happens in lines that start with europeans characters and switch to thai characters later. I think knowing this will be useful to fix it :-)

This attachment shows how a small resizing suffices to make the display OK.

That Thai behavior sounds more like bug 328940, I don't know if that's the same issue as this or not (some Unicode characters seem to _never_ be displayed).

OK, my Thai problem was indeed bug 328940, that is now fixed (bug 332649 opened for an even better fix). I'd like to list clearly what we know still doesn't work : - Bitmap fonts : blocked by bug 324706 - Symbol fonts : but how much support do we really want to implement for fonts that are not unicode compliant ? - Math ML support : http://www.mozilla.org/projects/mathml/start.xhtml is obviously broken, not just the layout, but most of the chars missing. But about the allan wood page above, everything seems now to display quite properly and on W2K I get just as many characters displayed than with IE, that means none of the surrogates on mathematical_alphanumeric_symbols.html. Note : I don't know if thebes needs the activation of special setting to display surrogates on W2K (as IE requires). See the description of that here : http://www.i18nguy.com/surrogates.html I see more characters on mathematical_alphanumeric_symbols.html with the latest trunk seamonkey/wingfx, but in truth I miss the required fonts and what is displayed is seriously bogus (they're not bold, not italic, not script, not fraktur when they should). So here it's seamonkey/wingfx that's broken, not thebes.

Well, there's definitely still a problem, because the Arrows page linked shows boxes for everything after U+21EA and I have two fonts installed that contain the entirety of the Arrows block (Code2000 and Everson Mono Unicode). The behavior is different than non-Cairo - in a non-Cairo build, if you don't have a font that contains a particular character, you get a question mark (i.e. "Gecko couldn't find a font for this character and gave up"). Viewing those pages in Cairo, I get squares (i.e. "Gecko found a font but the font doesn't actually have the character somehow"), so it seems to me like something is wrong with Cairo's ability to determine whether a font contains a given character, or its ability to switch fonts when necessary.

I can confim after instaling Everson Mono Unicode : fails in Minefield/thebes, works in latest trunk Seamonkey/gfx windows. If EMU is set as the default western encoding font in Fx, the whole page displays correctly, so there's still a font fallback problem.

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

fixed as part of 340590

Sorry Stuart, but the testcase in c#14 is still broken in 20060611 (you can download evermono here to test http://www.evertype.com/emono/). The display did change a bit, but the characters are still missing. The trouble with this bug 324560 is that so many problem have been dupped to it that it can be considered more as a meta bug, and it's very hard to solve everything with only one patch. You might consider it better to open a follow-up bug for this issue if you consider if it require significant more work to solve.

(In reply to comment #18) > Do you mean that all Everson characters don't display? I see this: http://img123.imageshack.us/img123/2766/naamloos2bq.png

I did a comparison with Firefox 1.5 and the following pages are still for more than about 80% broken on trunk cairo (I see squares): http://www.alanwood.net/unicode/arrows.html http://www.alanwood.net/unicode/supplemental_arrows_b.html http://www.alanwood.net/unicode/block_elements.html http://www.alanwood.net/unicode/box_drawing.html http://www.alanwood.net/unicode/combining_diacritical_marks_for_symbols.html http://www.alanwood.net/unicode/control_pictures.html http://www.alanwood.net/unicode/currency_symbols.html http://www.alanwood.net/unicode/dingbats.html http://www.alanwood.net/unicode/enclosed_alphanumerics.html http://www.alanwood.net/unicode/letterlike_symbols.html http://www.alanwood.net/unicode/mathematical_alphanumeric_symbols.html http://www.alanwood.net/unicode/miscellaneous_symbols.html http://www.alanwood.net/unicode/miscellaneous_technical.html http://www.alanwood.net/unicode/number_forms.html http://www.alanwood.net/unicode/optical_character_recognition.html

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060611 Minefield/3.0a1 ID:2006061201 [cairo] I use Arial as sans-serif font and >95% of the symbols display just fine.

(In reply to comment #21) > I tested the default settings (= allow pages to choose their fonts)

Default is also: serif. When I set proportional to sans-serif the following two links achieve better results: http://www.alanwood.net/unicode/box_drawing.html http://www.alanwood.net/unicode/control_pictures.html This one for about 40%: http://www.alanwood.net/unicode/letterlike_symbols.html But the rest is about the same.

all of those pages render fine for me...

I should point out that I'm using default font prefs for everything. I don't have anything set.

also, re the ? marks vs the blocks -- if we can't find anything we go back to the original font and draw the blocks using that. This may change later, but for now I like the blocks better than the ?s.

Stuart, I pointed you to https://bugzilla.mozilla.org/show_bug.cgi?id=324560#c14 because it describe one precise problem and enough info for reproduction. - Download Everson Mono - Install it on your OS - Display the page http://www.alanwood.net/unicode/arrows.html - Before Cairo : All characters display, Everson Mono has them all - After Cairo : Everything after U+21EA doesn't display (few fonts have those characters) - After setting Everson Mono as the default font : Everything displays again, so it's a problem of a less powerful fallback mecanism than before.

(In reply to comment #27) > Stuart, I pointed you to > https://bugzilla.mozilla.org/show_bug.cgi?id=324560#c14 because it describe one > precise problem and enough info for reproduction. Comment 14 doesn't describe anything in enough detail for any reproduction. If you read my comment 26, you'll see that we always draw blocks when we can't find a font -- even after we go through almost all the fonts on your system. For me, all of the characters on that page render without Everson Mono on my system. Most of them them are probably coming from CODE2000 on my system here. The OpenType unicode range table specifies: { 37, 0x2190, 0x21ff, "Arrows" }, { 37, 0x27f0, 0x27ff, "Supplemental Arrows-A" }, { 37, 0x2900, 0x297f, "Supplemental Arrows-B" }, I would guess that Everson Monon doesn't claim to support any of these -- I'll verify shortly when I change computers. If that is the case, it is more of a bug with the font than anything. If you have no fonts on your system that claim to support those ranges, then we keep looking, but we have a lot less to go on. We try to find fonts that are similar to to the family of the original font -- serif in this case. But since this isn't a serif font, we'll not give it any points for that and we'll then see that it is a symbol font. We'll dock it a few points for that, so it'll basically end up with -5 and be ignored. I'm working on tweaking the font ranking code a bit more, but it can be really expensive to actually go through every font on the users system and try to render with it. My laptop has over 3000 fonts on it and I'm already hitting some other performance problems due to some cases where we end up returning all the serif fonts on your system for fallback... Anyways, I'll check on that font shortly.

OK. I can reproduce the problem if I uninstall CODE2000 from my system. Everson does have the right bits set and claims to support those characters, however, when I try to render the glyphs it doesn't support it returns valid glyph locations as if it does support them... When I try to draw with them it gives me the box. The font doesn't have glyphs for things like 0x21FF in it, but it does for 0x21F1 and that doesn't render either. I'm not sure what causes this font to do the wrong thing. I'll poke around.

ria: you also have everson mono installed on your machine?

(In reply to comment #32) > ria: you also have everson mono installed on your machine? > Yeah, I deleted it and it has some effect: I see dashes now instead of squares :D http://img230.imageshack.us/img230/951/fonts5xs.png I see far more symbols on another, older computer, also XP.

(In reply to comment #20) > http://www.alanwood.net/unicode/arrows.html 21EB-21FF are squares for me. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060612 Minefield/3.0a1 ID:2006061205 [cairo]

(In reply to comment #20) > I did a comparison with Firefox 1.5 and the following pages are still for more > than about 80% broken on trunk cairo (I see squares): > > http://www.alanwood.net/unicode/arrows.html > http://www.alanwood.net/unicode/supplemental_arrows_b.html > http://www.alanwood.net/unicode/block_elements.html > http://www.alanwood.net/unicode/box_drawing.html > http://www.alanwood.net/unicode/combining_diacritical_marks_for_symbols.html > http://www.alanwood.net/unicode/control_pictures.html > http://www.alanwood.net/unicode/currency_symbols.html > http://www.alanwood.net/unicode/dingbats.html > http://www.alanwood.net/unicode/enclosed_alphanumerics.html > http://www.alanwood.net/unicode/letterlike_symbols.html > http://www.alanwood.net/unicode/mathematical_alphanumeric_symbols.html > http://www.alanwood.net/unicode/miscellaneous_symbols.html > http://www.alanwood.net/unicode/miscellaneous_technical.html > http://www.alanwood.net/unicode/number_forms.html > http://www.alanwood.net/unicode/optical_character_recognition.html > This was "something on my computer". Don't yet know what caused this misbehaviour but the half of all characters don't show up anymore since I installed and uninstalled Everson Mono. Something must have gone very wrong. Retested on another computer and everything is displayed well with a few exceptions: In some cases Minefield has another idea of what a character should look like than my text editor or Firefox 1.5. For instance here: http://www.alanwood.net/unicode/ancient-greek-numbers.html http://www.alanwood.net/unicode/mathematical_alphanumeric_symbols.html Just copy some symbols and paste them in a text editor or compare them with Firefox 1.5. Minefield interprets them differently. Screenshot here: http://img148.imageshack.us/img148/3712/fonts5eo.png

Not sure this is the same bug. The attached testcase works displays fine on non-cairo builds.

(In reply to comment #36) > Created an attachment (id=227976) [edit] > Testcase with chinese characters > > Not sure this is the same bug. The attached testcase works displays fine on > non-cairo builds. See also bug 343454 for CJK.

(In reply to comment #36) > I see them in sans-serif but not in serif

(In reply to comment #38) > (In reply to comment #36) > > > I see them in sans-serif but not in serif > Ah no, only when I choose my own font by overriding the choice of the website. Courier shows a kind of weird stripes.

Can we mark this fixed and split off the remaining bugs in to new bugs? The last testcase should be "Bitmap fonts claim to support unicode characters when they don't really" or something

I agree, the issue from the original report isn't happening anymore for me. I've filed bug 353756 for the other issue.