Typophile - Question about OT Scripting and file size - Comments

Me too. This was a very

Eben Sorkin — Fri, 6 Jun 2008 11:28:55 -0700

Me too. This was a very useful thread!

Hello Miguel, very belated

k.l. — Fri, 6 Jun 2008 07:16:58 -0700

Hello Miguel, very belated thanks for the information! Karsten

When I was a kid, we had to

charles_e — Wed, 4 Jun 2008 17:42:17 -0700

When I was a kid, we had to walk 5 miles through the snow to get to school, uphill both ways . . .

But actually, I did start withe a PC-XT — which used the 8088 chip. We typeset using TeX. The way you did it was to kick off your files when you went home at night; it took about 6 hours to run a typical book. Last time I used TeX, the same chore would take around a minute.

I’m not a machine oriented guy, but the moral is it may seem a bit slow today; it won’t be tomorrow.

Now all I gotta figure out is how Nick got one of my Photoshop files (and Nick, add that you’re using the 16-bit mode for the intermediate, working file . . .)

There is a lag time in

Nick Shinn — Wed, 4 Jun 2008 15:52:05 -0700

There is a lag time in opening up a file, or changing a font, when a font with a lot of contextual lookups is involved.

A user might think this is an issue with the font, but probably not, as the wait time is quite short compared to, say, opening a gigabyte Photoshop file with dozens of layers.

Speaking of optimization,

Miguel Sousa — Wed, 4 Jun 2008 14:45:58 -0700

Speaking of optimization, Read Roberts explained to me that there’s not much a font developer can do to reduce the font file size. If the designer really thinks that the typeface is better served by having 30 OpenType features implemented in the font, or 20 contextual lookups, then there’s no way you can compress that data to become half its size. Surely, sometimes lookups can be shared between features (e.g. you can define a lookup to be used by ’subs’, and then reference that same lookup in ’sinf’), but for the most part each feature has its own unique lookup.

Having said that, from a text engine point of view, contextual lookups will definitely make a bigger dent on the processing performance than one-to-one lookups do, obviously. So, if you need to use contextual lookups try to keep their number low and each context as short as possible. (Contextual lookups are like regular expressions, the more complex they are, the longer they take to process. No way to avoid that.)

Of course there are some good practices a font developer should observe, which will help keep the font file size low. A simple one is to arrange the glyphs in the font into groups. So for example, putting the a–z glyphs into a continuos range, and then ordering their corresponding small cap glyphs (a.sc–z.sc) in the same way, will keep the size of the lookup generated by this substitution rule,

sub [a b c ... y z] by [a.sc b.sc c.sc ... y.sc z.sc];

at its minimum. This is because the GID ranges will be continuos and the offset from the original glyph to the resulting glyph is constant. I should stress that the secret to make this work relies on the way the glyphs are ordered throughout the font, not the way the features are written. This means that, if the glyphs are neatly ordered in the font, it doesn’t matter if you use the code above, or any of the substitutions below.

sub [z y ... c b a] by [z.sc y.sc ... c.sc b.sc a.sc]; sub [c y a ... z b] by [c.sc y.sc a.sc ... z.sc b.sc];

Actually, recently I did an experiment in this area with one of our biggest Western fonts, Arno Pro. I took the original GlyphOrderAndAliasDB file, randomized the order of its lines (with the exception of the first line which must correspond to the .notdef glyph), and rebuilt one of the Italic fonts. Keep in mind I didn’t change anything else; the OT code used, the PFA source font and all the supporting files were exactly the same. The results were interesting: 9% increase of the file size (460Kb to 504Kb). I guess the takeaway is, it pays-off to spend some time rationalizing the glyph order.

> Do you know in which

Miguel Sousa — Wed, 4 Jun 2008 12:59:57 -0700

> Do you know in which version this was fixed?

It was fixed in OS X 10.4.9, http://support.apple.com/kb/HT1525 This problem only affects name-keyed OT-CFF fonts. Here are some screenshots I took at that time. Don’t try this at home! The likelihood of getting a kernel panic is quite high.

Must have to do with our

k.l. — Wed, 4 Jun 2008 07:51:44 -0700

