[this is related to bug 51288 ("Use standard PostScript glyphs for some Unicode characters")] Xprint module does not print special glyphs like em-dash or dagger correctly - they appear correctly on screen - but Xprint module prints '?' or '¼' instead... I'll attach a testcase...

Assign to Roland.

I see the same problem in Xlib-toolkit... well... looks like an issue in nsFontmetricsXP.cpp (again... :-)...

Xlib toolkit has the same problem - all the "em-dash & co."-glyphs are displayed/printed as '?' ... ;-( ---- CC:'ing the gods of font stuff {rbs@maths.uq.edu.au,bstell@netscape.com} - I need their help with this issue... at least one or two hints what may cause this issue ... ;-(

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

First, let me say that I am not at all experienced with moz's XPrint code. If I were working on this problem the first thing I would try to do is determine what encoding, character, and font was used to send to the XPrint server. I'd use a breakpoint or printf in the draw routine. Mozilla's draw routines get Unicode values so the font selected should control which converter was used. Once the converted character value was known I would look it up in a reference for that encoding to make sure it is the expected character. I would then use xfd to display that character in the selected font and I would look at the glyph to verify that the font is correct. If all this looks okay then I would make a very simple test program to verify if the XPrint server is or is not printing correctly. If it does not print correctly I would submit this test program to the XPrint server developers as a bug report. (If the test program prints correctly then I would have to scratch my head and try to figure out what I had missed.)

bstell: Mozilla's Xprint module shares a _huge_ part of code with the Xlib toolkit (nsFontMetricsXlib*, nsRenderingContextXlib.* etc. etc.) - and Xlib toolkt suffers from the same bug... I assume the bug does not sit in the Xprt server (X print server)... :-) Wanna build a Xlib toolkit Zilla (configure --enable-toolkit=xlib) and see if you can catch this issue, please ?

Fixing COMPONENT to "XP Toolkit/Widgets" - this is not an Xprint module specific issue, Xlib toolkit is affected, too. Adding "HELPWANTED" keyword... I spend some time on debugging the issue forth and back - and failed to kill this issue... ;-(

rbs: Is there any common detail between "em-dash"&co. and MathML fonts/chars which may explain this issue ?

This bug sounds like another hard bug: "Xprint [and Xlib] module does not print special glyphs like em-dash or dagger correctly - they appear correctly on screen - but Xprint module prints '?' or '¼' instead..." i.e., screen=ok, printer=bad. I sincerely have no idea as to what is happening.

Could the X server and XPrint server have different font paths?

rbs@maths.uq.edu.au wrote: > This bug sounds like another hard bug: That's this one... I only changed the SUMMARY of the bug. > "Xprint [and Xlib] module does not print special glyphs like em-dash or dagger > correctly - they appear correctly on screen - but Xprint module prints '?' or > '¼' instead..." > > i.e., screen=ok, printer=bad. I sincerely have no idea as to what > is happening. No no. screen[Xlib_toolkit]=bad, printer=bad. Noth suffer from the same problem. Only screen[GTK+_toolkit]=ok

Brian Stell wrote: > Could the X server and XPrint server have different font paths? No, I usually start Xprt like this: -- snip -- % Xprt -fp $(xset q | fgrep "/X11/fonts/misc/") -audit 4 :1 -- snip -- And as I wrote few secs ago to rbs - Xlib toolkit suffers from _exactly_ the same problem - I only changed the SUMMARY of this bug (sorry for the confusion...).

Because of glyph fill-in I had the same problem in the GTK code trying to figure out where the code was looking for glyphs. I believe that this is the reason Erik added NS_FONT_DEBUG_LOAD_FONT and it is definitely the reason I added FIND_FONT_PRINTF. If I were working on the problem I would add in these debug tools and then make a simple test case that only displayed one char. I could then know where it got (or failed to get) the glyph from. We should also seriously consider merging the GTK+ and Xlib code.

This issue is still present... ;-( Retargeting to 0.9.6 milestone...

bstell: Is it possible that we simply do not have the neccesary unicode converter loaded/linked/build ?

I'd recommend making a very short test page (just one char) and breakpointing in DrawString. After the conversion: int len = mCharSetInfo->Convert(mCharSetInfo, mFont, aString, aLength, p, bufLen); Look at the value in the buffer (p).

Looks like this won't make it in for 0.9.6.

Still no clue, retargeting ...

This patch generates a lot of assertions like this when viewing the testcase: -- snip -- Document http://bugzilla.mozilla.org/showattachment.cgi?attach_id=38071 loaded successfully ###!!! ASSERTION: no gFontSubConverter: 'gFontSubConverter', file ../../../../../../../../home/mozilla/src/2002-02-27-08-trunk/mozilla/gfx/src/xlib/nsFontMetricsXlib.cpp, line 2334 ###!!! Break: at file ../../../../../../../../home/mozilla/src/2002-02-27-08-trunk/mozilla/gfx/src/xlib/nsFontMetricsXlib.cpp, line 2334 ###!!! ASSERTION: no gFontSubConverter: 'gFontSubConverter', file ../../../../../../../../home/mozilla/src/2002-02-27-08-trunk/mozilla/gfx/src/xlib/nsFontMetricsXlib.cpp, line 2334 ###!!! Break: at file ../../../../../../../../home/mozilla/src/2002-02-27-08-trunk/mozilla/gfx/src/xlib/nsFontMetricsXlib.cpp, line 2334 ###!!! ASSERTION: no gFontSubConverter: 'gFontSubConverter', file ../../../../../../../../home/mozilla/src/2002-02-27-08-trunk/mozilla/gfx/src/xlib/nsFontMetricsXlib.cpp, line 2334 ###!!! Break: at file ../../../../../../../../home/mozilla/src/2002-02-27-08-trunk/mozilla/gfx/src/xlib/nsFontMetricsXlib.cpp, line 2334 -- snip -- which indicates that -- snip -- nsComponentManager::CreateInstance(kSaveAsCharsetCID, nsnull, NS_GET_IID(nsISaveAsCharset), (void**) &gFontSubConverter); -- snip -- is failing... but why ?

This mess was caused by a simple typo... nice... xx@@!!!... ;-(

Requesting r=/sr= ...

Comment on attachment 71976 [details] [diff] [review] Patch for 2002-02-27-08-trunk I think what you want is attr_EntityAfterCharsetConv. This is what GfxWin uses. See my description in bug 33498 comment #4.

rbs: I am using the same call as GTK+ (except that typo), see http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#2544

Yep, I know -- that's why I pointed you at my earlier description. The GTK call itself is not doing what you might want. I am just profiting from this opportunity for a fixup.

s/bug 33498 comment #4/bug 33498 comment #9/

OT: Another issue... the chars which were previously rendered as '?' (fixed by my attachment 71976 [details] [diff] [review]) do not scale with the text zoom (setting text zoom to 300% does not scale the chars, they are still in the same size as in 100% text zoom mode). Backing out the patch doesn't help either, the '?' are not scaled, too. GTK+-based Zilla does scale them correctly. Does anyone have an idea where this problem may hide ?

Roland: would you try rgb's suggestion and if it is okay we should also apply it to the GTK code. > the chars which were previously rendered as '?' (fixed by my attachment > 71976) do not scale with the text zoom This sounds like a separate problem from this bug since the Gtk port does scale them. Perhaps you could open a new bug for this. Shanjian: can you help Roland with this

Brian Stell wrote: > Roland: would you try rgb's suggestion and if it is okay we should also > apply it to the GTK code. I filed bug 128530 ("Use |nsISaveAsCharset::attr_EntityAfterCharsetConv| instead of |nsISaveAsCharset::attr_EntityBeforeCharsetConv| in GTK+/Xlib toolkits") to handle this and attached a patch there...

Comment on attachment 71976 [details] [diff] [review] Patch for 2002-02-27-08-trunk r=bzbarsky on the code if we want this right now, as long as we have a separate bug to do this right....

Yes, it's the right thing for now... text zoom for these special chars (like dagger etc. - all others are working) doesn't work, but at least we can display/print the chars now. Better than nothing... :)

Fix integrated into the patch for bug 128748 ...

Patch for bug 128748 has been checked in, marking this bug as FIXED.

Follow-up is bug 129666 ("[Xlib] Xlib/Xprint do not scale em-dash & co. correctly...") ...