Closed
Bug 382542
Opened 17 years ago
Closed 16 years ago
Font entries need to depend on the style (Arabic characters not displayed in italic)
Categories
(Core :: Graphics, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla1.9beta5
People
(Reporter: pavlov, Assigned: pavlov)
References
()
Details
Attachments
(8 files, 5 obsolete files)
45.79 KB,
patch
|
vlad
:
review+
|
Details | Diff | Splinter Review |
3.54 KB,
text/html
|
Details | |
4.62 KB,
text/html
|
Details | |
70.40 KB,
image/png
|
Details | |
40.28 KB,
image/png
|
Details | |
42.20 KB,
image/png
|
Details | |
11.72 KB,
patch
|
pavlov
:
review+
jtd
:
superreview+
|
Details | Diff | Splinter Review |
6.37 KB,
patch
|
vlad
:
review+
|
Details | Diff | Splinter Review |
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.
Flags: blocking1.9+
Updated•17 years ago
|
Target Milestone: --- → mozilla1.9alpha6
Comment 1•17 years ago
|
||
After discussing with Stuart, moving to B1.
Target Milestone: mozilla1.9alpha6 → mozilla1.9beta1
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Updated•17 years ago
|
Priority: -- → P2
Target Milestone: mozilla1.9 M8 → ---
Updated•17 years ago
|
Summary: Font entries need to depend on the style → Font entries need to depend on the style (Arabic characters not displayed in italic)
Assignee | ||
Comment 2•17 years ago
|
||
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•17 years ago
|
||
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
Assignee | ||
Updated•17 years ago
|
Priority: P2 → P1
Comment 5•17 years ago
|
||
Stuart, I heard a rumor you might be working on this. How's it coming?
Assignee | ||
Comment 6•17 years ago
|
||
Hoping to have it done this week. It can wait for RC1 imho.
Assignee | ||
Updated•17 years ago
|
Priority: P1 → P2
Assignee | ||
Updated•17 years ago
|
Flags: tracking1.9+ → blocking1.9+
Assignee | ||
Comment 7•16 years ago
|
||
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.
Assignee | ||
Comment 8•16 years ago
|
||
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.
Attachment #310082 -
Attachment is obsolete: true
Assignee | ||
Comment 9•16 years ago
|
||
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.
Attachment #310165 -
Attachment is obsolete: true
Assignee | ||
Comment 10•16 years ago
|
||
shifting to P1. This needs to go in to beta 5 -- the patch is getting big.
Priority: P2 → P1
Assignee | ||
Comment 11•16 years ago
|
||
Attachment #310199 -
Attachment is obsolete: true
Attachment #310341 -
Flags: review?(vladimir)
Assignee | ||
Comment 12•16 years ago
|
||
fixes a problem with InitBadUnderlineList using FindFontEntry without a style.
Attachment #310341 -
Attachment is obsolete: true
Attachment #310349 -
Flags: review?(vladimir)
Attachment #310341 -
Flags: review?(vladimir)
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?
Attachment #310349 -
Flags: review?(vladimir) → review+
Comment 14•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
Comment 17•16 years ago
|
||
Comment 18•16 years ago
|
||
regression ? see http://forums.mozillazine.org/viewtopic.php?p=3301380#3301380
Comment 19•16 years ago
|
||
Left: bold fonts are displayed correctly Right: bold fonts missing (in webpage contents & in tab names on tabbar)
Updated•16 years ago
|
Target Milestone: --- → mozilla1.9beta5
Assignee | ||
Comment 20•16 years ago
|
||
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.
Assignee | ||
Updated•16 years ago
|
Attachment #310523 -
Flags: review?(vladimir)
Comment on attachment 310523 [details] [diff] [review] v1.0 (part 2) Looks fine, get John to look at it also?
Attachment #310523 -
Flags: review?(vladimir) → review+
Assignee | ||
Comment 22•16 years ago
|
||
slight update to the previous patch
Attachment #310523 -
Attachment is obsolete: true
Attachment #310635 -
Flags: superreview?(jdaggett)
Attachment #310635 -
Flags: review+
Comment 23•16 years ago
|
||
Comment on attachment 310635 [details] [diff] [review] v1.05 (part 2) Looks fine.
Attachment #310635 -
Flags: superreview?(jdaggett) → superreview+
Assignee | ||
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 24•16 years ago
|
||
(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.
Assignee | ||
Comment 25•16 years ago
|
||
This adds FontEntrys for fake bold items so we'll use 600 weight when we don't have anything better.
Attachment #310687 -
Flags: review?(vladimir)
Attachment #310687 -
Flags: review?(vladimir) → review+
Comment 26•16 years ago
|
||
20080319_2244_firefox-3.0b5pre.en-US.win32.zip fixed, thanks.
Comment 27•16 years ago
|
||
cause this ? bug 424060 http://forums.mozillazine.org/viewtopic.php?p=3303247#3303247
You need to log in
before you can comment on or make changes to this bug.
Description
•