Should change Japanese fonts to display Japanese characters

VERIFIED FIXED in M12

Status

()

Core
Internationalization
P3
major
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: Teruko Kobayashi, Assigned: Frank Tang)

Tracking

Trunk
PowerPC
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Target Milestone: M6
(Assignee)

Updated

19 years ago
Assignee: ftang → peterl
Target Milestone: M6 → M7
(Assignee)

Comment 1

19 years ago
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.

Updated

19 years ago
Blocks: 7228

Updated

18 years ago
Assignee: peterl → ftang
Status: ASSIGNED → NEW

Comment 2

18 years ago
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).
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 3

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

Comment 4

18 years ago
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

18 years ago
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...
(Assignee)

Updated

18 years ago
Target Milestone: M9 → M10
(Assignee)

Updated

18 years ago
Target Milestone: M10 → M11
(Assignee)

Comment 6

18 years ago
move to M12. No time to work on Mac for M11
(Assignee)

Updated

18 years ago
Target Milestone: M11 → M12
(Assignee)

Updated

18 years ago
Target Milestone: M12 → M13
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Target Milestone: M13 → M12
(Assignee)

Comment 7

18 years ago
Mark it as M12 fix. I forget to mark it fixed when I check in the code 1 week
ago.
(Reporter)

Comment 8

18 years ago
I verified this in 2000020315 Mac build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.