I have been developing grid-based PPEM-specific screen fonts for a few years now, building on my work on vector-based bitmap fonts.

But the data in the fonts I am producing is scaled (e.g 60 UPM units per pixel), so the final UPM size is not as small as the design size.

I would be interested in testing if fonts with a 1:1 grid ratio work well in common font engines. Please feel free to drop me an email if you would like to collaborate on some experients, I would be glad to send you some prototype fonts for tests.

Also related: FontStruct, Replica.

I know that many of John Downer's typefaces have been drawn on a relatively course grid. I'm not sure if the fonts actually have a low UPEM setting or if he just snaps each point to some multiple of units, but you might ask him for more information.

On a related topic, Matthew Carter originally designed Charter to take up as little storage space as possible. (He tells a funny story about how, after finishing the design, he was told that the computational restrictions he had designed it for were no longer an issue.) Again, I'm not sure what the UPEM settings are for those fonts, but it might be relevant to your inquiry.

I Think Matt's talking abount low numbers of spacing units, e.g. 18 or 24 typesetter units, not units per em?

Also, when David Berlow designed Prelude for the Palm Pre, he drew on a 512 UPEM because he calculated that even a single character at full screen size couldn’t display much more information than that and so he could keep the font file size considerably smaller as a result.

Not as small a UPEM as you’re talking about, but the same general concept.

I don't get it. Why can restricting UPEM reduce font size significantly, given the current font formats? I think they always use 16 bits to store a coordinate, no matter how many UPEM it is.

I don’t know, but David told me to open Verdana, for example, reduce the UPEM down to 512, and regenerate and see for myself.

Maybe “considerably” smaller was an overstatement on my part. But even a little savings can make a difference when storage space is at a premium.

ahyangyi – Why can restricting UPEM reduce font size significantly, given the current font formats?

TTF's glyf table can store coordinate values either in a byte or in two, depending on how big the value is. So a small UPM and hence smaller coordinate values may make a difference. I assume that CFF, with its different ways to represent integers, allows for similar optimization.

Now this is a topic.
Allow me to allocate a one-hour block, hopefully today.
In the meantime pay close attention to Gustavo. :->

hhp

The effect is not significant, but it’s there.

A quick test:

Postscript 1000 upm: 28kb
Postscript 64 upm: 24kb

Truetype 1000 upm: 92kb
Truetype 64 upm: 84kb

At least for my TT file, I can go even lower with less points (a straight conversion from PS outlines typically introduces more points than you really need), and both formats could be stripped of some extra data.

In any case, you should start from scratch with conditions like these: Draw the type within the boundries with as few points as possible, working the coarse grid to your advantage, rather than downscaling an existing font.

For a specific [text] size, a bitmapfont will always be smaller. The only exception
might be designs with long straight lines (not pretty). Think about it: a pixel in a
bitmap font can be just one bit; in the worst case (if you go for subpixel rendering,
which nobody has done yet AFAIK) a pixel would be 3 bytes*. With outlines, even at
1 byte per x/y coordinate you're looking at for example 8 bytes to define the smallest square. In practice of course you don't define an outline square for each pixel, but
you certainly need more than 3 bytes per end-result pixel.

* And this is only at the edges of the glyph.
The body of the glyph being solid, run-length
encoding** compresses the data to near-nothing.

** What would be great BTW is to compress the
data in vertical columns, since [Latin] glyphs
have long verticals but short horizontals.

Where outlines do save more space is if you reuse the same outline to generate
a large number of sizes; but you have to resort to hinting (and superhinting*)
to coax the outlines to come close to what the bitmap would do. Also, if you
decide that text flow is paramount you have to abandon integer glyph widths,
so bitmaps are out the window, but then the net result is ugly rendering.

* The moving of an individual point in an outline glyph for one ppem.

More than saving space, outlines rule the land now because they save effort.
To me however this is a bit strange, because if you really want to save effort
you shouldn't be designing type in the first place! :-)

Here's the thing: are you making a large number of sizes, or a few?

More:
- Bitmaps don't have to be blocky:
http://www.themicrofoundry.com/manademo/
And that's not even using subpixels.

- CJK fonts as a rule use small UPMs, to save space.

- Downer: I didn't realize an actual coarse grid was used! I always
thought the segmentation was an effect applied at full Em resolution.

- Carter/Charter: the way that design saved space was to use straight
lines for short segments, thus eliminating control point data for those
segments. BTW, there have been font formats (most notably during the
phototype era, but also used by URW to release lo-fi trial versions of
their fonts) that feature straight lines only, and I believe [some] font
rasterization algorithms [still] rely on this when the laser hits the film.

- Amount of savings: one would expect 1-byte data to take up half the
space of 2-byte data, but because of compression this is not the case.

- Hey, here's a crazy idea for saving more space: use lossy compression!

--

In direct competition to Gustavo (a friend from our Ultrafonts days, FYI :-)
I will also offer to work with you. I guarantee we can nail down a killer way
to deliver the best font rendering anywhere at the smallest filesizes. This
might actually involve outlines that mimic bitmaps exactly, but it's the
spirit of the bitmap that shines through and delivers the goods.
hpapazian at gmail dot com

BTW, can you tell I love this stuff? I've been making
screenfonts since 1982, and I don't want to stop. :-)

hhp

...and what good is your whole library of screen fonts? 25 years of pixel picking has taught you nothing at all substatiatable about modern font software but you keep evangelizing your dead end sign. Sizing, scaling and rendering conditions all leave bitmaps as a low-brow solution to a medium-brow problem/opportunity to be solved by intelligent design you've simply never grasped. Sorry if that sounds harsh but your clock is just plain wrong all day.

David, I always value your candor.

On some level you're right. For one thing, unlike you I've never been good
at making money. But it's not that I haven't learned anything about "modern
font software", it's that I think most of what most of the rest of you do is
dead wrong, or at best a cheap shadow of how it should be done. To be fair,
I guess it's really a matter of what drives each one of us, and how much our
particular lives afford us to dream instead of selling street-wise solutions.

I'm quite happy that the type world has you. But it's not what makes my
own clock tick. And tellingly, as I hinted before, if you asked people
like Gates or Jobs, nobody who makes fonts has a working clock.

hhp

As a follow-up to my previous comment about Charter being designed to require less data storage, Matthew Carter tells the story in this interview with Paul Shaw for the Type Directors Club (the story starts around 11:10):
https://vimeo.com/16503883