Interesting.
How will the type change based on "truthfulness"?

As for screen design:
1) Ignore print - it will reduce the quality of your screen work. Don't make an outline font unless you have to.
2) Figure out what vertical span (in pixels) you'll have.
3) Figure out how horizontally economical the font has to be.
4) Try to get a handle on the types of fidelity loss you'll encounter, and design with that in mind, like by incorporating trapping* (which is not just for outline fonts - video "bleeds" too).
5) Define the types of emphasis you need (noting that the traditional method -italics- is lousy onscreen).
6) Use grayscale pixels if you can.

There's a lot of precedent for video fonts**, but to me none of them are really good enough - you have a chance to break promising new ground.

* http://www.themicrofoundry.com/ss_trapping1.html

** Like this: http://www.myfonts.com/fonts/bitstream/tiresias/

hhp

Yes I am familiar with Letterror's Twin typeface. I do not have the capabilities of a group like that, but i guess i hope to bring something similar to that to fruition.

Hrant, was hoping you would respond. You comments were what I was hoping for. Some of your thoughts I have also conjured, but with my limited knowledge I had not the way to state them as eloquently as you had.

I am going to survey them more tomorrow since it is very late and i need to go to bed.

Thank you both.

jp

I was looking in depth at the basic construction of a bitmap font and wanted to know more about the correaltion between the size of the squares used for example by Silkscreen (which is only used optimally at 8 pt) and its .014 in. square that builds the form.

Looking at my options and the time I have my approach will probably take this course. Using a set grid, design a screen-based font that will have a set base alphabet and at least one parallel-varied set that shows the effects of untruthful statements with a varying line width, extended stems, enlarge counters, etc... It probably will not be optimal to read at the size needed for a closed captioning system, but I hope my main idea will still come across.

Maybe in the future I can extend the family and incorporate more of the research into it.

Any other encouraging information is welcome though if you feel I can accomplish the fuller idea or verison of it in a smaller time frame.

josh

There are two main kinds of bitmap fonts:
1) "True" bitmap fonts where the actual pixel data is defined in bits. These are either stand-alone (like in the FON format) or embedded (in a TT font). These fonts only show up when their pre-defined pixel height is chosen. True bitmap fonts have unfortunately become second-class citizens in terms of support, especially on MacOS.
2) Pixelfonts (like Silkscreen), which are basically outline fonts that can be used at any point size, but which map out the correct bitmap data only when a certain point size is chosen. Pixelfonts have robust support, because the OS doesn't know the difference.

In a pixelfont the point size you need to use to make the bitmap come out right depends on the ratio of the outline pixel squares to the em size of the font. For example if you fix the target point size to 8 and make the "pixels" 125 em units square, you can build a bitmap font of any vertical span you want and it'll come out right when the font is set to 8 point. This might seem counter-intuitive, but it avoids the user having to fish around for the right point size that will make the font snap into place.

hhp

Is there a sliding scale I can use to say make a 20 pt type?

I feel I really need to experiment before I can completely understand this. My mathematical wisdom went out the window a long time ago.

I'm going to get to work with the best of the knowledge gained and will definitely post while working.

jp

For 20 pixels high defining em & pixel sizes that map to 8 point is probably a bad idea, because your outlines would go more than twice over the vertical limit. What you might do instead (especially since this font seems to be for "controlled" use only) is define a normal em of 1000, and use pixels of 50 units square: that way you'd just chose "20 point" (at 72 dpi) and it would map out perfectly.

Call it "Icosa". :-)

hhp

Hrant,
you wrote:
"In a pixelfont the point size you need to use to make the bitmap come out right depends on the ratio of the outline pixel squares to the em size of the font. For example if you fix the target point size to 8 and make the "pixels" 125 em units square, you can build a bitmap font of any vertical span you want and it'll come out right when the font is set to 8 point. This might seem counter-intuitive, but it avoids the user having to fish around for the right point size that will make the font snap into place. "

While this is not inaccurate, it leaves out an important issue: the UPM size. Your calculations assume a UPM size of 1000.

The whole trick of the size of the grid (i.e. "vector pixels") is:

One side: At 72 dpi, the point size that you require is equal the ppem size of the font, i.e. the number of pixels that the emsquare will consist of, e.g. 8.

Other side: Your font's emsquare is built of a certain amount of of units, typically 1000. So we speak of 1000 UPM (units per em).

Since 8 pixels correspond to 1000 units, 1 pixel corresponds to 1000/8 = 125 units. This is really simple math.

However, note that if you use FontLab to create a font in TrueType format, you will be able to choose any number as your UPM size. Therefore, you can as easily set your UPM size to 800 and target for a 8 pixels type size, so that one pixel corresponds to 800/8 = 100 units.

Similarly, if you target a 20 pixels type size, you can use a UPM 1000 and then one pixel will correspond to 1000/20 = 50 units, but you can also use a UPM 200 and then one pixel will correspond to 200/20 = 10, or a UPM 2000 and then 2000/20 = 100.

Keeping this in mind, you will be able to easily target "untypical" font sizes such as 13 pixels.

Adam Twardoch
Fontlab Ltd.

You're right about my assumption.
But there's a reason to stick with 1000: unlike TT, that's the only size PS can handle.

hhp

(Wow, I am going to break my "never reply to Hrant" rule for the first time in months.)

That's not true. Type 1 (and OpenType CFF) fonts can be built at any em scale, as long as all points and metrics are within +/- 4096 units.

Additionally, specifying size in points for a font intended to be used on screen is meaningless, unless the output device is also defined. There's a good reason folks developing screen fonts talk about size in ppem (pixels per em). This does correspond to points in classical Mac-speak, but the conversion from ppem to points involves multiplying by 3/4 for classical Windows-speak. That is to say, 12 ppem equals 12 point on Mac, but 9 point on Windows. If you want to optimize something for "12 point display" on both Mac and Windows, you need to optimize both the 12 and 16 ppem sizes.

Cheers,

T

(Congratulations.)

I guess the limitation then is only when Fontographer exports PS?
Can FontLab export PS fonts with different ems?

hhp

Latest versions of FontLab, or at least versions in development, can. (It seems like I'm always on a pre-release version to get the latest bug fixes, so it's hard for me to keep this straight.) I recall that earlier versions could not, but we pointed out that it really was okay to use other ems, and it got changed.

I didn't remember that Fontographer had a limitation in this area, but then it's been a lot of years since I've used it, and this is a rarely-trod path.

T

So another -more important- question:
Would any notable apps (especially legacy ones) have a problem with non-Em=1000 PS fonts?
(Thanks.)

hhp

Not that I am aware of, no.

T

You might be interested in the book/project Metro Letters: A Typeface for the Twin Cities. The project's winner was Letterror. They are programmer's extraordinaire. The presentation was beyond amazing. Their typeface is programmed to show among other things Weather and Wind. More applicable to your research is how they demonstrated noise.