364713 - [Cairo][regression] bold and italic not simulated for families that lack bold and/or italic faces

Status: VERIFIED FIXED

(Core :: Graphics, defect, P2)

Description

[Eiichi]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.9a2pre) Gecko/20061221 Camino/1.2+
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.9a2pre) Gecko/20061221 Camino/1.2+

Bold & Strong are displayed as fixed-font in Japanese.

Reproducible: Always




Test case coming soon.

Comment 1

[Eiichi]

Attachment: Test Case

Comment 2

[Eiichi]

Version 2006122202 (1.2+) fixed the problem that I said above, but <Bold> & <Strong> aren't displayed correctly, so change the Summary.

Comment 3

[Hiro]

WFM

Mac OS X 10.3.9
Version 2006122202 (1.2+)

Comment 4

[Eiichi]

Attachment: Screen shot of <http://www.tcp-net.ad.jp/danbo/?12222313> : Version 2006122122 (1.1a1+)

Comment 5

[Eiichi]

Attachment: Screen shot of <http://www.tcp-net.ad.jp/danbo/?12222313> : Version 2006122202 (1.2+)

Comment 6

[Stuart Morgan]

Is this really Camino-only, or is it a core bug that shows up in trunk Firefox as well?

Comment 7

[Hiro]

It reproduced. 
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a2pre) Gecko/20061222 Minefield/3.0a2pre

