Enable "system-ui" generic font family

third_party/WebKit/Source/platform/fonts/skia/FontCacheSkia.cpp

Index: third_party/WebKit/Source/platform/fonts/skia/FontCacheSkia.cpp
diff --git a/third_party/WebKit/Source/platform/fonts/skia/FontCacheSkia.cpp b/third_party/WebKit/Source/platform/fonts/skia/FontCacheSkia.cpp
index 16678e70b19b88a6feb4f67e57f32b195d9e5e93..92442840161d800d53c25cdad1d733881de670ba 100644
--- a/third_party/WebKit/Source/platform/fonts/skia/FontCacheSkia.cpp
+++ b/third_party/WebKit/Source/platform/fonts/skia/FontCacheSkia.cpp
@@ -229,21 +229,33 @@ sk_sp<SkTypeface> FontCache::createTypeface(
   }
 #endif
 
+#if OS(WIN)
+  DCHECK_NE(family, FontFamilyNames::system_ui);
+  const char* familyNameForSkia = name.data();
+#else
+  // When the system UI font is localized, "system-ui" should have
+  // been replaced to the localied name. Use the Skia default family

[drott, 2016/10/12 11:01:59]

Can you add some explanations where was it replaced? localied -> localized.
If I understand correctly, this will be in upcoming CLs? In this case, can you
add a TODO with bug link here?

When does this fail and we don't have a localized name? What are the chances it
fails?

As fallback if the localized name is missing, I'd prefer to fallback to one of
the browser side generic families instead of Skia's default family, would that
make sense? Skia's default is more similar to our LastResort - is that the
intention? Or would falling back to another FontFamilyNames category make more
sense? 

If it's closer to LastResort can we extract the name from
FontCache::getLastResortFallbackFont? That gives us more control and we don't
have to rely on Skia's default which may change.

[kojii, 2016/10/12 11:14:52]

FontCacheLinux already has setSystemFontFamily() in this CL, but nobody calls it
yet. Getting the string from resources and call it will be in the next CL
https://codereview.chromium.org/2138613002
Linux English version does not have the string, so will use Skia default. I
believe CJK versions have localized font names in the resources. Also CrOS has
the resource even in English version.
It is the intention. When I read through our UI/menu rendering code in the
browser, Linux/English uses nullptr to get the font from Skia, so this is
mimicing our UI/menu rendering code. Our LastResort could be more suitable for
document rendering, the same logic as UI/menu rendering looks better to me, no?

Thanks for catching the spell error, will fix in the next CL.

+  // if it is not localized by using nullptr.
+  const char* familyNameForSkia =
+      family == FontFamilyNames::system_ui ? nullptr : name.data();
+#endif
+
 #if OS(LINUX) || OS(WIN)
   // On linux if the fontManager has been overridden then we should be calling
   // the embedder provided font Manager rather than calling
   // SkTypeface::CreateFromName which may redirect the call to the default font
   // Manager.  On Windows the font manager is always present.
-  if (m_fontManager)
+  if (m_fontManager) {
     return sk_sp<SkTypeface>(m_fontManager->matchFamilyStyle(
-        name.data(), fontDescription.skiaFontStyle()));
+        familyNameForSkia, fontDescription.skiaFontStyle()));
+  }
 #endif
 
   // FIXME: Use m_fontManager, matchFamilyStyle instead of
   // legacyCreateTypeface on all platforms.
   sk_sp<SkFontMgr> fm(SkFontMgr::RefDefault());
-  return sk_sp<SkTypeface>(
-      fm->legacyCreateTypeface(name.data(), fontDescription.skiaFontStyle()));
+  return sk_sp<SkTypeface>(fm->legacyCreateTypeface(
+      familyNameForSkia, fontDescription.skiaFontStyle()));
 }
 
 #if !OS(WIN)