Font variations.

src/core/SkFontDescriptor.h

Index: src/core/SkFontDescriptor.h
diff --git a/src/core/SkFontDescriptor.h b/src/core/SkFontDescriptor.h
index 66707ddd3c5e10819ecd87e4d2352ed603c85817..8a837ae46fbf0efa274e349f05e759f04e079f06 100644
--- a/src/core/SkFontDescriptor.h
+++ b/src/core/SkFontDescriptor.h
@@ -12,6 +12,29 @@
 #include "SkString.h"
 #include "SkTypeface.h"
 
+class SkFontData {
+public:
+    /** This takes ownership of 'stream'. Makes a copy of the data in 'axis'. */
+    SkFontData(SkStreamAsset* stream, int index, int axisCount, const SkFixed axis[])
+        : fStream(stream), fIndex(index), fAxisCount(axisCount), fAxis(axisCount)
+    {
+        for (int i = 0; i < axisCount; ++i) {
+            fAxis[i] = axis[i];
+        }
+    }
+    bool hasStream() const { return fStream.get() != NULL; }
+    SkStreamAsset* transferStream() { return fStream.detach(); }
+    int getIndex() const { return fIndex; }
+    int getAxisCount() const { return fAxisCount; }
+    const SkFixed* getAxis() const { return fAxis.get(); }
+
+private:
+    SkAutoTDelete<SkStreamAsset> fStream;
+    int fIndex;
+    int fAxisCount;
+    SkAutoSTMalloc<4, SkFixed> fAxis;

[bungeman-skia, 2015/04/23 21:16:34]

Is this the right way to serialize the axes (as a list of fixed point values)?
Internally, we know that in the font they come in some consistent order, so this
should be enough to reconstruct. However, making each axis here a pair
(SkFourByteCode, SkFixed) does make things clearer, and while the order and the
code are somewhat redundant information, it does make working with CoreText a
lot simpler (and probably safer).

In FreeType the ordering can be trusted to work out.

With CoreText, CTFontCopyVariation returns an unordered { tag|name : double }
and while currently always in the right order there is no guarantee.
CTFontCopyVariationAxes returns a [{tag:int, min:double, max:double, def:double,
name:string}] which could be used to sort against, but there is also no strict
guarantee that the order of this array will be stable. Also, as it turns out
CTFont*Variation* methods only work when the font is created with CT/NS. Fonts
created with CG and converted to CT don't seem to work correctly (much like
CTFontCopyTable / CGFontCopyTableForTag), so it turns out we may need to rely on
the CG versions of these since that's the only way to create a font from data.
This means that just using public API on OSX, we cannot even know the tags, and
must rely on array ordering.

GDI kinda supports MM, and you can get the values used, but there doesn't appear
to be any means of setting the values when creating a font. DirectWrite doesn't
appear to support the notion at all, outside of its synthetic attributes. If
DirectWrite ever does support this, I would imagine that there would be a
enumeration with the various known values and a IDWriteFontX / IDWriteFontFaceX
with some interface for querying/setting values.

enum DWRITE_FONT_AXIS_TAG {
  DWRITE_FONT_AXIS_TAG_DEFAULT,
  DWRITE_FONT_AXIS_TAG_WEIGHT = 0x74686777,
  DWRITE_FONT_AXIS_TAG_WIDTH = 0x68746477,
  DWRITE_FONT_AXIS_TAG_SLANT = 0x746E6C73,
  DWRITE_FONT_AXIS_TAG_OPTICAL_SIZE = 0x7A73706F,
};

struct DWRITE_FONT_AXIS_METRICS {
  DWRITE_FONT_AXIS_TAG tag;
  FLOAT min;
  FLOAT default;
  FLOAT max;
};

IDWriteFontX {
  virtual UINT32 GetAxisCount() = 0;
  virtual HRESULT GetAxesCoordinates([in, out] UINT32 * numberOfAxes, [out,
optional] FLOAT* axes) = 0;
  virtual HRESULT GetAxisMetrics(UINT32 index, [out] DWRITE_FONT_AXIS_METRICS *
metrics) = 0;
  virtual HRESULT GetAxisNames(UINT32 index, [out] IDWriteLocalizedStrings **
names) = 0;
  virtual HRESULT CreateFontFace(UINT32 numberOfAxes, [in] FLOAT* axes, [out]
IDWriteFontFaceX ** fontFace) = 0;

  virtual UINT32 GetNamedStylesCount() = 0;
  virtual HRESULT GetNamedStyleCoordinates(UINT32 index, UINT32 numberOfAxes,
[out] FLOAT* axes) = 0;
  virtual HRESULT GetNamedStyleNames(UINT32 index, [out] IDWriteLocalizedStrings
** names) = 0;
};

From this sort of thought experiment, it seems likely that positional axes would
be supported, though like the current CoreText API, there may be no reason to
believe that after being serialized and deserialized that the axes in the
deserialized font are necessarily in the same order. All of this to say, we
should always have access to an axis tag, so always pass that with the values.
This is a minimal amount of extra information to carry, as this information is
being passed with the rest of the font data in any event.

+};
+
 class SkFontDescriptor {
 public:
     SkFontDescriptor(SkTypeface::Style = SkTypeface::kNormal);
@@ -28,24 +51,20 @@ public:
     const char* getPostscriptName() const { return fPostscriptName.c_str(); }
     bool hasFontData() const { return fFontData.get() != NULL; }
     // Transfers ownership to the caller.
-    SkStreamAsset* transferFontData() { return fFontData.detach(); }
-    int getFontIndex() const { return fFontIndex; }
+    SkFontData* getFontData() { return fFontData.get(); }
 
     void setFamilyName(const char* name) { fFamilyName.set(name); }
     void setFullName(const char* name) { fFullName.set(name); }
     void setPostscriptName(const char* name) { fPostscriptName.set(name); }
     /** Set the font data only if it is necessary for serialization.
-     *  This method takes ownership of the stream (both reference and cursor).
-     */
-    void setFontData(SkStreamAsset* stream) { fFontData.reset(stream); }
-    void setFontIndex(int index) { fFontIndex = index; }
+     *  This method takes ownership of the font data. */
+    void setFontData(SkFontData* data) { fFontData.reset(data); }
 
 private:
     SkString fFamilyName;
     SkString fFullName;
     SkString fPostscriptName;
-    SkAutoTDelete<SkStreamAsset> fFontData;
-    int fFontIndex;
+    SkAutoTDelete<SkFontData> fFontData;
 
     SkTypeface::Style fStyle;
 };