Encoding of font files about fontkit HOT 13 OPEN

I really, really wish FontKit could subset woff fonts! If there was a crowdfunding for this feature alone, I'll back it for sure :D

from fontkit.

@devongovett I'd like to have a JS solution, but not for browser — for node.js-based stuff. Reason: not to have a Python dependency and to be able to install it with just npm.

I've looked at fonttools once, tried to install them and failed somewhere (can't remember where), so right now I'm just using FontForge to manually subset all the fonts I need, haha.

from fontkit.

Also, I miss a way for a new font file to be created from scratch and not as a subset of a previously parsed font file.

from fontkit.

You are correct. Fontkit does not currently support encoding fonts from scratch, and while basic subsetting support exists, it is mostly designed for use in PDF files (for PDFKit), so it generates very minimal fonts without all of the required tables for standalone use.

Because the tables are implemented using restructure, they automatically support encoding as well as decoding. But the actual glyph paths are not decoded by restructure because they are more complex, so encoding would also need to be written by hand. So here's what's missing in my estimation:

• glyph path encoding for CFF and TTF
• a high level API to create a font, set metadata properties, and add glyph paths.
• encoders for various font formats (e.g. WOFF, collections...)
• some nice API for defining things like GSUB/GPOS...

Even though most of the tables should "just work" when encoding, we still have to write all of the code to produce the tables as JavaScript objects. Some tables like GSUB and GPOS are pretty complex, so if we support them, this may be quite a bit of work.

I don't currently need support for encoding fonts in JS, so I probably won't have time to work on this myself, but I'm happy to assist to others who would like to do it.

from fontkit.

FYI, as of #43 there is a TTFGlyphEncoder class that can encode paths to TrueType glyph buffers. Currently used when subsetting a variation font for PDF, but it could be used to build a font from scratch as well.

from fontkit.

cool, thanks! :-)

from fontkit.

On a sidenote, though, having multiple hammers for different nails is always a good idea, so if you need to build a font "from scratch", you might also want to have a look at opentype.js

from fontkit.

Does this mean that fontkit can not be used to subset webfonts at the moment? E.g. woff in >> woff with subset glyphs out.

It sure would make me happy being able to subset automatically rather than having to use fontsquirrel's webfont generator every time!

from fontkit.

(One thing to realize is that WOFF is just a thin wrapper around OpenType that repacks each table as a compressed block with the most minimal of additional metadata so that tables can be unpacked individually, so you could just unpack the WOFF, subset the OptenType font, and then repack as WOFF)

from fontkit.

😃 @Pomax awesome! When I have time on the weekend I'll have a go at coding a gulp script which takes in otf files and outputs woff and woff2.

I'll open a new issue if I run into any problems, didn't mean to hijack this issue.

from fontkit.

The above comment still stands. The current font subsetting abilities of fontkit are designed for PDFKit's usage. Several required tables for standalone usage are not currently included in the subset font, and additional subsetting support for other tables such as GSUB and GPOS are not supported. For that, I'd recommend fonttools.

@kizu @maxmilton do you need font subsetting specifically in JS (e.g. for browser usage) or does something like fonttools work for you?

from fontkit.

I would be interested also in this functionality. @devongovett you've outlined what is missing. Do you think it would be a lot of effort to implement these missing bits? I imagine that subsetting GSUB and GPOS tables could become quite complex?

from fontkit.

small extension on subsetting outlines: OpenType fonts come in more than just cff and ttf, so for full coverage fontkit will need to deal with CFF, TTF, and EBDT (embedded bitmaps) all three of which have been in OpenType since 1.4, SVG data (OT1.7), and as of OT1.8 also CFF2 (Like CFF, but with all the "this duplicates OpenType metadata" and programming-in-the-outlines bits dropped) and CBDT (colour bitmap data because welcome to 2016, everything is emoji).

@kizu on a practical note, it's usually trivial to have python and node installed on the same machine, and triggering a fontforge operation (which is by far the absolute best offline tool for the job) via node is incredibly easy so while I love simple build systems, there's a lot to be said for "using the right tools for the job". Plus, and this is often forgotten, having the OS manage two processes for different jobs is typically more efficient than having a single process handle everything. I'd also imagine the memory footprint to be lower, but that's a harder claim to back up =) Using python+fontforge as font creation microservice makes a lot of sense though, and then make node talk to it either directly or over a port. Client-side, things are very different (you want a pure JS solution there), but server-side (which is really just "offline") you have a lot more freedom on how to distribute the load and looking at multiple concurrent task runners is actually a good thing. Keeping everything managed by one Node instance negates a number of advantages.

from fontkit.