Erin Kissane's 'Typography Matters' in A List Apart neatly demonstrates two rendering problems with unusual characters (in my Mozilla 0.94 on Red Hat 7 as indicated by user-agent fields): 1. the (amp)rsquo; character gets rendered glaringly badly compared to 'normal' I-just-typed-it-on-the-keyboard apostrophes. My guess is that designers are tempted to use rsquo to indicate possession and for omitted letters, even when a normal apostrophe would suffice; the character is still glaring, though, as if it was a size or two too large. If rsquo was only using for quotes, it would still be an eyesore. What's up? 2. the em-dash (unicode #8212) character is rendered on-screen exactly as two hyphens rather than as a single long dash that you'd expect, even though this rendering can only be highlighted as a single character. If copied and pasted into a text window, two hyphens are pasted. It looks like someone has thought carefully about the em-dash case from a text-cut-and-paste-to-ascii viewpoint, without giving fidelity of browser rendering (basically all that design types care about) a similar level of attention. Of course, I'm presuming here that a proper em-dash is available for use in the font; other platforms apparently don't have this problem. (I've taking the liberty of sticking zeldman on cc since I don't pretend to understand typography. The very fact that I'm trying to describe these problems while typing in fixed-font courier clearly indicates this is doomed; my environment has trained me to use hyphens for everything.) L. it's not as if you can type em-dashes when programming C.

Reporter: would you mind attaching a screenshot if what you see differs from mine.

->layout

a quick check shows us using an en-dash to show the em-dash in april and the "--" char in August. Note that the "--" char is a _single_ character, which means that it's coming from some font that has that as the em-dash character. Dumb font, no? Ccing bstell and rbs. I tried disabling use of other fonts and setting Monotype Times New Roman (the MS Times New Roman font) as my default font and I still see the "--". I refuse to believe that that font does not have an em-dash char. :) Oh, — and — render identically, so that's good. As for &rsquot; that looks like glyph substitution kicking in....

mid-air.... resending to layout.

it could be related to the "early transliterator" added as for bug 33162 in which case the single char "--" would be coming from the substitute font. would you try setting "font.allow_double_byte_special_chars" to false in unix.js

yup. That "fixed" the em-dash problem. With that pref set it looks like an en-dash again.

can we find out which font the em-dash should be coming from?

Verdana is the font on the page. But if I disable the page's fonts, then it would be Monotype Times New Roman or Adobe Times (the two I have tested). Or am I answering the wrong question? :)

Lloyd Wood wrote: > How do I find out what font these chars are in? make a minimal html page (just the one char) Turn off the early transliterator: in unix.js set pref("font.allow_double_byte_special_chars", false); Get the font debug output: set the environment variable NS_FONT_DEBUG=5, do a minimal run (eg: ./mozilla file:///some_dir/test_file.html), capture moz's output, and attach it to this bug

I've attached mozilla's font output for the page http://www.alistapart.com/stories/typography/ following bstell's instructions. Haven't attempted to simplify the page; since the missized apostrophe (from glyph substitution?) is a result of stylesheet choices, it would seem best to compare this output with similar output from someone seeing what the 'screenshot from current CVS, Linux' gif shows... The page offers 'Use stylesheet -> none/friendly fonts', since it loads in /print.css and /friendly.css. The missized apostrophes are visible with 'none'; selecting 'friendly fonts' increases the size of the rest of the text to better match the large apostrophes, but e.g. spacing around the apostrophe is still messed up, helping to indicate the mismatch. Note that I'm still seeing the apostrophe problem even though the page source has since been altered to use unicode representations rather than the original (amp)rsquo;. Looks like rsquo; and the unicode equivalent are rendered identically. [page last modified Friday 26 October 5:55pm british summer time.] Current dates on the stylesheets are: $ lynx -head http://www.alistapart.com/print.css HTTP/1.1 200 OK Date: Tue, 30 Oct 2001 13:33:56 GMT Server: Apache/1.3.20 (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6b PHP/4.0.6 Last-Modified: Fri, 26 Oct 2001 16:53:24 GMT ETag: "52d790-64-3bd99504" Accept-Ranges: bytes Content-Length: 100 Connection: close Content-Type: text/css $ lynx -head http://www.alistapart.com/friendly.css HTTP/1.1 200 OK Date: Tue, 30 Oct 2001 13:32:53 GMT Server: Apache/1.3.20 (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6b PHP/4.0.6 Last-Modified: Fri, 26 Oct 2001 16:53:01 GMT ETag: "52d706-4e-3bd994ed" Accept-Ranges: bytes Content-Length: 78 Connection: close Content-Type: text/css so designers seem to have been fiddling but have fortunately not affected the bug. L.

I've attached png screenshots showing the alistapart page currently (mozilla prefs/env as suggested by bstell), under both stylesheet settings; none and friendly.

I realize these are an attempt help but neither of these attachments provide the information needed for solving this problem (they merely restate the problem). make a minimal html page (just the one char) Turn off the early transliterator: in unix.js set pref("font.allow_double_byte_special_chars", false); Get the font debug output: set the environment variable NS_FONT_DEBUG=5, do a minimal run (eg: ./mozilla file:///some_dir/test_file.html), capture moz's output, and attach it to this bug

what constitutes a minimal html page in this context? what stylesheets should the page reference? and how do you know the problem is not stylesheet related? Apart from the 'one char' html page, I followed your instructions exactly to get the mozilla font information (the first of three attachments) I attached. use of 'neither' indicates that you are referring to two attachments. note that I attached THREE attachments, only two of which are screenshots. please advise.

Here is were the right single quote is found: > FindFont(/0x2019), nsFontMetricsGTK.cpp 4013 > ... > iso8859-13 ffre = *-*-iso8859-13, nsFontMetricsGTK.cpp 3982 > TryNodes aFFREName = *-*-iso8859-13, nsFontMetricsGTK.cpp 3382 > load font misc-fixed-iso8859-13, nsFontMetricsGTK.cpp 2888 Humm, it makes me nervous to consider add a iso8859-13 font early. Does the right single quote in misc-fixed-...-iso8859-13 look good? How do the other special chars in that font look?

bstell has moved this from 0.98 to future. Since I can't find out exactly what I need to do to help further (cut-and-paste code and descriptions of code I'll never look at are not meaningful - the evangelism bug week's a failure if you ask me) recording final mails on the offchance they help someone else with this. defaulting to iso8859-13 is just weird for this -1 user. L. Date: Wed, 31 Oct 2001 11:24:32 -0800 From: Brian Stell <bstell@netscape.com> To: Lloyd Wood <L.Wood@eim.surrey.ac.uk> Subject: Re: [Bug 105703] display problems with em-dashes and apostrophes (representations) By the time the code gets here it has already looked for a font with same family name for these glyphs and failed. It has also already looked for a font in the same language group (as the document) for these glyphs and failed. The code is about to look at all the fonts that are selected in user prefs (the font dialog) for these glyphs on the assumption that the user likes these fonts. If this is a single byte doc (western) we want to avoid the big glyphs in CJK (eg: JISX0208) glyphs. For western docs the code adds an "early" transliterator to prevent the CJK glyphs from being used. This early tranliterator works by subsituting other ascii chars for these special chars; eg: "(TM)" for trademark, reqular double quote for smart quotes, etc. To get the non-tranliterated glyphs there is a hack to add some other fonts just before the early transliterator. This hack overrides the user font prefs but this seems like a somewhat minor override since we have already tried and failed to get a font with the right name or language group. We have to be careful that in getting these special chars we do not also get some other ugly chars. So, will we like the glyphs from an iso8859-13 font? Since there is always an ascii font at the head of the list we know that the 0-127 chars will come from the iso8895-1 font. The 128-255 glyphs (most likely) will come from this iso8859-13 font. Is this a good thing to do? ie: do the glyphs in the 128-255 range for the iso8859-13 font look good? Lloyd Wood wrote: > > This is with double-byte disabled unix.js setting as before? > unicode representation? > plain html file with nothing else? > just a screenshot to see how they look, right? > > L. Date: Wed, 31 Oct 2001 19:36:22 +0000 (GMT) From: Lloyd Wood <eep1lw@eim.surrey.ac.uk> Reply-To: Lloyd Wood <L.Wood@eim.surrey.ac.uk> To: Brian Stell <bstell@netscape.com> Subject: Re: [Bug 105703] display problems with em-dashes and apostrophes (representations) On Wed, 31 Oct 2001, Brian Stell wrote: > Is this a good thing to do? ie: do the glyphs in the 128-255 > range for the iso8859-13 font look good? I see you didn't answer my questions. No point explaining to me how mozilla code works; my attention span is already fully taken up with code I am responsible for, which thankfully has nothing to do with unicode and likely never will. I'm interested in helping provide enough information to enable you to improve the rendering while I am still able to do so. Can you answer yes/no to the questions? > Lloyd Wood wrote: > > > > This is with double-byte disabled unix.js setting as before? > > unicode representation? > > plain html file with nothing else? > > just a screenshot to see how they look, right? > > > > L. > > > > On Wed, 31 Oct 2001, Brian Stell wrote: > > > > > Date: Wed, 31 Oct 2001 10:39:16 -0800 > > > From: Brian Stell <bstell@netscape.com> > > > To: Lloyd Wood <L.Wood@eim.surrey.ac.uk> > > > Subject: Re: [Bug 105703] display problems with em-dashes and apostrophes > > > (representations) > > > > > > > > > > > > Lloyd Wood wrote: > > > > ... > > > > What special characters do you want to know about? > > > > > > > > Please be specific. > > > > > > http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#605 > > > 605 // > > > 606 // smart quotes (and other special chars) in Asian (double byte) > > > 607 // fonts are too large to use is western fonts. > > > 608 // Here we define those characters. > > > 609 // > > > 610 static PRUnichar gDoubleByteSpecialChars[] = { > > > 611 0x0152, 0x0153, 0x0160, 0x0161, 0x0178, 0x017D, 0x017E, 0x0192, > > > 612 0x02C6, 0x02DC, 0x2013, 0x2014, 0x2018, 0x2019, 0x201A, 0x201C, > > > 613 0x201D, 0x201E, 0x2020, 0x2021, 0x2022, 0x2026, 0x2030, 0x2039, > > > 614 0x203A, 0x20AC, 0x2122, > > > 615 0 > > > 616 }; > > > > > > > <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

Lloyd Wood wrote: > No point explaining to me how mozilla code works ... ... > defaulting to iso8859-13 is just weird for this -1 user There are techinal issues regarding displaying characters than are not in the specified font.

> There are techinal issues regarding displaying characters than are not in the > specified font. ...that you think aren't in the specified font, which strikes me as a slightly different (and possibly incorrect) thing. Skip the technical issues, and just clearly and unambiguously detail the steps needing to be done to get the info you need. I have been asking questions about those steps because of this ambiguity. $ How do the other special chars in that font look? how do I show you how they look? expand. explain. clarify. L.

Lloyd: Let's put some things in perspective: 1) This is a very minor issue. All the text is displayed and readable. This is about polish; eg: which glyph is used to display an em-dash. 2) I have other serious bugs where the text is not readable. These are the areas where I should be spending my time. 3) Even though this is a minor bug I have tried to give it some attention when I found spare moments. 4) I have found my discussions with you to be acrimonious and rather than continuing until things get really hot I have decided to back away from this very minor bug for now.

> 4) I have found my discussions with you to be acrimonious and rather than > continuing until things get really hot I have decided to back away from > this very minor bug for now. funny, that's _exactly_ why I dumped your emails into bugzilla. Your attempting to discuss code doesn't get us anywhere. I just wanted clear instructions on what I need to do to provide further information. > Does the right single quote in misc-fixed-...-iso8859-13 look good? I don't know. How do I find out and show you? > How do the other special chars in that font look? I don't know. How do I find out and show you? (I'm reasonably sure it's not by reading some C++ file in seamonkey.) L.

I't really not clear to me how you think you can help when you refuse to understand the problem. I really don't have any more time at the present waste on this.

> I't really not clear to me how you think you can help when you refuse to > understand the problem. by following clear, precise instructions to provide useful information. Understanding the problem is _your_ problem. > I really don't have any more time at the present waste on this. likewise.

> > I't really not clear to me how you think you can help when you refuse to > > understand the problem. > > by following clear, precise instructions to provide useful information. For a while I did that with you but you seem to have issues following directions. > Understanding the problem is _your_ problem. Do you normally find it successful to take an adversarial position when asking someone to work on something for you?

>> > > I't really not clear to me how you think you can help when you refuse to >> > > understand the problem. >> > >> > by following clear, precise instructions to provide useful information. >> >> For a while I did that with you clear and precise? 'minimal html page'? 'do the glyphs in the 128-255 range for the iso8859-13 font look good?' >> but you seem to have issues following directions. I requested clarifications by email and in bugzilla. You're not willing to spend the time to answer yes/no to a quick set of 'do you mean _this_?' questions, but you're happy to spend the time to get the last word on record in bugzilla. Odd, that. > > Understanding the problem is _your_ problem. > > Do you normally find it successful to take an adversarial position when > asking someone to work on something for you? that certainly seems to be working for you, and I presume you're representative of Mozilla's spread-the-bugwork approach as a whole. If anyone else is still paying attention: provide instructions and I'll be able to provide debugs/screenshots for the next week or so, after which the machine and configuration conveniently showing this are, alas, scheduled to become history. thanks, L. so, is there a list of top ten flamewar bugs, or what?

Lloyd: I'm tired of your hostility. You need to find someone else to work with on this. There is so much hostility in this particular bug that it clouds the issue. As such I am closing this bug. You are free to open a new bug if you do leave me out.

Further investigation of this is in bug 108321. > do the glyphs in the 128-255 range for the iso8859-13 font look good? I suspect you may have meant 'do the glyphs in the 128-255 range look good when the iso8859-13 font encoding is selected?'. font != font encoding. L. has never had iso8859-13 fonts installed.