382542 - Font entries need to depend on the style (Arabic characters not displayed in italic)

Status: RESOLVED FIXED

(Core :: Graphics, defect, P1)

Description

[Stuart Parmenter]

Given something like Arial with italic style the Windows font mapper creates a font with the Arial Italic font face.  We think we're using Arial and check its character set which is different than Arial's character set.  We need to tell which font we're actually using (or do the mapping ourselves early on) so that we can check the right character set.

Comment 1

[Damon Sicore (:damons)]

After discussing with Stuart, moving to B1.

Comment 2

[Stuart Parmenter]

you can also see this using the STIXNonUnicode fonts where they use a different PUA codepoint for each style (i.e. U+0E261-U+0E264 are all "stix-old style digit 0")

Comment 3

[Bahram Maravandi]

There is another example in google search using persian language interface

http://www.google.com/search?hl=fa&q=%D8%A8%D9%87%D8%B1%D8%A7%D9%85%E2%80%8C%D8%B4%D9%87%D8%B1&btnG=Search&lr=lang_en%7Clang_de%7Clang_fa

Comment 5

[Damon Sicore (:damons)]

Stuart, I heard a rumor you might be working on this.  How's it coming?

Comment 6

[Stuart Parmenter]

Hoping to have it done this week.  It can wait for RC1 imho.

Comment 7

[Stuart Parmenter]

Attachment: v0.6

this works.  it ends up adding a lot of font variations that we might not need to our font list.  i suspect this stinks up startup time a bit.  probably doesn't make much difference for Tp.

Comment 8

[Stuart Parmenter]

Attachment: v0.75

this works a lot better. still need to make pref font caches depend on style as well as move weight selection over to use this new code.

Comment 9

[Stuart Parmenter]

Attachment: v0.8

ok, this looks pretty good.  still need to make cached prefs depend on styles as well as take a look at the bad underline stuff as it looks to be calling FindFontEntry without a style still.

Comment 10

[Stuart Parmenter]

shifting to P1.  This needs to go in to beta 5 -- the patch is getting big.

Comment 11

[Stuart Parmenter]

Attachment: v1.0

Comment 12

[Stuart Parmenter]

Attachment: v1.05

fixes a problem with InitBadUnderlineList using FindFontEntry without a style.

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 310349 [details] [diff] [review]
v1.05

This doesn't look too scary; I gave a few comments over irc.  Make sure all reftests etc. pass?

Comment 14

[John Daggett (:jtd)]

Attachment: testcase, Arabic with synthetic bolding and italics

Arabic is rendered strangely in italics in some situations.  Times New Roman goes all hexen with italics applied.  Verdana, a font with no Arabic glyphs, switches fallback font *family* when italics are applied, looks very strange.  Prior to the patch, the hex boxes under italics would *always* occur, after the patch it only happens for certain fonts.

Not sure this is super important, italics is not a typographic style natural to Arabic, especially given the common tendency for Arabic glyphs to slant left in normal style faces.

Comment 15

[John Daggett (:jtd)]

Attachment: testcase, Hiragino Maru Gothic and MS Gothic problems

1. Copy Hiragino Maru Gothic Pro from a Mac system:

find /System/Library/Fonts/ -name "*Pro*.otf" -print
/System/Library/Fonts//ヒラギノ丸ゴ Pro W4.otf
/System/Library/Fonts//ヒラギノ明朝 Pro W3.otf
/System/Library/Fonts//ヒラギノ明朝 Pro W6.otf
/System/Library/Fonts//ヒラギノ角ゴ Pro W3.otf
/System/Library/Fonts//ヒラギノ角ゴ Pro W6.otf

The "Maru Gothic" face is the first one in the list above.

2. Run the attached testcase

Results:

- Hiragino Maru Gothic Pro doesn't bold until "bolder 5" 
==> should be bolder 1 and beyond

- Hiragino Maru Gothic Pro doesn't lighten until "lighter 4" 
==> should be lighter 1 and beyond

- MS Gothic *never* bolds at any weight!

FF2/Win renders correctly.

Note: this was tested after applying the fontselection.diff patch.

Comment 16

[John Daggett (:jtd)]

Attachment: screenshot, hiragino bolder lighter

Comment 17

[John Daggett (:jtd)]

Attachment: screenshot, ms gothic bold

Comment 18

[pal-moz]

regression ?

see http://forums.mozillazine.org/viewtopic.php?p=3301380#3301380

Comment 19

[Kemcy BEST]

Attachment: Screenshot concerning chinese fonts

Left:  bold fonts are displayed correctly
Right: bold fonts missing (in webpage contents & in tab names on tabbar)

Comment 20

[Stuart Parmenter]

Attachment: v1.0 (part 2)

This should fix all the problems that john daggett was seeing.  I've changed the search all fonts code to use the same code as everything else for selecting a font face from a family.  This will yield better results and fix john's problem.

I also fixed the bold problem he was seeing.  We should probably support synthetic bold when there are no other bold faces, but we can do that in another bug.

Comment 21

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 310523 [details] [diff] [review]
v1.0 (part 2)

Looks fine, get John to look at it also?

Comment 22

[Stuart Parmenter]

Attachment: v1.05 (part 2)

slight update to the previous patch

Comment 23

[John Daggett (:jtd)]

Comment on attachment 310635 [details] [diff] [review]
v1.05 (part 2)

Looks fine.

Comment 24

[pal-moz]

(In reply to comment #18)
> regression ?
> 
> see http://forums.mozillazine.org/viewtopic.php?p=3301380#3301380
> 

20080319_1911_firefox-3.0b5pre.en-US.win32.zip

not fixed.
bold is not bold.

Comment 25

[Stuart Parmenter]

Attachment: bold fix

This adds FontEntrys for fake bold items so we'll use 600 weight when we don't have anything better.

Comment 26

[pal-moz]

20080319_2244_firefox-3.0b5pre.en-US.win32.zip

fixed, thanks.

Comment 27

[pal-moz]

cause this ?

bug 424060
http://forums.mozillazine.org/viewtopic.php?p=3303247#3303247