Tested 5-13-99 Mac build. In the Mac build, the Japanse characers are not displayed clearly. The font for Japanese character display is not good.

Peterl: We need the document character set information in the nsFont to do this right. Please hook up code to pick the nsIDocument::GetDocumentCharset and pass that info to nsFont. After that, you can reassign this back to me and I will handle the rest of it. Could you do that by end of May ? If so , then I can make it to M7.

The nsFont should not contain charset information. This can be set in the rendering context instead (can be set once at the beginning of a paint operation).

peterl: Could you put down more details about your previous comment ?

My assertion is that it isn't the nsFont that needs charset and font information, also that nsFont does not have the right data locality to store this properly. The issue as I understand it, is that when text is actually rendered, the rendering code needs to know the charset and language of the *rendered text* in order to select the proper font given a list of font families (from nsFont). The actual font(s) used for a given set of families (eg: "times, arial, serif") can vary with the language and charset of the input text to be rendered. Rather than store charset and lang in the font, this information needs to be passed to the rendering code along with the nsFont and the input text. ie: you need to add SetLang/SetCharset methods to nsRenderingContext and call them as appropriate during text rendering. If the charset cannot vary between text nodes within a document (not sure if this is true given unicode entities) then the charset can simply be set once on the rendering context at the beginning of the paint operation rather than for each text node. Since a single nsFont instance can be used for multiple text nodes which can each have different languages (and possibly charsets), the nsFont is not the right place to store this info.

The charset does not change from element to element. There is a single charset for a whole document. Entities are irrelevant. The charset of a document is the character encoding used to transmit it over the wire. On the other hand, the language *can* change from element to element, though this is rare now, and probably will always be rather rare. Since nsFont does contain things that can change from element to element (e.g. size, weight, family), why can't we just add the language to the list of things that are stored in nsFont? Also, since we don't expect the language to vary much, wouldn't it be inefficient to call SetLang on RenderingContext for each element? Just some thoughts...

move to M12. No time to work on Mac for M11

Mark it as M12 fix. I forget to mark it fixed when I check in the code 1 week ago.

I verified this in 2000020315 Mac build.