Import and export UFO zips

[felipesanches]

There's a proof of concept implemented by Alex Troush at https://github.com/metapolator/metapolator/tree/gh-pages/next/app

One can access this page: http://metapolator.com/next/app/glyph-inspector/glyph-inspector.html

...and drop a UFO zip and see it's glif outlines rendered as svg. But it seems that Alex did not use ufoJS for this.

We should cleanup, refactor and incorporate that functionality into ufoJS.

[felipesanches]

The initial plan is to start from Alex's code and make it part of ufoJS io classes.

[graphicore]

What I'd like to see would be compatible with our io api: https://github.com/graphicore/ufoJS/tree/master/lib/tools/io

Metapolator has also some io classes: https://github.com/metapolator/metapolator/tree/master/app/lib/io

From some research I believe this is the zip library to use: http://stuk.github.io/jszip/ But I can't say for sure :-) I remember Alex had some trouble with the lib he used, I think I remember that he did some custom debugging.

From some recent discussion about the future of the UFO file format, one critique was that it seems to be hard to rewrite just one file in a zip archive, without having to rewrite everything. A clear statement of what our implementation can do in this respect would be great. This is strongly dependent of the zip implementation I guess.

It is strongly desired to have this working in the Browsers (current FF/Chromium) and NodeJS.

I can make a review of Alex's implementation if you want, this should help.

[graphicore]

Also, if making a zipIO implementation proves being a bad idea for any reason, maybe we should do a generic function that just takes an IO object to copy the zip contents to, for example: https://github.com/metapolator/metapolator/blob/master/app/lib/io/InMemory.js

like: function readZip(zipData, ioObject, targetPath) and function writeZip(sourcePath)

[felipesanches]

Yes, a review of Alex's implementation would be greatly appreciated, for sure!

[graphicore]

The biggest problem with a Browser and NodeJS interface is probably the handling of binary data. We should find some solution that is good for both platforms. I think that means having either ArrayBuffer on nodeJS or Buffer in the browser. But I did not investigate.

[davelab6]

Felipe, you might like to look at how opentype.js handles packing the binary. I think it is with ArrayBuffer

[felipesanches]

I've just read this, regarding "Compact UFO": http://unifiedfontobject.org/roadmap.html It worries me a bit. What is the current state of this? A ZIP-file containing the UFO directory is not yet embraced by a formal spec, right? It seems that it is mostly a desired feature that we want to experiment with even if it can lead to performance issues in extreme cases. Are there already a few examples of extreme cases? To talk about 4 billions of glyphs sounds to me like an exaggeration over a theoretical capability.

Additionaly, where can I get sample "Compact UFO" files? I know I supposedly can produce them by zipping an UFO directory, but I'd like to be sure I'm dealing with the real thing by looking at sample files provided by someone else.

[felipesanches]

I guess this is one example, at least: https://github.com/metapolator/metapolator/blob/gh-pages/next/app/glyph-inspector/app/glyphInspector/TestFont1%20%28UFO3%29.ufo.zip

I'll still be glad to have more sample files at hand, though.

[graphicore]

No worries. We don't intend to do something like ufo compact at the moment. We really need just a way that a user can open a ufo in a browser. Also, the io api and classes will eventually get their own project, you don't need to care about complying to the ufo spec, just make an io class that uses zip as a backend (if feasible)

[graphicore]

adobe source sans has relatively large ufo files (~1000 glyphs): https://github.com/adobe-fonts/source-sans-pro/tree/master/Roman/Black/font.ufo

[felipesanches]

thanks!

[graphicore]

Oh, ok, just zip a ufo, there is no such thing as compact ufo yet, and you wont find this in the wild. However, if you can produce a sane backend for zipped ufos, which especially doesn't need to re-zip everything to change just one file, then we can run it up to the people who do the current research for compact ufo. This is one of the biggest critiques for just zipping ufos.

[davelab6]

On 2 Apr 2015 2:45 pm, "Felipe Corrêa da Silva Sanches" < notifications@github.com> wrote:

I've just read this, regarding "Compact UFO": http://unifiedfontobject.org/roadmap.html It worries me a bit. What is the current state of this?

It is very early explorations that move very slowly. Don't mind it :) However if you have a view on the ideal kind of persistence format based on your 3d work that would be cool to hear

A ZIP-file containing the UFO directory is not yet embraced by a formal spec, right?

No, but it's already shipped in 1 proprietary tool (vfb2ufo) and all modern file browsing shells have a right click 'zip this Directory' feature, so I think it's orthogonal to the UFOv4 exploration, although that might end up concluding that s zip of a UFO v3 is sufficient.

It seems that it is mostly a desired feature that we want to experiment with even if it can lead to performance issues in extreme cases.

Yes. There is no other way to get a UFO into a browser that is more simple. If you think of something, let us know :) More complex solutions can offer things a zip can't, but their trade off is simplicity.

Are there already a few examples of extreme cases? To talk about 4 billions of glyphs sounds to me like an exaggeration over a theoretical capability.

Unicode has potential for a lot of glyphs, like hundreds of thousands. Metapolator itself also presents the possibly of tens of thousands, given a devanagari plus Latin is 1,000 without stylistic alternates.

Additionaly, where can I get sample "Compact UFO" files? I know I supposedly can produce them by zipping an UFO directory,

Yes that is fine

but I'd like to be sure I'm dealing with the real thing by looking at samples files provided by someone else.

vfb2ufo is the only tool but it's proprietary ;)

— Reply to this email directly or view it on GitHub.

[davelab6]

I think you can zip -0 for a zip without compression, essentially the same as tar, which might allow to change files in situ like that