6451 - Should change Japanese fonts to display Japanese characters

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[Teruko Kobayashi]

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]

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]

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).

Comment 3

[Frank Tang]

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

Comment 4

[Peter Linss]

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]

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]

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

Comment 7

[Frank Tang]

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

Comment 8

[Teruko Kobayashi]

I verified this in 2000020315 Mac build.