Closed Bug 1133318 Opened 9 years ago Closed 3 years ago

The symbol is rendered bad

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Version:
38 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: over68, Unassigned)

References

Details

(Whiteboard: likely invalid) 

When writing symbols ⊙＿⊙, the symbol on the right side falls back to MS PGothic font.

Testcase https://dl.dropboxusercontent.com/u/95157096/85f61cf7/q4isvvhmm3.html

Screenshot https://dl.dropboxusercontent.com/u/95157096/85f61cf7/7rhvgy1du9.png
I've found a similar problem here https://dl.dropboxusercontent.com/u/95157096/85f61cf7/tq6rw2j9ip.html.
Flags: needinfo?(jfkthame)
This bug occurs since the version 3.7a4pre (2010-03-16).

Screenshot https://dl.dropboxusercontent.com/u/95157096/85f61cf7/1le3um1ywx.png


http://hg.mozilla.org/mozilla-central/rev/050887c64183
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100316 Minefield/3.7a4pre
Build ID: 20100316165229

Triggered by:
	8ff6056308bd	Jonathan Kew — bug 502906 - part 3 - factor out Uniscribe and GDI shapers from Windows GDI font code. r=jdaggett
I'm not sure this is really a bug; it's just a result of how font matching and fallback works.

Note some points about the example here: ⊙ is the CIRCLED DOT OPERATOR from the Mathematical Operators block, which is classified as Script=Common (i.e., not associated with a specific writing system, but may be used within text of various scripts). So when we come to do font selection for the first ⊙, we default to treating it as a Latin-script character (not having seen anything to indicate otherwise), and use Latin-script font prefs. Most likely, we don't find this character in the default Latin font, so we then fall back to whatever the system offers, probably a default Symbol font. (I'm not currently on a Windows system to check more specifically.)

The ＿ character, in contrast, is FULLWIDTH LOW LINE, from the Half-width and Full-width Forms block (associated with Hiragana and Katakana). As such, this is considered to belong to Japanese script; it's a variant of the ASCII underscore (_) specifically for use in conjunction with Full-width Kana. And so we use the Japanese font prefs to select a font for it.

Then we come to the second ⊙. Remember that these math operators have Script=Common. So this character is included as part of the current script run, which is Japanese; there's no basis to treat it as anything else, really. And so it also has Japanese font prefs applied -- and it happens that the ⊙ glyph in the default Japanese font doesn't match very well with the Latin or default Symbol font we picked for the previous occurrence.

To avoid the problem, authors should specify fonts that are appropriate for the characters in their text, rather than relying on fallback; or they should avoid mixing characters from other scripts (particularly Japanese or Chinese, where the default fonts are likely to have very wide character coverage) into strings of arbitrary symbols purely for graphical effect, because of the side-effects this may have on font selection. Note that if the text is written as, for example,

  ⊙__⊙

using ASCII underscores instead of the fullwidth (Kana) character, such a problem is unlikely to arise as this will not appear to begin a Japanese-text run.
Flags: needinfo?(jfkthame)
FWIW, I can demonstrate a similar effect on Mac OS X with an example like

  data:text/html;charset=utf-8,✓東京✓

Here, the first checkmark renders in Lucida Grande, while the second renders in a Hiragino font as a result of the script property propagated from the preceding Japanese characters.
Component: General → Graphics
Component: Graphics → Layout: Text
Whiteboard: likely invalid

Testcase:

data:text/html;charset=utf-8,<!doctype html><p><span style="font-size:70px">&%23x2299;&%23xff3f;&%23x2299;

This bug has been fixed in bug 1659313.

Pushlog for fix range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=25eb83f06bdadf4226196b68fdb475a83ebd4649&tochange=fe1f580e78c1f07163d3e129a10fb8e8ff9c5f9f

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Depends on: 1659313
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.