Must have to do with our initials.

Karsten, I’m still running

kentlew — Wed, 4 Jun 2008 06:02:43 -0700

Karsten, I’m still running OSX 10.3.9 also. ;-)

Thomas — 1) Mac OS used to

k.l. — Wed, 4 Jun 2008 02:09:57 -0700

Thomas — 1) Mac OS used to have a limit on the total length of glyph name strings, as well. That has been fixed at some point.

Do you know in which version this was fixed? I wonder if we need to pay tribute to this issue in future ...
My impression is that someone who wants to use an ultra-plus font simply needs to accept some minimal system requirements — like with any other piece of software too. (And me being the last OSX 10.3 user anyway.) :)

Karsten

I must confess that large

sergeym — Wed, 4 Jun 2008 00:23:37 -0700

I must confess that large size of GSUB table in presence of complex lookups is the result of VOLT compiler not doing enough optimization work. As I understand, AFDK is doing better job. But contextual lookups usually do not have functional problems (resulting table may be too big for my taste, but will still work), positioning is much more problematic.

But this does not make John’s work less complex and less amazing. Besides quality, his fonts are always my best VOLT testbed :).

Sergey

Surely this is a ’Build’

Eben Sorkin — Tue, 3 Jun 2008 19:34:21 -0700

Surely this is a ’Build’ question?

Quite so. Thanks for moving it, whoever that was!

I had sort of assumed that what you have said here was so, but then I realized that it was quite an assumption to be leaning on if it was false. So, thanks John!

PPS. Surely this is a

John Hudson — Tue, 3 Jun 2008 17:35:54 -0700

PPS. Surely this is a ’Build’ question?

PS. All my OTL work is done

John Hudson — Tue, 3 Jun 2008 17:33:31 -0700

PS. All my OTL work is done in VOLT, so I don’t know what kind of tool issues you might hit with FontLab/FDK.

I’m playing with

John Hudson — Tue, 3 Jun 2008 17:32:35 -0700

I’m playing with interleaved contextual and stylistic set stuff for display type that goes way beyond anything that I would anticipate in a text face, and I have not hit any size limits in terms of software support — at least not in my test environments, which in this case are InDesign and WPF —, although I have hit (anticipated) feature implementation issues. Sergey Malkin at MS confirms that my VOLT source for this project is the largest and most complex he has seen (a record I previously held with SBL Hebrew), and the GSUB table takes up something like 40% of the compiled font. This is the stuff I’ll be showing at TypeCon this year.

I can’t imagine anything on that magnitude being necessary in a text face, even presuming that some characters have multiple forms for improved fit. Also, from my perspective there is an important net gain in not using ligature glyphs any more, since it massively simplifies the GPOS mark positioning work.

There’s a 64K limit on the

Thomas Phinney — Tue, 3 Jun 2008 17:09:15 -0700

There’s a 64K limit on the size of a subtable offset (I think I have that right). This can be worked around with the “extension” function and appropriate subtable breaks, although not all possible clients will recognize that. Usually this comes up with kerning for really big fonts (e.g. Arno Pro).

There are a couple of size limits related to glyphs rather than features, as well:

1) Mac OS used to have a limit on the total length of glyph name strings, as well. That has been fixed at some point.

2) There’s the limit of 64K glyphs in the font.

Regards,

Question about OT Scripting and file size

Eben Sorkin — Tue, 3 Jun 2008 14:15:58 -0700

I was thinking about the practical issues involved in using Calt/Liga for text faces today, and I started wondering about how much larger a file might be if it has has 10, 50, 100, 1000 or 10,000 feature entries. And what the real practical limitations might be in terms of the file size, for the Operating System (OSX, Windows Vista, XP etc.) , and applications, any one of which might potentially choke on an overly big file. Maybe file size per se isn’t the only technical issue. I am BTW deliberately leaving out any mention of managing large #s of features which is essentially a different issue.

It’s a broad question, and I know the answers are probably very specific and potentially very case dependent.

Still, what is your take on this? Have you run into problems regarding this kind of thing as an OS, application, or font developer you would like to share?