Remove duplicate fonts from the font fallback list.

Remove duplicate fonts from the font fallback list.

We use std::unique to remove duplicate entries from the fallback list.

BUG=467459
Committed: https://crrev.com/83de07b1894c61e53469c830c9f7c8986d9ae42c
Cr-Commit-Position: refs/heads/master@{#321497}

[ananta, 2015-03-19 23:53:39]

ananta@chromium.org changed reviewers:
+ msw@chromium.org

[msw, 2015-03-20 00:18:05]

lgtm

[ananta, 2015-03-20 00:23:51]

The CQ bit was checked by ananta@chromium.org

[commit-bot: I haz the power, 2015-03-20 00:24:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1019743004/20001

[commit-bot: I haz the power, 2015-03-20 02:15:56]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-20 02:17:09]

Patchset 2 (id:??) landed as
https://crrev.com/83de07b1894c61e53469c830c9f7c8986d9ae42c
Cr-Commit-Position: refs/heads/master@{#321497}

[Peter Kasting, 2015-03-20 07:15:01]

pkasting@chromium.org changed reviewers:
+ pkasting@chromium.org

[Peter Kasting, 2015-03-20 07:15:01]

I'm quite concerned with the list ordering change this produces.  It seems like
that's going to cause visible problems.  Did you evaluate how bad this is and
have good reason to conclude it was not an issue before moving forward with this
change?

If not, I think the change is potentially worse than what went before.

[ananta, 2015-03-20 07:28:19]

On 2015/03/20 07:15:01, Peter Kasting wrote:
> I'm quite concerned with the list ordering change this produces.  It seems
like
> that's going to cause visible problems.  Did you evaluate how bad this is and
> have good reason to conclude it was not an issue before moving forward with
this
> change?
> 
> If not, I think the change is potentially worse than what went before.

The fallback font list is based on the base font followed by its linked fonts.
The ShapeRun function returns early if it finds a font which yields zero
unmatched glyphs. If not it runs through the whole list and finds the font which
yields the least number of mismatches.

So we should be ok in most cases.

[Peter Kasting, 2015-03-20 07:30:54]

On 2015/03/20 07:28:19, ananta wrote:
> On 2015/03/20 07:15:01, Peter Kasting wrote:
> > I'm quite concerned with the list ordering change this produces.  It seems
> like
> > that's going to cause visible problems.  Did you evaluate how bad this is
and
> > have good reason to conclude it was not an issue before moving forward with
> this
> > change?
> > 
> > If not, I think the change is potentially worse than what went before.
> 
> The fallback font list is based on the base font followed by its linked fonts.
> The ShapeRun function returns early if it finds a font which yields zero
> unmatched glyphs. If not it runs through the whole list and finds the font
which
> yields the least number of mismatches.
> 
> So we should be ok in most cases.

That's relieving, but in that case, how could the order matter at all (as the
comment suggests it might)?  It sounds like the behavior should be identical no
matter the order?  (Or is the difference tiebreaking?)

[msw, 2015-03-20 16:33:14]

On 2015/03/20 07:30:54, Peter Kasting wrote:
> On 2015/03/20 07:28:19, ananta wrote:
> > On 2015/03/20 07:15:01, Peter Kasting wrote:
> > > I'm quite concerned with the list ordering change this produces.  It seems
> > like
> > > that's going to cause visible problems.  Did you evaluate how bad this is
> and
> > > have good reason to conclude it was not an issue before moving forward
with
> > this
> > > change?
> > > 
> > > If not, I think the change is potentially worse than what went before.
> > 
> > The fallback font list is based on the base font followed by its linked
fonts.
> > The ShapeRun function returns early if it finds a font which yields zero
> > unmatched glyphs. If not it runs through the whole list and finds the font
> which
> > yields the least number of mismatches.
> > 
> > So we should be ok in most cases.
> 
> That's relieving, but in that case, how could the order matter at all (as the
> comment suggests it might)?  It sounds like the behavior should be identical
no
> matter the order?  (Or is the difference tiebreaking?)

Yes, the difference would be in tie-breaking or an early return on a different
font that also yields no missing glyphs.