Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 6451 - Should change Japanese fonts to display Japanese characters
: Should change Japanese fonts to display Japanese characters
Product: Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: PowerPC Mac System 8.5
: P3 major (vote)
: M12
Assigned To: Frank Tang
: Teruko Kobayashi
: Axel Hecht [:Pike]
Depends on:
Blocks: 7228
  Show dependency treegraph
Reported: 1999-05-14 14:56 PDT by Teruko Kobayashi
Modified: 2000-02-04 12:01 PST (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Teruko Kobayashi 1999-05-14 14:56:51 PDT
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.
Comment 1 Frank Tang 1999-05-18 17:14:59 PDT
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.
Comment 2 Peter Linss 1999-08-05 11:07:59 PDT
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
Comment 3 Frank Tang 1999-08-06 12:26:59 PDT
peterl: Could you put down more details about your previous comment ?
Comment 4 Peter Linss 1999-08-06 16:01:59 PDT
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.
Comment 5 Erik van der Poel 1999-08-09 17:14:59 PDT
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...
Comment 6 Frank Tang 1999-09-17 12:12:59 PDT
move to M12. No time to work on Mac for M11
Comment 7 Frank Tang 1999-12-17 15:06:59 PST
Mark it as M12 fix. I forget to mark it fixed when I check in the code 1 week
Comment 8 Teruko Kobayashi 2000-02-04 12:01:37 PST
I verified this in 2000020315 Mac build.

Note You need to log in before you can comment on or make changes to this bug.