Refactor SkFontHost_linux into SkFontMgr_custom.

include/ports/SkFontMgr_custom.h

Index: include/ports/SkFontMgr_custom.h
diff --git a/include/ports/SkFontMgr_custom.h b/include/ports/SkFontMgr_custom.h
new file mode 100644
index 0000000000000000000000000000000000000000..7a413b024358991ba97d2aa002c295eaf62bd2ea
--- /dev/null
+++ b/include/ports/SkFontMgr_custom.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright 2015 Google Inc.
+ *
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+#ifndef SkFontMgr_custom_DEFINED
+#define SkFontMgr_custom_DEFINED
+
+#include "SkTypes.h"
+
+class SkFontMgr;
+
+/** Create a custom font manager which scans a given directory for font files. */
+SK_API SkFontMgr* SkFontMgr_New_Custom_Directory(const char* dir);
+
+struct SkEmbeddedResource { const uint8_t* data; size_t size; };

[reed1, 2015/06/15 15:48:07]

This struct stuff seems funny. If it is supposed to be something like what comes
out of a directory iterator (the first API), perhaps we want

class SkFileNameIteratorBaseClass;

SkFontMgr_New_From_Iter(...)

or 

SkFontMgr_New_From_File_List(const char* names[], int count);

?

[bungeman-skia, 2015/06/15 16:15:43]

No, the entire point is to avoid having a file system or names. This is designed
around providing fonts in the executable as static const data and having the
linker tell us where it is. While it would be interesting to add an abstraction
layer on top of this or have the user embed an entire file system as data and
have them mount that and pass a handle to it, this is mostly designed around
providing a simple means of embedding test fonts.

+struct SkEmbeddedResourceHeader { const SkEmbeddedResource* entries; int count; };
+/** Create a custom font manager which reads font files from embedded data. */
+SK_API SkFontMgr* SkFontMgr_New_Custom_Embedded(const SkEmbeddedResourceHeader* header);
+
+#endif // SkFontMgr_custom_DEFINED