Fixes 1 pixel shift of text rendering on CrOS and Linux.

Fixes 1 pixel shift of text rendering on CrOS and Linux.

For those platform which don't support cap height, we should center the entire font height instead of the cap height.  This CL applies the same fix as http://crrev.com/59873002 .

BUG=314688
TBR=asvitkine,msw
TEST=Test manually.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=234137

[commit-bot: I haz the power, 2013-11-09 08:43:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yukishiino@chromium.org/66723009/1

[Yuki, 2013-11-09 08:44:45]

Could you review this CL?

Sine the issue 314688 is beta blocking, and the change should be quite safe, let
me TBR.

[commit-bot: I haz the power, 2013-11-09 19:22:14]

Change committed as 234137

[msw, 2013-11-11 18:07:26]

LGTM, but please consider my comment/question.

https://codereview.chromium.org/66723009/diff/1/ui/gfx/render_text.cc
File ui/gfx/render_text.cc (right):

https://codereview.chromium.org/66723009/diff/1/ui/gfx/render_text.cc#newcode65
ui/gfx/render_text.cc:65: // Some platforms don't support getting the cap
height, and simply return
This and your prior CL (http://crrev.com/59873002) both restore text height
centering instead of cap height centering for Pango. Doesn't that effectively
undo this part of you original CL:
https://codereview.chromium.org/25039002/diff/1099001/ui/gfx/platform_font_pa...
Should you undo the changes in these two latest CLs and that small part of the
original CL to keep the same behavior? Or do some fonts (on other platforms?)
actually not provide an internal_leading, and these coordinated workarounds
actually support some additional cases?

[Peter Kasting, 2013-11-12 02:00:23]

I've been kinda uncomfortable with this issue as well.

If possible, I think callers should never be trying to detect a "failure" of
GetCapHeight().  In the limit, it would be better to make GetCapHeight() return
a bool (or add a parallel SupportsGetCapHeight() function) so callers could just
know if a platform supported such a feature, instead of trying to check in a
hacky way.  Perhaps, however, Mike's suggestion makes more sense.

Of course, all this could be resolved more directly by just implementing this
for real on Pango.  I have tried in the past to link to bugs where I've made
some suggestions about how this could be done.

[Yuki, 2013-11-12 09:49:21]

On 2013/11/12 02:00:23, Peter Kasting wrote:
> I've been kinda uncomfortable with this issue as well.
> 
> If possible, I think callers should never be trying to detect a "failure" of
> GetCapHeight().  In the limit, it would be better to make GetCapHeight()
return
> a bool (or add a parallel SupportsGetCapHeight() function) so callers could
just
> know if a platform supported such a feature, instead of trying to check in a
> hacky way.  Perhaps, however, Mike's suggestion makes more sense.
> 
> Of course, all this could be resolved more directly by just implementing this
> for real on Pango.  I have tried in the past to link to bugs where I've made
> some suggestions about how this could be done.

I'd like to assume that the internal leading = GetBaseline() - GetCapHeight(). 
GetCapHeight() == GetHeight() breaks this assumption (the internal leading
becomes negative).

I'd like to fix this problem by implementing PlatformFontPango::GetCapHeight().

I think we can get the cap height by actually layouting "ABC...XYZ" and getting
its height.  This layouting will be done once per font per size.  So we can
accept this cost.

[msw, 2013-11-12 17:58:56]

On 2013/11/12 09:49:21, Yuki wrote:
> I think we can get the cap height by actually layouting "ABC...XYZ" and
getting
> its height.  This layouting will be done once per font per size.  So we can
> accept this cost.

Please attempt to address our earlier concerns with this approach.
( see comments at http://crrev.com/24240013 )
Remember that it'll be once per font/size/style (bold/italic).
Remember that capital letters may be shorter than lowercase.
Remember that other language characters might be taller/shorter.
This approach might be okay, but it's not really correct, afaict.

[Peter Kasting, 2013-11-12 19:57:08]

On 2013/11/12 09:49:21, Yuki wrote:
> I think we can get the cap height by actually layouting "ABC...XYZ" and
getting
> its height.  This layouting will be done once per font per size.  So we can
> accept this cost.

No.  Don't do it this way.  There are correct ways to do this that actually read
the true metrics out of the font and return you the same values Windows
calculates, and as a bonus are faster than this method.  Go read the bugs about
this.  If you still don't understand what I'm asking for, ping me.

[Yuki, 2013-11-13 02:12:39]

On 2013/11/12 19:57:08, Peter Kasting wrote:
> On 2013/11/12 09:49:21, Yuki wrote:
> > I think we can get the cap height by actually layouting "ABC...XYZ" and
> getting
> > its height.  This layouting will be done once per font per size.  So we can
> > accept this cost.
> 
> No.  Don't do it this way.  There are correct ways to do this that actually
read
> the true metrics out of the font and return you the same values Windows
> calculates, and as a bonus are faster than this method.  Go read the bugs
about
> this.  If you still don't understand what I'm asking for, ping me.

Okay, let me try to retrieve the font metrics from fonts.  If you have any
clues, please let me know.  When I tried this before, I didn't find an API in
Pango.