Use views::style for buttons, bootstrap ash_typography to do so.

ui/views/style/typography_provider.h

Index: ui/views/style/typography_provider.h
diff --git a/ui/views/style/typography_provider.h b/ui/views/style/typography_provider.h
index aab1c0e997d7a325fd33671e07f3756dcea28cfd..684f751f9c43ba5225a5153d7fc0c8da6e9f5bbf 100644
--- a/ui/views/style/typography_provider.h
+++ b/ui/views/style/typography_provider.h
@@ -31,6 +31,11 @@ class VIEWS_EXPORT TypographyProvider {
   // Gets the line spacing, or 0 if it should be provided by gfx::FontList.
   virtual int GetLineHeight(int context, int style) const = 0;
 
+  // A user's gfx::Weight::NORMAL font may already "bold enough" and requesting
+  // a MEDIUM font can result in a font that is less bold. So this method
+  // returns NORMAL, if the NORMAL font is at least as bold as |weight|.

[Peter Kasting, 2017/04/08 01:38:54]

I'm confused.  There are fonts where asking for a lower weight (e.g. 400) gets
you a bolder font than asking for a higher weight (e.g. 500)?

[tapted, 2017/04/10 12:27:33]

Yup.

The windows font settings have a "Bold font" checkbox. Checking this will put a
bold font into ResourceBundle when asking for gfx::Weight::NORMAL. Fonts at a
given *size* are derived from the unstyled font at the normal size, so this
boldness is preserved when changing _size_.

However, deriving a Weight::MEDIUM font from a bold font (i.e. the one in the
NORMAL slot) will cause the weight to decrease.

[Peter Kasting, 2017/04/10 22:56:02]

OK, so effectively, the "bold font" checkbox really means "when someone calls
the font APIs requesting NORMAL, return something that's really BOLD; for any
other weight, just do what they asked"?

If so, (a) thanks Microsoft, that's a great way to implement this :P, and (b)
can you make the comments more specific to describe this particular scenario,
rather than leaving them sort of vague and general as today?

[tapted, 2017/04/11 01:56:50]

It's not quite that bad :). The logic for this is in

PlatformFontWin::HFontRef* PlatformFontWin::GetBaseFontRef() 

It calls base::win::GetNonClientMetrics(..) and creates a gfx::Font using the
HFONT that the WinAPI puts into NONCLIENTMETRICS_XP::lfMessageFont
Done.

[Peter Kasting, 2017/04/11 02:24:20]

OK, so the default metrics say e.g. "use weight 600", and so the issue is that
if we ask PlatformFont for "normal", it doesn't actually force the weight, it
just uses the base font, so we get bold, but if we ask for a specific weight, it
writes that into the metrics, and then we get that?

If so it sounds to me like PlatformFont should take care of this -- if we ask
for something bolder than NORMAL, but we're deriving it on a font where the base
metrics would already have given a higher weight to the NORMAL case, then we
should clamp the requested weight to at least that weight.

Doing it in the typography provider seems a bit too high-level.  Or long run
does it not matter because no one uses PlatformFont directly and everyone goes
through the typography provider?  Though even then it seems like this should
happen there, I think?

[tapted, 2017/04/12 07:31:48]

Yup
I don't think PlatformFont is right. It's coincidence that a default-constructed
PlatformFont gets its metrics from something that happens to be used for UI.
E.g. There's no reason why Blink should have its own font class rather than
using gfx::Font (I want to combine them!)

Another option is ResourceBundle - it's ResourceBundle::GetFontListWithDelta().
That's the method that has the logic to preserve styles on the base font when
deriving a font at the same size
https://cs.chromium.org/chromium/src/ui/base/resource/resource_bundle.cc?l=582 

It also has logic to do a bitwise-OR of styles when deriving things.

But I don't think that's right either. E.g. we'd have to make a decision what to
do when deriving a _lighter_ weight to be consistent. That is, when BaseFont is
"BOLD" should gfx::Font::Weight::LIGHT be MEDIUM? If it's not, how does one get
a MEDIUM font if they really want one?


I think the root cause is that it's a bug that
ResourceBundle::GetFontListwithDelta(.., Font::Weight::NORMAL) would ever give a
BOLD font. We can't change that without breaking everything.

I think we'd want to introduce something like Font::Weight::SYSTEM to do what
Weight::NORMAL currently does: (and only that should have any special logic for
MEDIUM to still return BOLD when Weight::SYSTEM is already BOLD). and
brute-force/refactor everything currently using NORMAL to see if it should be
changed to SYSTEM instead.

Currently this confusion results from burying this weird logic around system UI
fonts deep in the system. I think adding _more_ subtle logic can only make that
worse. (Hence SYSTEM to make it explicit rather than subtle).

[Peter Kasting, 2017/04/13 03:53:17]

Yeah, I agree this is too low-level -- the issue is with the behavior when you
ask for a specific UI font like "the base font", and that happens above this
layer.
All font weights are relative to the normal appearance of that font face.  The
real problem here, IMO, is that Microsoft implemented this "bold font" checkbox
not by substituting a different font face that appeared bolder at the same
weight, but that they hacked the default weight metrics.

But given that they did this, I think we should try and pretend they did it the
other way -- that is, we basically ask the system for (base font's base weight)
+ (requested weight - NORMAL).  When this checkbox isn't on, that does the same
thing as today; otherwise, it will add 200 to every requested font weight.  This
has a similar effect as if Microsoft was just using a font face that was
inherently bolder.

So to answer your question, one should not be able to "get a MEDIUM font if they
really want one", because the fact that the weights are being munged should be
hidden from the view of all ResourceBundle consumers.
We could sort of do that, but I claim:
(1) Everyone using NORMAL should use SYSTEM; there is no place where we should
avoid the SYSTEM behavior.
(2) And also everyone using every other font weight should have things adjusted,
because those weights were chosen relative to NORMAL, and they should stay
relative to the "NORMAL" (now SYSTEM) weight.

Hence my proposal above.
I would agree if only some consumers want this.  If every consumer wants this,
better to do it at a core level.

[tapted, 2017/05/05 03:08:49]

I've implemented this in PatchSet 13. But -- without introducing a behaviour
change -- it doesn't help simplify the logic here. The current logic returns
Weight::NORMAL if that's "bold enough" -- i.e. the weight is "capped" to bold.

In PatchSet 14 I've explored a simplification that results in a behaviour
change: MD buttons will use BLACK weight on Windows if the base font is BOLD.
(same applies to the default buttons in non-MD).

I've added some screenshots to http://crbug.com/691891#c16 . I am still unsure
about this, because:
- It assumes gfx::Font::Weight is linear, and that the system provides fonts at
all weights consistently (e.g. across typefaces where fallback fonts are
involved)
- A user may be setting their default fonts to 'BOLD' to assist with legibility,
but BLACK may be less legible than BOLD.

+  static gfx::Font::Weight WeightNotLighterThanNormal(gfx::Font::Weight weight);
+
  protected:
   TypographyProvider() = default;
 
@@ -52,10 +57,10 @@ class VIEWS_EXPORT DefaultTypographyProvider : public TypographyProvider {
   // Sets the |size_delta| and |font_weight| that the the default GetFont()
   // implementation uses. Always sets values, even for styles it doesn't know
   // about.
-  void GetDefaultFont(int context,
-                      int style,
-                      int* size_delta,
-                      gfx::Font::Weight* font_weight) const;
+  static void GetDefaultFont(int context,
+                             int style,
+                             int* size_delta,
+                             gfx::Font::Weight* font_weight);
 
  private:
   DISALLOW_COPY_AND_ASSIGN(DefaultTypographyProvider);