linux: Add patterns for subpixel test to fonts.conf.

linux: Add patterns for subpixel test to fonts.conf.

This updates our layout test fontconfig settings to define
one font family that explicitly enables subpixel rendering
and one that disables it.  I'm using this in a test for a
change that fixes
https://bugs.webkit.org/show_bug.cgi?id=42220.

BUG=chromium-os:4638
TEST=upcoming

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=52562

[Evan Martin, 2010-07-14 22:21:56]

LGTM

http://codereview.chromium.org/2928011/diff/1/2
File webkit/tools/test_shell/resources/fonts.conf (right):

http://codereview.chromium.org/2928011/diff/1/2#newcode213
webkit/tools/test_shell/resources/fonts.conf:213: <const>rgb</const>
Isn't there another attr you need to specify for subpixel to apply?  Or is that
not relevant for your test anyway.

[Daniel Erat, 2010-07-14 22:28:13]

On Wed, Jul 14, 2010 at 3:21 PM,  <evan@chromium.org> wrote:
> LGTM
>
>
> http://codereview.chromium.org/2928011/diff/1/2
> File webkit/tools/test_shell/resources/fonts.conf (right):
>
> http://codereview.chromium.org/2928011/diff/1/2#newcode213
> webkit/tools/test_shell/resources/fonts.conf:213: <const>rgb</const>
> Isn't there another attr you need to specify for subpixel to apply?  Or
> is that not relevant for your test anyway.

I don't think that this is relevant to the WebKit code, but in Chrome
I believe that we ignore the subpixel settings if hinting is disabled.
 The current defaults seem to be reasonable here (that is, I'm getting
hinted text without specifying it in the config), and the other tests
appear to depend on this being the case, so I didn't bother manually
enabling antialiasing, hinting, and setting a hintstyle... I can do so
if you think it'd be safer, though.  Maybe I should set defaults for
all this stuff explicitly at the top level of the config?

> http://codereview.chromium.org/2928011/show
>

[Daniel Erat, 2010-07-15 00:36:25]

On Wed, Jul 14, 2010 at 3:27 PM, Daniel Erat <derat@chromium.org> wrote:
> On Wed, Jul 14, 2010 at 3:21 PM,  <evan@chromium.org> wrote:
>> LGTM
>>
>> http://codereview.chromium.org/2928011/diff/1/2
>> File webkit/tools/test_shell/resources/fonts.conf (right):
>>
>> http://codereview.chromium.org/2928011/diff/1/2#newcode213
>> webkit/tools/test_shell/resources/fonts.conf:213: <const>rgb</const>
>> Isn't there another attr you need to specify for subpixel to apply?  Or
>> is that not relevant for your test anyway.
>
> I don't think that this is relevant to the WebKit code, but in Chrome
> I believe that we ignore the subpixel settings if hinting is disabled.
>  The current defaults seem to be reasonable here (that is, I'm getting
> hinted text without specifying it in the config), and the other tests
> appear to depend on this being the case, so I didn't bother manually
> enabling antialiasing, hinting, and setting a hintstyle... I can do so
> if you think it'd be safer, though.  Maybe I should set defaults for
> all this stuff explicitly at the top level of the config?

The fontconfig documentation claims this:

"The initial pattern is modified by applying the list of editing
instructions specific to patterns found in the configuration; each
consists of a match predicate and a set of editing operations. They
are executed in the order they appeared in the configuration."

, but when I add a

<match target="font">
  <edit name="antialias" mode="assign"><bool>true</bool></edit>
</match>

stanza to the top of the file, it appears to override any later
matches; the "NonAntiAliasedSans" family is antialiased, for instance.
 Have you seen this before?

I guess I'll just check this in as-is after I manage to get it through
the buildbots.

>> http://codereview.chromium.org/2928011/show
>>
>

[Evan Martin, 2010-07-15 18:03:18]

On 2010/07/15 00:36:25, Daniel Erat wrote:
> The fontconfig documentation claims this:
> 
> "The initial pattern is modified by applying the list of editing
> instructions specific to patterns found in the configuration; each
> consists of a match predicate and a set of editing operations. They
> are executed in the order they appeared in the configuration."
> 
> , but when I add a
> 
> <match target="font">
>   <edit name="antialias" mode="assign"><bool>true</bool></edit>
> </match>
> 
> stanza to the top of the file, it appears to override any later
> matches; the "NonAntiAliasedSans" family is antialiased, for instance.
>  Have you seen this before?

I haven't, but I haven't fought with fontconfig much.

> I guess I'll just check this in as-is after I manage to get it through
> the buildbots.

Yes, that is a good course of action.