(In reply to comment #1)
> Created an attachment (id=249429) [edit]
> Test Case
> 

In the font specification of this test case, the problem did not reproduce. 
But the problem reproduced similarly when Japanese was included in this test case 
specifying it. 

And the treatment of a Japanese font is not perfect yet. (bug362665)

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I'm not sure if this might be bug 364678 or something else, so kicking to gfx:thebes but not confirming (someone who has a better clue, please confirm and have block the right bugs if warranted)....

Comment 9

[Eiichi]

Attachment: Test Case (included Japanese Fonts)

Comment 10

[Hiro]

Attachment: screen shot of Safari + Hiragino maru go

Comment 11

[Hiro]

Attachment: screen shot of Firefox20061222 + hiragino maru go

Comment 12

[Hiro]

Attachment: screen shot of Firefox20061222 + hiragino kaku go

Comment 13

[Hiro]

The display of the font is almost the same as the application for other Mac according to bug362665. 

Because "hiragino kaku go" and "hiragino min cyou" have the bold font, the bold display is an expectation. 

Comment 14

[Eiichi]

I set to use "Sans-serif" "Osaka" for the default font, but it doesn't seem to work.
Japanese fonts are displayed as "Hiragino Mincho".

Comment 15

[Eiichi]

Attachment: Screen shot

Screen shot of <http://www.starfleet.ac/~inu/link/>

Comment 16

[philippe (part-time)]

This is one of the issues from bug 362665. I build Minefield with the patch (v2.01) from bug 364678, and that fixes most issues.

Comment 17

[Eiichi]

So is this a duplicate of bug 364678?

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

confirming.

But your testcase is invalid...

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: testcase

Use this for valid HTML.
# But Safari doesn't work fine in this. The Safari cannot resolve the font families correctly. See this testcase with old gfx(e.g., fx2).

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

We can reproduce this bug with italic style too.

If the font family doesn't have the style, current cairo doesn't generate the style dynamically. See http://lxr.mozilla.org/mozilla/source/gfx/cairo/cairo/src/cairo-atsui-font.c#711

> 711     /* TODO - bold and italic text
> 712      *
> 713      * We could draw the text using ATSUI and get bold, italics
> 714      * etc. for free, but ATSUI does a lot of text layout work
> 715      * that we don't really need...
> 716      */

Vlad:

Should we change the cairo ourselves? I cannot find the bug in the bugzilla of cairo.

Comment 21

[philippe (part-time)]

(In reply to comment #19)
 
> Use this for valid HTML.
> # But Safari doesn't work fine in this. The Safari cannot resolve the font
> families correctly. See this testcase with old gfx(e.g., fx2).
> 

It is more difficult...
Safari (cocoa app) need 'Hiragino Kaku Gothic Pro' (or Hiragino Mincho Pro  for serif), Carbon based apps that use Atsui need ヒラギノ明朝 Pro or ヒラギノ角ゴ Pro ( full name according to FontBook.app - one can omit the W3 or W6): Opera 9, iCab 3.0. The same name is needed for old Gecko (using QuickDraw).

I noticed earlier on my Minefield build with the patch for bug 364678 that Gecko+Cairo only will recognise the Hiragino font in a stylesheet if I use the postscript name for Hiragino Mincho (HiraMinPro). I'll attach a test case next.

Comment 22

[philippe (part-time)]

Attachment: test case Mincho (serif)

The green paragraph is not displayed as Mincho (serif).

Comment 23

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

(In reply to comment #20)
> We can reproduce this bug with italic style too.
> 
> If the font family doesn't have the style, current cairo doesn't generate the
> style dynamically. See
> http://lxr.mozilla.org/mozilla/source/gfx/cairo/cairo/src/cairo-atsui-font.c#711
> 
> > 711     /* TODO - bold and italic text
> > 712      *
> > 713      * We could draw the text using ATSUI and get bold, italics
> > 714      * etc. for free, but ATSUI does a lot of text layout work
> > 715      * that we don't really need...
> > 716      */
> 
> Vlad:
> 
> Should we change the cairo ourselves? I cannot find the bug in the bugzilla of
> cairo.

I'm not sure what you mean; cairo isn't involved at all in our text layout/font selection.  We just give it a font id and a set of glyphs.  Synthesizing italic and the like from this would be pretty hard; I don't even know if ATSU can synthasize oblique and bold.  We should do more investigation, I guess...

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #23)
> I'm not sure what you mean; cairo isn't involved at all in our text layout/font
> selection.  We just give it a font id and a set of glyphs.  Synthesizing italic
> and the like from this would be pretty hard; I don't even know if ATSU can
> synthasize oblique and bold.  We should do more investigation, I guess...

The ATSU generates the bold/italic style if the font family doesn't have the bolder/italic style. The comment in cairo says it too. So, we need to send the style which we want. And cairo should honor the style. But there are 2 problem:

1. We cannot send the style to cairo.
2. Cairo is not using ATSU and is not generate the styles.

If cairo doesn't implement it until Fx3, this is a very big bug of Fx3 for CJK users... Therefore, we need to contact to the developers of cairo. But this bug is not filed in their bugzilla.

Comment 25

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

FYI.

http://www.devworld.apple.com/documentation/Carbon/Reference/ATSUI_Reference/Reference/reference.html#//apple_ref/doc/c_ref/kATSUQDBoldfaceTag
> Specifies a boldface text style. Text style attribute tags are included for compatibility with the Style type used by the QuickDraw function TextFace. If a font variant for this text style exists, ATSUI uses that variant. Otherwise, the variant is generated algorithmically. The associated value is of type Boolean and has a default value of false.

http://www.devworld.apple.com/documentation/Carbon/Reference/ATSUI_Reference/Reference/reference.html#//apple_ref/doc/c_ref/kATSUQDItalicTag
> Specifies an italic text style. Text style attribute tags are included for compatibility with the Style type used by the QuickDraw function TextFace. If a font variant for this text style exists, ATSUI uses that variant. Otherwise, the variant is generated. The associated value is of type Boolean and has a default value of false.

Comment 26

[OpenMacNews]

fwiw i'm seeing the same,

   "but <Bold> & <Strong> aren't displayed correctly"

in,

   Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a2pre) Gecko/2007012104 Minefield/3.0a2pre

the problem manifests on GMail screens ... but on other sites, bold/strong display correctly. iiuc, it's a matter of which font is displayed.

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

we should not take this bug in fx3 final.

Comment 28

[Brian Ewins]

Commenting from the cairo side... atsu will generate synthetic bold and italic for you (among other things) but its not as simple as passing the ATSUStyle along with the glyphs - the ATSU rendering functions that are capable of synthesis expect a textrun as input, not glyphs; it'd need changes in the public API of cairo. 

Synthetic bold, condensed and oblique (ie italic) are just matrix transforms though. It should be possible to achieve the desired effect by setting the font matrix?
http://www.cairographics.org/manual/cairo-Text.html#cairo-set-font-matrix
Synthetic bold generated this way is pretty ugly. The other way people achieve the effect, at smaller point sizes, is to render the same text again shifted one pixel.

Comment 29

[Mike Connor [:mconnor]]

punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.

Comment 33

[John Daggett (:jtd)]

I'm going to grab this, I think it is possibly related to some bugs I'm looking at now.  Scream if you're already investigating a solution for this.

Comment 34

[Michael Mullin]

Hi John

Im hoping we can collaborate on this bug, as I have been working on it for a class I am doing. I am brand spanking new to Mozilla code which is why I am so slow, but I do have some patches which help me in the debugging process, and will probably help others.

From my newbie perspective there are three options:
1) dont use cairo for rendering text (probably a heck of a lot of work)
and do ATSU text rendering ourselves
2) do work on cairo so that cairo renders ATSU (also a heck of a lot of work, but the best choice)
3) fake it with synthetic fonts. (I think its a bad choice, but easier)

