This bug is for the apostrophe substitution issue discussed in bug 105703; looks like people are familiar with the em-dash problem also described there.. Opening this as suggested by bstell when he closed 105703; bstell has requested not to be cc'd. Descriptions etc. are in bug 105703; if you need debugs/screenshots, please send instructions in the next week or so while I still have the setup to reproduce. thanks, L. Date: Mon, 29 Oct 2001 11:35:34 -0800 From: Brian Stell <bstell@netscape.com> To: Lloyd Wood <L.Wood@eim.surrey.ac.uk> Cc: bzbarsky@mit.edu Subject: Re: [Bug 105703] display problems with em-dashes and apostrophes (representations) Its probably a related bug. The basic issue is: where do we get glyphs for characters not in the primary font. We first started out by looking thru the prefs for fonts to look in. The problem is that the Japanese fonts had glyphs for many of the desired characters but as Japanese fonts tend to be constant width characters so these chars (eg: smart quote, em-dash) came out much too large. The first hack was to disable these glyphs in the Japanese fonts. It made Western docs look good but Japanese docs look bad. I restored the Japanese glyphs but disabled them in Western docs by adding an "early" transliterator. This prevented the Japanese glyphs but also disabled the code from finding the Western glyphs in the "last ditch try". To "find" these glyphs earlier I've added a hack to look for the characters just before the early transliterator. See: http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#3730 Let me know which fonts these chars are in and let's consider extending the hack to include these. Brian Lloyd Wood wrote: > > Despite bzbarsky's comment on the apostrophe problem being a glyph > substitution problem, focus seems to be on fixing the em-dash. > > Should I file a separate bug on the apostrophe? > > thanks, > > L.

Lloyd: 1) Create a document containing the apostrophe, em-dash, and any other characters from the story you feel are now being misrendered. 2) Change the font in that document to -misc-fixed-iso-8859-13. 3) Report in this bug whether or not the appearance of those characters in that font is acceptable. Feel free to attach a screenshot. If they are acceptable, I will email bstell and let him know; that should be enough data for him to provide a fix. If not, there may not be a font on your system that renders them properly.

> Lloyd: > > 1) Create a document containing the apostrophe, em-dash, and any other > characters from the story you feel are now being misrendered. raw html doc, nothing else? bstell had a list of high ascii chars he wanted to look at, but didn't indicate how to display them - with unicode representations? > 2) Change the font in that document to -misc-fixed-iso-8859-13. how do I do that? stylesheet? content-type in header? one of mozilla's many font-related menu options? I have misc-fixed-iso-8859-1 and misc-fixed-iso-8859-15 available in Preferences... Appearance/Fonts. I do not have -13 available as an option there, despite font dumps appended to bug 105703 reporting -13. Hence confusion/difficulty and resulting questions for clarification. L.

Any kind of text/whatever document should be fine. Easiest for you would probably be to create an HTML document representing the characters by character references (&#number;). To get it displaying in iso-8859-13 in Mozilla, try View->Character Coding->More->East European->Baltic (iso-8859-13). I think this will do the trick. If this doesn't work, I *may* be able to test this independently; it looks like the iso-8859-13 font that appears in the font dump you supplied is autogenerated from the standard iso 10646 transcoded fonts for XFree86. I'm installing them right now; I'll take a screenshot of what you should hopefully see for the document in iso-8859-13.

> Any kind of text/whatever document should be fine. Easiest for you would > probably be to create an HTML document representing the characters by > character references (&#number;). To get it displaying in iso-8859-13 in > Mozilla, try View->Character Coding->More->East European->Baltic > (iso-8859-13). Ah. Done that. Am attaching: - screenshot with Baltic -13 encoding selected as above. Note lack of visibility of dashes. - tcl script used to generate html page for output. tclsh test.tcl > test.html L.

Ugh, that didn't work. Experimentation on my own machine leads me to believe that all of the adobe-* and misc-fixed-* fonts use the -- glyph for em-dash. Something else peculiar is going on here; my own system has a font (which I haven't identified yet, I'll have to make a font dump), which is appears to be different from the Lucida used on the ALA page and is supplying a correct em-dash and some thin, ugly-looking left and right quotes. I'll have to get a font debug build and find out what that is. cc'ing bz; bz, do you have a dump of font debug information for a page with em-dash and transliteration turned off? AIUI, once we know where that glyph is coming from, bstell can hack that into the pre-early-transliteration bit and supply the right glyph regardless of pref.

cc'ing ftang at bstell's request. Very odd; using xfd reveals a character in both iso-8859-13 and iso-8859-15 which appears to be em-dash in some character tables on the web, but appears smaller than ASCII hyphen in the misc-fixed fonts (only common iso-8859-13 and -15 fonts for Linux, AFAIK.)

.

With Mozilla ver 1.3a, the apostrophe appears as a white question mark on a black diamond background. My language setting is western ISO-8859-15. See: http://www.heartcenteronline.com/myheartdr/common/artprn_rev.cfm?filename=&ARTID=350

Continuation of my previous comment. The same URL displays the apostrophe correctly with IE 6.0. In Netscape 4.79 the the page and source code should the apostrophe correctly. In the source code in Mozilla 1.3a the apostrophe is displyed as a white question mark inside a black diamond background.

Another page which unfortunately shows this problem: http://www.mozilla.org/start/1.5/ Filed bug 22692 requesting that we use normal apostrophes for the start page.

Akkana, I'm not convinced that the last 3 or 4 comments are talking about the same bug as the original report: that was a fonts issue and the newer reports seem to be more of a character integrity issue. http://www.mozilla.org/start/1.5/ has been changed in the meanwhile: do you see the same problem in general NCR test pages like http://www.theorem.ca/~mvcorks/cgi-bin/unicode.pl.cgi?start=2000&end=206F ?

I'm the offending user who first spotted this, and the test page shows fine using exactly the same setup where the "apostrophe" failed on /start/1.5/ If I can check or run any other tests, let me know. And, of course, /start/1.5/ is fine now. Thanks all. Dave