Refactor fontnik font registering?

[lbud]

@springmeyer would love to get your feedback on this —

node-fontnik will be used in the font uploading API, but @mikemorris and I talked about how we could totally refactor this to no longer use the Mapnik font registry concept and have little name2face maps floating around, but rather pull the streaming logic out so that we could do something like

fontnik.load(fontfile, function(faces) {
  // faces returns an array per face from the file of objects that look like
  // {  face_name: "",
  //    family_name: "",
  //    style_name: "",
  //    codepoints: [],
  //    range: function
  // }
})

(where the FT library/stream is scoped to the callback so that the range function can be repeatedly called inside the callback). And eliminate much of the node-fontnik API.

But, given that the registry actually seems (if I understand correctly) mostly harmless — just a name-to-face map — is it worth doing this? (Or is it harmless?)

[springmeyer]

👍 to simplifying and trying to reduce the duplicated code. I'm tied up at FOSS4G today, but would love to voice on this tomorrow?

[mikemorris]

Voice tomorrow would work for me, I'll be around to chat too!

[lbud]

👍 voice tomorrow is good for me too!

[springmeyer]

Capturing voice call:

• Yes, this new API proposal makes sense and will obsolete the need for the pre-populated registry.
• After the registry is removed maybe other cruft can be dropped
• We'll maintain the low-level FT library API calls (where std::fopen is used instead of FT for file io in order to keep the possibility for windows support).

[springmeyer]

happening in #80