Comment 35

[John Daggett (:jtd)]

Attachment: Webkit synthetic bolding of Futura

Using the testcase from 396083, rendered in Webkit latest build.

The top shows font-weight: 500, the bottom shows font-weight: 600.  On the screen weight 600 clearly seems "bolder" but this is simulated by drawing each glyph twice, the second time with a one pixel offset.

Comment 36

[John Daggett (:jtd)]

Attachment: Futura in FF2 and Opera 9.23

In FF2 we generated synthetic bold for weights 700 and higher.  Opera doesn't appear to do synthetic bolding.

Comment 37

[John Daggett (:jtd)]

I dug around in FF1.5 and Webkit code to find the pertinent tidbits of source.

Webkit does synthetic bolding by drawing text twice, the second time with a one pixel offset.

http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform/mac/FontDataMac.mm#L107

Oblique is done by drawing with a 14deg shear specified in the text transform:

http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform/mac/FontMac.mm#L119

In the FF 1.5 code it looks like we relied on the ability of QD to produce a synthetic bold font.  I think this is the code, I haven't tested to verify that this is the actual rendering path as there appear to be lots of DrawString methods floating around:

Requesting bold/italic fonts from ATSUI:
http://lxr.mozilla.org/mozilla1.7/source/gfx/src/mac/nsATSUIUtils.cpp#257

I would say the next step here is to write a small piece of test code that renders text in the same way as FF 1.5/2.0, using a font like Futura that doesn't have a bold face. (Note: double check this in FontBook if you've installed your own fonts or have apps that came with extra fonts).  Use Pixie if you need to get a close up, pixel-level view of the rendering.

Once we know exactly how we did synthetic bold before, we can figure out a way to add that in with the current code.  I think this is preferable compared to asking ATSUI to do the same thing for us, since we'll be able to make that work the same way when we move to CoreText in the future.

Comment 38

[philippe (part-time)]

