Closed Bug 86563 Opened 24 years ago Closed 24 years ago

font tag and quote no longer mix well

Categories

(Core :: Internationalization, defect, P4)

Product:
Core
Component:
Internationalization
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: fred, Assigned: shanjian)

References

Details

(Keywords: relnote)

Attachments

(3 files)

Minimal test case
301 bytes, text/html
Details
Normal behaviour (in Moz 0.9)
24.54 KB, image/png
Details
Broken behaviour (moz 0.9.1, nightly)
27.55 KB, image/png
Details
I'll attach a test case. It seems HTML parser (or maybe DOM) is now displaying tag as content. This problem was not present in Mozilla 0.8.1 and Mozilla 0.9. It is present in Mozilla 0.9.1 and nighly build (2001061706) Test case and screenshots attached
Attached file Minimal test case —
You must have Verdana font installed on system (through xfs using XFree86 4)
Verified on build: 2001-06-27-04-Trunk platform: Win NT I have Verdana font installed on my machine and the test case loads as expected.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Component: HTML Element → Parser
Resolution: --- → WORKSFORME
This is a linux bug !!! Reopening..
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
wfm correctly using build 062906 running on newest SuSE distro (7.2, including up to date XFree86 4..)
This seems to have something to do with font selection, although I'm not sure whether it's more likely to be a bug in Mozilla or a bug in the font.
Assignee: clayton → nhotta
Component: Parser → Internationalization
QA Contact: bsharma → andreasb
Cc to IQA, can anyone reproduce this? Reassign to bstell.
Assignee: nhotta → bstell
I can not reproduce it on both 07-13 Branch and N6.1PR1 build / RedHat6.2-Ja by running the attached test case.
I'm still seeing this problem using XFree86 4.1 (Mandrake cooker) and Microsoft Verdana font on Build 2001071621 I don't think font tag is "eaten" but I think wrong charset is used to retrieve font glyphs..
I cannot reproduce this in 7-17-0.9.2 build. Frederic Crozat, have you changed anything in font preferences?
QA Contact: andreasb → ylong
Nothing changed : I have this problem on a fresh test machine, without any mozilla (nor netscape) preferences.. This problem can be reproduced on Mdk 8.0 (XF 4.0.3) or Mdk Cooker (XF 4.1) with Microsoft Verdana font installed (seen as microsoft-verdana-*-*..)
Sorry, I just noticed I don't have this verdana font in my system, that's probably why I can not reproduce it. Is there any good place that I can get (download) the font for RedHat6.2?
Well, from a Microsoft system :(( Be sure to copy all verdana*.ttf file, run ttmkfdir to create fonts.dir file..
I copied all verdana*.ttf file in my ReaHat6.2-Ja system, and when I run xlsfonts | grep verdana, I can see the verdana fonts list. Then I start ./netscape, but still can not reproduce it by running the testcase. - I have checked "Allow documents to use other fonts" in preferences, and there is no verdana fonts list in the western-iso-8859-1 list.
ok, I've finally found what to do exactly to reproduce this problem, since it is no longer present on Mandrake cooker, with latest XFree packages : it appears ttmkfdir was not "publishing" verdana fonts with the microsoft-cp1251 encoding.. When this encoding is not available (ie with Mandrake 8.0 and some older cooker or by deleting the -microsoft-cp1251 line in fonts.dir) and with Mozilla 0.9.1 or greater, the symptoms are present. With Mozilla 0.9, no problem. The symptom only disappears when verdana font is available in microsoft-cp1251 encoding.. The strange thing is that the test case is in iso-8859-1 encoding, not microsoft -cp1251 (and it has been done under linux..) After digging in Bonsai to find what has changed between Moz 0.9 and 0.9.1, this bug might be caused by bug #81786 (I'm not sure..) Anyway, I'm wondering if we should close this bug (maybe add some warnings in release notes) or dig further..
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: relnote
I think we should close this bug per Frederic Crozat 's comment. But I want to let bstell know this issue.
I am closing this as WORKSFORME since no one here can reproduce it and the bug originator suggested we close it.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Mark it as verified according previous comments.
Status: RESOLVED → VERIFIED
*** Bug 96929 has been marked as a duplicate of this bug. ***
Reopening : there is at least 2 duplicates of this bug in the database. And I've finally found what caused this problem (with help of NS_FONT_DEBUG variable) : it is checking 1.139 of mozilla/gfx/src/gtk/nsFontMetricsGTK.cpp (ie ISO8859-13 font support) After removing support of ISO8859-13, Mozilla retrieves correct glyphs for these smart quotes... With the ISO8859-13 support, Mozilla loads the iso8859-13 font for Verdana.. I think it was only seen in Mdk 8.0 because we (MandrakeSoft) have support for many languages and we were probably the only one with ISO8859-13 support for fonts in XF 4.1.. And BTW, this problem can still be seen in Mdk 8.1 (and my previous workaround is not working..)
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Frederic: I'm pleased that the font debug printfs helped. Do I understand your comments correctly: Verdana iso8859-13 font from xfs gives the wrong glyph for "right double quotation mark" (Unicode \u201D, decimal 8221). I wonder if it is the font or the converter. If you are able to build mozilla could you put a printf in the draw routine to see what hex value is coming out the converter and then drawn? (I'd recommend that the test html page just have the one NCR.) http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp 2028 nsFontGTKNormal::DrawString(nsRenderingContextGTK* aContext, ... 2045 gint len = mCharSetInfo->Convert(mCharSetInfo, 2046 (XFontStruct*) GDK_FONT_XFONT(mFont), aString, aLength, p, bufLen); 2047 GdkGC *gc = aContext->GetGC(); add a printf here to print the chars (as hex bytes) pointed to by p for length len. 2048 nsRenderingContextGTK::my_gdk_draw_text(aSurface->GetDrawable(), mFont, gc, aX, 2049 aY + mBaselineAdjust, p, len);
I've made some tests with printf : when verdana is available in iso8859-13, rdquo (the right quote which is badly displayed) is displayed using ffffffa1 (ie using char #a1 from iso8859-13).. when there is no iso8859-13 encoding for verdana, rdquo is displayed using 201d (ie the official unicode code for this glyph).. This problem is also present with some other "smart quotes" (I haven't made a full list) and only with Microsoft truetype font.. When checking with showfont, it appears microsoft fonts are incorrectly mapped in this particular encoding but there is still a problem because Mozilla should not use iso8859-13 encoded font (I think, even if some of these glyphs are available in this encoding), but iso10646-1 (ie unicode) encoded font for these smart tags..
Ok, after discussing with our i18n specialist, it seems we have 2 separate bugs : -mozilla should not try to find glyphs in iso8859-13 but directly in unicode font -in Mdk 8.0 (this will be fixed in 8.1), the file encodings.dir in /usr/lib/X11/fonts/drakfont/ is not present (it should be a symlink from /etc/X11/encodings.dir) and therefore microsoft truetype fonts are wrongly mapped in some charset (ie iso8859-13).. There should be a specific note in Mozilla Release note (I think this note should be more general than Mdk 8.0 has truetype font broken, since a lot of people who install truetype fonts by hand only run ttmkfdir and don't put encodings.dir file).. This problem will go away with future version of XFree86
> -mozilla should not try to find glyphs in iso8859-13 but directly in unicode > font Are you suggesting we drop support for all iso8859-13 fonts because people improperly load TrueType fonts? Also, 10646 fonts can be extremely expensive to load and hence we do not favor them.
I've never suggested support for iso8859-13 should be dropped.. But from our i18n specialist point of view, Mozilla should not try to grab glyphs from other encodings than the current one and 10646 one, since spacing and other things can be very wrong.. 10646 font can be very long to load if fonts have maps completely 10646 charset but many fonts (as Truetype one) only maps a subset of 10646..
Such a change would break many things, among them many HTML character entities, and would also hurt performance significantly.
> Mozilla should not try to grab glyphs from other encodings than the current > one and 10646 one, since spacing and other things can be very wrong.. Are you suggesting that 10646 fonts will visually match any other font? Are you suggesting that most user's systems have a good selection of 10646 fonts with all the needed characters and all in all the needed sizes? It would be wonderful if all fonts had glyphs for all Unicode points then we could just use one font (ignoring of course the Han ambiguation problem). Since this is not true and mozilla is commited to make readable text when ever possible Linux moz has a lot of code to allow it to find glyphs. Moz tries to find glyphs in fonts in the same language group and of the same size when possible. I cannot imagine why moz should ignore all non 10646 fonts as a source of glyphs. > 10646 font can be very long to load if fonts have maps completely 10646 > charset but many fonts (as Truetype one) only maps a subset of 10646.. Know any way to find out what chars have glyphs in a 10646 font without opening it? That is expensive.
Status: REOPENED → ASSIGNED
Target Milestone: --- → Future
(PS: I'm the "i18n expert" Frederic talks about). I'm not saying to discard any non-iso10646-1 font; but when there is an iso10646-1 one and an iso8859-13 one (or other encoding) with all other properties the same (face name, founder, size, resolution, style, etc); then it makes sense to use the iso10646-1 one, as in fact the others are just virtual fonts created out of the real one that is in unicode encoding. But I'm not very strongly convinced about it either. (in fact I'm convinced that any serious text rendering should be done trough Xft font mechanism instead)
Kaixo! > when there is an iso10646-1 one and an iso8859-13 one (or other encoding) > with all other properties the same (face name, founder, size, resolution, > style, etc); then it makes sense to use the iso10646-1 one, as in fact the > others are just virtual fonts created out of the real one that is in unicode > encoding. I see 2 separate issues here: 1) iso8859-x fonts may hand generated or may be generated from a Unicode (probably TrueType) font. Since hand generated fonts always look the best we should use them when possible. It is possible that the Unicode font had embedded bitmaps that were used to generate the iso8859-x font but my impression so far is that outline fonts generated into bitmaps or served up via Xfs are not that great looking (I have open bugs from user about this). Thus I still lean toward using the iso8859-x font since I believe it increases our odds of getting a hand tuned font. 2) X apps use the XLFD to select fonts. Excluding 10646 fonts, most of the fonts have glyphs for all the characters in their XLFD encoding. This means that when searching for a glyph an app can just look at the XLFD and decide if there is a glyph. With 10646 fonts an app must load all the glyph metrics to determine which glyphs are available. This is a very expensive operation and hence we try to avoid 10646 fonts because of this performance burden. (This is one of my biggest issues with Xft's current design.) PS: what does Kaixo! mean?
Your make a good observation that some X fonts are being generated by taking subsets of larger fonts. An application can produce better looking results by first looking in related fonts for characters not in the current font. Earlier this year we modified moz's font search routine to logically regroup these subsets. I am working on documenting how moz finds fonts in bug 90384.
future, p4, normal, move to shanjian
Assignee: bstell → shanjian
Severity: critical → normal
Status: ASSIGNED → NEW
Priority: -- → P4
I didn't see there was any thing need to be done for this bug. Close it as wfm.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Verified wfm.
Status: RESOLVED → VERIFIED
*** Bug 110046 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: