Fix matching Roboto Bold for src: local("Roboto Regular")

Fix matching Roboto Bold for src: local("Roboto Regular")

Our @font-face { src: local() } matching is incorrectly going down the
same code path that is used for matching CSS font-family. On Windows,
this family match code path takes extra steps to ensure something like
"Roboto Regular" is matched against Roboto, or "Roboto Bold" is matched
against Roboto, in a bold variant. However, this type of matching is too
wide for local(), where the CSS fonts module specification expects a
unique match against full font name or postscript name. On Windows, it
was incorrectly matching local("Roboto Regular") against "Roboto Bold"
if that was the only available Roboto font on the system.

This CL is a temporary fix for the case of "Roboto Regular" matching
against Roboto Bold. However, matching local("Roboto Bold") against the
actual Roboto Bold does still not work, also local("Roboto") still
matches against Roboto Bold if that is the only available Roboto on the
system. A full fix requires access to the OpenType name table and
reading the full font name or postscript name.

TEST=Manual, using src: local("Roboto"), local("Roboto Regular"),
     local("Roboto Bold") with only Roboto Bold installed on the system
BUG=690334
Review-Url: https://codereview.chromium.org/2721613002
Cr-Commit-Position: refs/heads/master@{#453600}
Committed: https://chromium.googlesource.com/chromium/src/+/d31bcba110520454ced012b05695f9c471446a52

[drott, 2017-02-27 15:24:42]

The CQ bit was checked by drott@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-27 15:25:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[drott, 2017-02-27 15:26:00]

drott@chromium.org changed reviewers:
+ eae@chromium.org, kojii@chromium.org

[drott, 2017-02-27 15:26:16]

Description was changed from

==========
Fix matching Roboto Bold for src: local("Roboto Regular")

Our @font-face { src: local() } matching is incorrectly going down the
same code path that is used for matching CSS font-family. On Windows,
this family match code path takes extra steps to ensure something like
"Roboto Regular" is matched against Roboto, or "Roboto Bold" is matched
against Roboto, in a bold variant. However, this type of matching is too
wide for local(), where the CSS fonts module specification expects a
unique match against full font name or postscript name. On Windows, it
was incorrectly matching local("Roboto Regular") against "Roboto Bold"
if that was the only available Roboto font on the system.

This CL is a temporary fix for the case of "Roboto Regular" matching
against Roboto Bold. However, matching local("Roboto Bold") against the
actual Roboto Bold does still not work, also local("Roboto") still
matches against Roboto Bold if that is the only available Roboto on the
system. A full fix requires access to the OpenType name table and
reading the full font name or postscript name.

TEST=Manula, using src: local("Roboto"), local("Roboto Regular"),
     local("Roboto Bold") with only Roboto Bold installed on the system
BUG=690334
==========

to

==========
Fix matching Roboto Bold for src: local("Roboto Regular")

Our @font-face { src: local() } matching is incorrectly going down the
same code path that is used for matching CSS font-family. On Windows,
this family match code path takes extra steps to ensure something like
"Roboto Regular" is matched against Roboto, or "Roboto Bold" is matched
against Roboto, in a bold variant. However, this type of matching is too
wide for local(), where the CSS fonts module specification expects a
unique match against full font name or postscript name. On Windows, it
was incorrectly matching local("Roboto Regular") against "Roboto Bold"
if that was the only available Roboto font on the system.

This CL is a temporary fix for the case of "Roboto Regular" matching
against Roboto Bold. However, matching local("Roboto Bold") against the
actual Roboto Bold does still not work, also local("Roboto") still
matches against Roboto Bold if that is the only available Roboto on the
system. A full fix requires access to the OpenType name table and
reading the full font name or postscript name.

TEST=Manual, using src: local("Roboto"), local("Roboto Regular"),
     local("Roboto Bold") with only Roboto Bold installed on the system
BUG=690334
==========

[commit-bot: I haz the power, 2017-02-27 19:28:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-27 19:28:27]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[eae, 2017-02-27 21:49:11]

LGTM, thank you

[drott, 2017-02-28 08:09:16]

The CQ bit was checked by drott@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-28 08:09:31]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-28 11:26:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-28 11:26:27]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[drott, 2017-02-28 11:41:46]

Fix test cases relying on generous matching for local()

[drott, 2017-02-28 11:41:47]

The CQ bit was checked by drott@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-28 11:42:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[drott, 2017-02-28 11:42:05]

The CQ bit was unchecked by drott@chromium.org

[drott, 2017-02-28 11:42:09]

The CQ bit was checked by drott@chromium.org

[drott, 2017-02-28 11:42:09]

The patchset sent to the CQ was uploaded after l-g-t-m from eae@chromium.org
Link to the patchset: https://codereview.chromium.org/2721613002/#ps40001
(title: "Fix test cases relying on generous matching for local()")

[commit-bot: I haz the power, 2017-02-28 11:42:14]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[drott, 2017-02-28 12:53:05]

Fix test case for Mac

[drott, 2017-02-28 12:53:14]

The CQ bit was checked by drott@chromium.org

[drott, 2017-02-28 12:53:14]

The patchset sent to the CQ was uploaded after l-g-t-m from eae@chromium.org
Link to the patchset: https://codereview.chromium.org/2721613002/#ps60001
(title: "Fix test case for Mac")

[commit-bot: I haz the power, 2017-02-28 12:53:23]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-28 14:57:29]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1488286394414640,
"parent_rev": "803cb96d3089cc214ee46062cf3759a13646b172", "commit_rev":
"d31bcba110520454ced012b05695f9c471446a52"}

[commit-bot: I haz the power, 2017-02-28 14:58:10]

Description was changed from

==========
Fix matching Roboto Bold for src: local("Roboto Regular")

Our @font-face { src: local() } matching is incorrectly going down the
same code path that is used for matching CSS font-family. On Windows,
this family match code path takes extra steps to ensure something like
"Roboto Regular" is matched against Roboto, or "Roboto Bold" is matched
against Roboto, in a bold variant. However, this type of matching is too
wide for local(), where the CSS fonts module specification expects a
unique match against full font name or postscript name. On Windows, it
was incorrectly matching local("Roboto Regular") against "Roboto Bold"
if that was the only available Roboto font on the system.

This CL is a temporary fix for the case of "Roboto Regular" matching
against Roboto Bold. However, matching local("Roboto Bold") against the
actual Roboto Bold does still not work, also local("Roboto") still
matches against Roboto Bold if that is the only available Roboto on the
system. A full fix requires access to the OpenType name table and
reading the full font name or postscript name.

TEST=Manual, using src: local("Roboto"), local("Roboto Regular"),
     local("Roboto Bold") with only Roboto Bold installed on the system
BUG=690334
==========

to

==========
Fix matching Roboto Bold for src: local("Roboto Regular")

Our @font-face { src: local() } matching is incorrectly going down the
same code path that is used for matching CSS font-family. On Windows,
this family match code path takes extra steps to ensure something like
"Roboto Regular" is matched against Roboto, or "Roboto Bold" is matched
against Roboto, in a bold variant. However, this type of matching is too
wide for local(), where the CSS fonts module specification expects a
unique match against full font name or postscript name. On Windows, it
was incorrectly matching local("Roboto Regular") against "Roboto Bold"
if that was the only available Roboto font on the system.

This CL is a temporary fix for the case of "Roboto Regular" matching
against Roboto Bold. However, matching local("Roboto Bold") against the
actual Roboto Bold does still not work, also local("Roboto") still
matches against Roboto Bold if that is the only available Roboto on the
system. A full fix requires access to the OpenType name table and
reading the full font name or postscript name.

TEST=Manual, using src: local("Roboto"), local("Roboto Regular"),
     local("Roboto Bold") with only Roboto Bold installed on the system
BUG=690334

Review-Url: https://codereview.chromium.org/2721613002
Cr-Commit-Position: refs/heads/master@{#453600}
Committed:
https://chromium.googlesource.com/chromium/src/+/d31bcba110520454ced012b05695...
==========

[commit-bot: I haz the power, 2017-02-28 14:58:12]

Committed patchset #4 (id:60001) as
https://chromium.googlesource.com/chromium/src/+/d31bcba110520454ced012b05695...