(In reply to comment #36)
> 
> In FF2 we generated synthetic bold for weights 700 and higher.  Opera doesn't
> appear to do synthetic bolding.

Fwiw:
1. Opera 9.5 alpha now does synthetic bolding for Futura (and some other fonts, when no real bold is available)

2. FF2 was wrong regarding bold and font-weight 700. That was changed for Gecko 1.9, see
https://bugzilla.mozilla.org/show_bug.cgi?id=365613#c8

Comment 39

[John Daggett (:jtd)]

Attachment: Opera 9.5 synthetic bolding of Futura

Looks like Opera 9.5 does synthetic bolding by using a text transform with a slight xscale, something like 1.03.  Ick, doesn't look so great.

Comment 40

[Michael Mullin]

Attachment: Example of synthetic italics

This is a patch which has helped me understand the way fonts are rendered in trunk.  Its very dirty and just meant as an example of synthetic italics.

Comment 41

[Brian Ewins]

(In reply to comment #40)
> Created an attachment (id=285962) [details]
> Example of synthetic italics
> 
> This is a patch which has helped me understand the way fonts are rendered in
> trunk.  Its very dirty and just meant as an example of synthetic italics.
> 

You should be able to get this effect without adding new public api - just call cairo_set_font_matrix().

Comment 42

[Michael Mullin]

Attachment: Please look at me: I am ATSUI

I have been working on getting a text rendering with ATSUI.  I've managed to get text rendering with bold/italic however the layout is all screwed up.  I would like someone with more knowledge to take a look if they have the time please.

Comment 43

[Michael Mullin]

Attachment: The results of 289046

This is the results from rendering one of my slightly edited test cases. It shows the bolding/italicizing which is going on.

Comment 44

[Michael Mullin]

Comment on attachment 289046 [details] [diff] [review]
Please look at me: I am ATSUI

Hi, can you check this out?  I am trying to get ATSUI to do the work here.  Layout is bad, but thats why I am looking for help

Comment 45

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you, Michael.

And you should read our coding rules:
http://developer.mozilla.org/en/docs/Mozilla_Coding_Style_Guide

your if statement should be changed.

Comment 46

[John Daggett (:jtd)]

Mike, you should probably have Vlad take a look at this but off the top of my head I don't think creating ATSULayout objects for each text run is going to work performance wise.  We need to push this down into cairo somehow.  Also, the synthetic oblique is in the wrong direction.

Comment 47

[Michael Mullin]

Attachment: Does Synthetic bold/italic/oblique

Possible fix for italic/oblique/bold problems.

Comment 49

[John Daggett (:jtd)]

This patch (292539) looks like it's headed in the right direction.  Could you post what the results look like?  How does using the size matrix for bolding look at both small and large text sizes?

Comment 52

[Cody 'codeman38' Boisclair]

Is bug 409680 actually a duplicate of this? It involves fonts that *do* have an actual bold-italic version not rendering correctly, rather than synthesized bold and italic.

Comment 53

[Francesco Lodolo [:flod]]

Sorry to bother you but I don't understand why bug 409680 has been marked as a duplicate of this bug: as far as I know Arial (see last test case) has the styles for bold and italic.

Maybe the description of this bug should be changed to avoid other duplicates? Or 409680 wasn't a duplicate?

Comment 55

[:Gijs (out for now; he/him)]

This also affects the display of away states in the ChatZilla user list :-(

Comment 56

[Mike Shaver (:shaver emeritus)]

jdaggett: mmullin is back in school, I believe, so you probably want to spin a build yourself (try server?) to get examples of output.

Comment 57

[John Daggett (:jtd)]

(In reply to comment #56)
> jdaggett: mmullin is back in school, I believe, so you probably want to spin a
> build yourself (try server?) to get examples of output.

OK, I'm gonna grab this, although I won't be able to look at it until post-B3 freeze. 

Comment 59

[Shreevatsa R]

I have the following behaviour: 
Specifying a *size* (any size) for the font makes it not display the italics: http://pastebin.ca/918322 , but leaving out the size shows italics fine. (Bold works in both cases.)

This is OS X 10.4 with the sans-serif font set to Helvetica.

Is this the same bug, or should I file a new one?

Comment 60

[John Daggett (:jtd)]

(In reply to comment #59)
> I have the following behaviour: 
> Specifying a *size* (any size) for the font makes it not display the italics:
> http://pastebin.ca/918322 , but leaving out the size shows italics fine. (Bold
> works in both cases.)
> 
> This is OS X 10.4 with the sans-serif font set to Helvetica.
> 
> Is this the same bug, or should I file a new one?

Assuming you're using a recent build of Firefox 3, yes, this is the same bug.  Helvetica has no italic face (use FontBook to confirm).  If you can come up with a testcase that shows italic where the font is Helvetica, please post it along with a screenshot and build version info.  Thanks!

Comment 61

[Shreevatsa R]

Yes, I'm using Firefox 3 Beta 3 (I should have mentioned). Helvetica does have an italic face, Helvetica Oblique [ #395886 and #396002 but you know about it already :) ]. I do not understand why specifying the font size in the CSS should affect it, it's presumably the same font. (But it does, see comment/pastebin.) But if you say so, it must be the same bug, consider my example as one more testcase to help with the debugging, then :)

Comment 62

[John Daggett (:jtd)]

Attachment: simple testcase using Tahoma (synthetic italics)

Comment 64

[John Daggett (:jtd)]

Attachment: patch, v.0.2, update of mmullin patch

Simplified a bit.  Both bold and oblique are done by swizzling the font matrix.  Need to do the correct weight calculation (e.g. 898).

Comment 65

[philippe (part-time)]

(In reply to comment #64)
> Created an attachment (id=306456) [details]
> patch, v.0.2, update of mmullin patch
> 
> Simplified a bit.  Both bold and oblique are done by swizzling the font matrix.
>  Need to do the correct weight calculation (e.g. 898).

That work pretty well, so far. On 10.5.2.
BUT
font-weight:lighter; gives very weird results: slanting/italicizing the text for all fonts.

[hmm, and Helvetica Neue doesn't show font-weight:100 correctly (Ultra-light face not used) - but that doesn't seem a regression form this patch, maybe  something from bug 411891, I never really tested that one since you fixed it].

Comment 66

[philippe (part-time)]

Attachment: screenshot for comment 65

from testcase attachment.cgi?id=297512 in bug 411891.

(in the same testcase, you can see that Helvetica Neue, font-weight 100; is not correct on 10.5.2)

Comment 67

[John Daggett (:jtd)]

(In reply to comment #65)

> That work pretty well, so far. On 10.5.2. BUT
> font-weight:lighter; gives very weird results: slanting/italicizing the text
> for all fonts.

Yeah, I'm seeing that also on 10.4, I'm debugging that now.

> [hmm, and Helvetica Neue doesn't show font-weight:100 correctly (Ultra-light
> face not used) - but that doesn't seem a regression form this patch, maybe 
> something from bug 411891, I never really tested that one since you fixed it].

I'll check this.

Comment 68

[John Daggett (:jtd)]

Attachment: testcase, various fonts lacking either italic or bold faces

Comment 69

[philippe (part-time)]

John, I saw another combination, same issue:
<p class="headline"><strong><a href>xxx</a>

.headline {font-weight:bold; /* other rules */}
(Geneva is the used font, according to Firebug)

on http://www.japantimes.co.jp/
towards the top, a grey box on the right (Editor's choice).

Comment 70

[John Daggett (:jtd)]

Attachment: testcase, various fonts lacking either italic or bold faces

Fixup tiny js error!

Comment 71

[John Daggett (:jtd)]

Attachment: patch, v.0.3, fix up the weight handling and adjust advances

This is probably closer to what mmullin intended, synthetic oblique is done with an x-skew, bolding is done with an x-scale.  The obliquing seems fine, the bold doesn't look bold, just expanded.

Two other ways:

1. double-striking (WebKit does this)
2. adding a stroke width (example of this included in Apple dev examples)

Handling lighter/bolder is a bit tricky with this code, there are times when it's hard to decide whether to bold or not.  For example, with a font family containing faces with weights 100, 400 only, a style weight of 101 should not be bold but a style weight of 102 should be (these correspond to nested elements with 'bolder' applied).  Probably not a common occurance but something to consider for fun and amusement...

Comment 72

[John Daggett (:jtd)]

Attachment: screenshot, Helvetica in FF2 vs. FF3 with patch v.0.3

Comment 73

[John Daggett (:jtd)]

Attachment: screenshot, MS Gothic in FF2 vs. FF3 with patch v.0.3

Comment 74

[philippe (part-time)]

Attachment: screenshot (patch v.0.3

Gecko is on the left, WebKit on the right.
With patch v.0.3, the artificial bolding causes the textrun to overflow/run out of its bounding box. Look at the underline (text-decoration) or the background on the italic lines.

Geneva is used in the screenshot, but any font that needs artificial bolding is affected.

The italics look good for most fonts I could test. The bold is a bit too light.

Comment 75

[John Daggett (:jtd)]

Attachment: patch, v.0.4, bolding by double strike

Italic via cairo font matrix, bold by drawing glyphs a second time with a one-pixel offset.  Still need to figure out how to adjust bounding box and catch the case where an RGBA color with A != 1 is involved.

Comment 76

[John Daggett (:jtd)]

Attachment: Futura waterfall, normal/bold vs. Safari

Safari adds a per-character 1-pixel advance, I don't think that's needed.

Comment 77

[John Daggett (:jtd)]

Attachment: small bolded text, FF3, FF2 and Safari

FF3 (top left) and FF2 (top right) display is hard to read, Safari (bottom) is readable.  Probably need to consider adding advance at smaller sizes, argh.

Comment 78

[John Daggett (:jtd)]

Attachment: testcase, various fonts lacking either italic or bold faces with waterfall

Comment 79

[John Daggett (:jtd)]

Attachment: testcase, synthetic bolding with hsla colored text

Uses canvas mozText to draw a text with different hsla colors.  Fonts used are Futura (no bold face), Hiragino Maru Gothic Pro (no bold face), Helvetica Neue (has bold face).

With the latest patch (v.0.4), text changes color when bolded.  Scroll down to the section for alpha = 0.4 to see this more clearly.

Comment 80

[John Daggett (:jtd)]

Attachment: screenshot, double-striked bold changes text color

Comment 81

[John Daggett (:jtd)]

Attachment: screenshot, closeup of text color changes

Shows text with and without bolding.  Fonts are Futura, Hiragino Maru Gothic Pro and Helvetica Neue, from left to right.

Comment 82

[philippe (part-time)]

(In reply to comment #79)
> Created an attachment (id=307856) [details]
> testcase, synthetic bolding with hsla colored text
> 
> Uses canvas mozText to draw a text with different hsla colors.  Fonts used are
> Futura (no bold face), Hiragino Maru Gothic Pro (no bold face), Helvetica Neue
> (has bold face).
> 
> With the latest patch (v.0.4), text changes color when bolded.  Scroll down to
> the section for alpha = 0.4 to see this more clearly.
> 

Fwiw, WebKit (latest build) does the same: bolded text is darker than the non-bold text.
(I had to make a static test file, WebKit doesn't like your canvas testcase).

My (Camino) build with patch v.0.4 works pretty well BTW

Comment 83

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

Are we doing the fake-bold or is atsui?  That's fine for now, though it should be an easy fix -- we just need to recognize if we're doing fake bold, and if so, draw without alpha into a surface group/layer and composite with the appropriate alpha.  I'd file a separate bug on that for fixing in 1.9.0.x.

Comment 84

[John Daggett (:jtd)]

Attachment: patch, v.0.5, bolding by double strike with correct alpha color handling

Handle alpha-colored text by buffering all drawing, drawing with solid color and compositing the result using the alpha value.

Vlad, could you look this over quickly?  I just want to verify that this looks like it's on the right path...

Still need to adjust metrics ever so slightly in the bold case.  Not sure anything is needed in the oblique case, although it might be possible for trailing glyphs to exceed the bounds box.

Comment 85

[John Daggett (:jtd)]

Attachment: patch, v.0.5a, bolding by double strike with correct alpha color handling

argh, fix typo

Comment 86

[John Daggett (:jtd)]

Attachment: testcase, synthetic bolding with hsla colored text, no canvas, works in Safari

Comment 87

[John Daggett (:jtd)]

Attachment: screenshot, double-striked bold with correct color

"Basically" correct, I'm seeing off-by-1 differences in the RGB values (color with alpha vs. opacity blit path differences)

Comment 88

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

I'm not super excited by using a helper object here, given that it's in a critical path.  Instead of doing the work in the helper object's constructor/destructor, maybe add Init() and Flush() methods, and do the opaque color source check in the Draw method?  That way you could just avoid calling Init() entirely; same thing with Flush().  (Flush() in general would be better -- you don't really want to do drawing from a destructor.)  One thing is that I'm pretty sure subpixel AA will be wrong for this case, but I'm not sure if subpixel AA ever comes into play for non-opaque text anyway on the mac.

Comment 89

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

John-san:

Should you modify the widths of each bolden glyphs?

Comment 90

[John Daggett (:jtd)]

Attachment: testcase, svg synthetic bolding with hsla colored text along a path

Wee, pretty sprial...

The first part of each phrase is bolded, the second half is not.  Colors should not change within a phrase when switching from bold to regular.

Comment 91

[John Daggett (:jtd)]

Attachment: patch, v.0.6, bolding by double strike with correct alpha color handling

Based on Vlad's comments, restructured code, it's probably a bit simpler now, the functionality is the same as the last patch.

Testing with text on a path in SVG, the code draws correctly but it's slow as mud.  The code in nsSVGGlyphFrame::LoopCharacters calls the textrun Draw method one character at a time without a dirty rect, pigfart.  This means the code is drawing into a buffer the size of the frame and compositing it in *every single character*!!  Need to add in code to calculate extents.

Comment 92

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Should the SVG text-along-a-path code handle transparent colors itself, by pushing a group for the whole string? What is the defined rendering for self-intersecting text-on-path?

Comment 93

[Robert O'Callahan (:roc) (email my personal email if necessary)]

For that matter, what is the defined rendering for SVG text with explicit glyph positions where the glyphs overlap one another?

Comment 94

[John Daggett (:jtd)]

Attachment: testcase, intersecting curves and text along a path

(In reply to comment #92)
> Should the SVG text-along-a-path code handle transparent colors itself, by
> pushing a group for the whole string? What is the defined rendering for
> self-intersecting text-on-path?

Seems like it should be consistent with self-intersecting paths, which draw with a single color for the entire path.  Text along a path draws each glyph as if it was a seperate object, intersections between glyphs or self-intersections cause double blending to occur.

Comment 95

[John Daggett (:jtd)]

Attachment: screenshot, intersecting curves and text along a path

Comment 96

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK, what about self-intersecting text containing a span in a different color with a different opacity level? :-)

Comment 99

[Ted Pavlic]

(In reply to comment #97)
> *** Bug 422143 has been marked as a duplicate of this bug. ***
> 

As discussed in that page, italics do not display in OS/X (at least 10.4) on WikiMedia style sheets. That is, they display upright. For example, from WikiPedia:

http://en.wikipedia.org/wiki/User:TedPavlic/Sandbox/Firefox3Beta3and4ItalicsTest

You can find that style sheet at:

http://en.wikipedia.org/wiki/MediaWiki:Common.css

Comment 100

[Ted Pavlic]

> You can find that style sheet at:
> 
> http://en.wikipedia.org/wiki/MediaWiki:Common.css

Changing the Sans-serif font from the default "Helvetica" to "Helvetica Neue" (which has italics) fixes the problem.

Comment 101

[John Daggett (:jtd)]

Attachment: patch, v.0.9, bolding via double strike

This should be fairly close to the final patch.  I still need to figure out how to adjust the width of the text run, since double-striking will draw 1-pixel beyond the extents of the non-bolded text.

In this version, a boolean is passed around when selecting weights to identify relative weights (bolder/lighter) couldn't be completely resolved with the existing font faces.  This makes bolder/lighter handling consistent, no matter what the assortment of weights available are.

Vlad, let me know if you think the code in gfxTextRun::Draw looks ok.

Comment 102

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

Comment on attachment 309067 [details] [diff] [review]
patch, v.0.9, bolding via double strike

Yep, looks fine.

Comment 103

[John Daggett (:jtd)]

Attachment: screenshot, bolding with double strike, two pixel offset

When bolding by drawing text twice, at larger sizes (>36pt) the bolding is hard to distinguish from non-bolded text.  Masayaki and Simon mentioned on IRC that it might be better to draw with a two-pixel offset at larger sizes.  This screenshot shows the problem with doing this, the two-pixel offset introduces nasty artifacts  at sharply mitred inflection points, the "w" in weight for Futura, or the "c" for Futura or Gothic-style faces for Japanese text.  It also results in an ugly balance within the ukanmuri radical at the top of the third character in "tonari no kyaku", the horizontal line is distinctly thinner than the short vertical segments at either end.

If we want to do triple-striking for larger sizes, that might be one way to work around the artifacts problem but in general I think it's better not to go too crazy trying to simulate boldness, both for performance reasons and because we really don't want to be ruining the efforts of font designers who spent a lot of time carefully designing the balance of their letterforms.

Comment 104

[John Daggett (:jtd)]

Attachment: testcase, waterfall tests for various scripts with fonts that lack bold or italic faces

Since we've decided to alter the advances in the synthetic bolding case, need to be sure to test with lots of different scripts.

Comment 105

[John Daggett (:jtd)]

Attachment: patch, v.1.0, bolding via double strike with advance

Synthetic bolding and obliqueing on the mac

- obliqueing by skewing via the font matrix (note bug 423607)
- bolding by double-striking with a 1px offset
- bolding occurs at weights 600 and greater
- bolder causes synthetic bolding beyond the boldest face available, no matter what the weight of that face
- lighter always disables synthetic bolding
- advance is increased by 1px at cluster/lig boundaries
- alpha colors render at the same color via buffered render
- at larger text sizes, bolding is very subtle
- tested 2px offset for larger sizes, rejected
- bolding for stroked text via SVG ignored (gfxTextRun::DrawToPath)
- tested with Japanese, Arabic, Devanagari, Thai, Hebrew, Korean, Chinese

Comment 106

[Adil Allawi]

I just tried the patch - maybe I am wrong or missing something - but isn't the synthetic italic meant to lean the opposite way? What I see is the text leaning to the left. For normal italic fonts text leans to the right.

Comment 107

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Adil, that's the bug referenced in comment 105:

> - obliqueing by skewing via the font matrix (note bug 423607)

Comment 108

[Adil Allawi]

Aha - I was missing something. One interesting side effect though - The italic for the Arabic looks much better with the italic angle to the left. I suppose that should go into a different bug report though.

Comment 109

[John Daggett (:jtd)]

(In reply to comment #105)
> Created an attachment (id=310245) [details]
> patch, v.1.0, bolding via double strike with advance

oops, left in a printf in gfxFont::Draw, will remove this in the final checkin

Comment 110

[John Daggett (:jtd)]

Attachment: patch, v.1.1, correct skew and remove printf

Together with Vlad, we decided that cairo is doing the right thing so i switched the sign of the skew factor so that synthetic italics lean right.

Comment 112

[John Daggett (:jtd)]

checked in yesterday.  confirmed duplicates.

This will be part of B5, yay!

Comment 113

[philippe (part-time)]

Thanks John !
It works nicely.

Comment 114

[Eiichi]

John, thanks a lot for your hard work.

Comment 115

[Chris Lawson (gone)]

Verified fixed with Camino trunk 2008032100. Thanks a bunch, John. I can finally use Wikipedia again without being horribly confused :)