It seems no one has ever made something like this?…

Until very recently, almost all East Asian fonts used embedded bitmaps for text sizes. There are ‘bitmap factories’ in China and Japan where dozens of people work on single fonts, creating bitmaps for key sizes. Because of the complexity of the forms and the difficulty of their interpretation at small sizes, making bitmaps has until recently been more efficient than the kind of hinting models used for most other scripts. Microsoft’s new Japanese face Meiryo (to be released with Longhorn), is one of the first East Asign TTFs to use hinting exclusively and include no embedded bitmaps.

Have you looked at FontLab’s BitFonter? I don’t know whether it handles CJKV encoding, but it is generally regarded as the best bitmap font editor, and supports more bitmap font formats than any other tools.

John, I think Azul wants to make pixelfonts, not hinted outlines or true bitmaps. The main reason might be that only pixelfonts work reliably across platforms and apps (if only for one single size per font), especially in something like Flash.

hhp

I’m not sure that I understand the distinction between a bitmap font and a pixelfont. Can you explain?

A pixelfont is basically an outline font made of “blocks” that fall where the pixels would be (at a certain point size), rendering out the “intended” bitmap. A hack of sorts, but sadly the only way much of the time.

hhp

Ah. From Azul’s description (‘i design my characters by dotting pixel-by-pixel, using Windows “Paint” program, and save into bitmap files’), I’d presumed he was wanting to make a bitmap font. In any case, if he is designing bitmaps and wants to produce a pixelfont as you describe it, he’s probably going to want to trace his bitmaps. In the upcoming FontLab Studio 5.0, he’ll be able to import his bitmaps into the background layer and trace them (ScanFont’s trace tool is incorporated into FL5).

You can use BitFonter 2.0 from Fontlab Ltd. (http://www.fontlab.com ) to design bitmap fonts. It is fully Unicode-compatible. With Fontlab’s TypeTool 2 or AsiaFont Studio 4, you can create (outline-based) pixelfonts from these bitmap fonts. They all support up to 65,535 glyphs and the BMP portion of Unicode (unicodes <0xFFFF).

Regards,
Adam Twardoch
Fontlab Ltd.

Thanks for your replies!

Right… vector-base might be too heavy for Chinese/Japanese character set, because one need to render 10000+ chars, already a hard job for pixel fonts. That’s why there’re only few typical Chinese fonts, but a bunch of beautiful fancy English fonts.

Thanks for telling the difference of “pixelfont” and “bitmap font”, before i thought they’re the same thing.
In fact i plan to create a “bitmap font” first. It’s easiest to make. Pixelfont need more skills, but it can have more usage and would be the next step.

I also notice BitFonter, and guess it will be suitable… but its Windows version is still under development. Anyway i’ll wait for it.

> vector-base might be too heavy

Do you mean the file-size would be too large? It would certainly be larger than a bitmap, but maybe still small enough. People do use monstrously large full-outline Chinese fonts after all.

Or do you mean the effort would be too much? Not if you do what Adam described: it’s mostly automated.

> That’s why there’re only few typical Chinese fonts

Yes, that’s certainly one reason.

> It’s easiest to make.

But won’t work in MacOS or Flash. :-(

hhp

Adam, can one run Flashfonter on a large Chinese TTF? Are there any size limits to what Flashfonter can produce? Any encoding issues?

Note that Fontflasher (not Flashfonter, right?) works from a “normal” outline font to make a pixelfont. On the other hand, it might actually work fine from a blocky autotrace of a bitmap font background…

hhp

Oh yes, it is FontFlasher now. When Yuri first demo’d it at ATypI in Vancouver it was FlashFonter. I guess they decided that might impinge on Macromedia’s Flash trademark.

it might actually work fine from a blocky autotrace of a bitmap font background

It might, yes, but my questions to Adam were not directly related to Azul’s project. I just wondered whether one could make a pixelfont from a large Chinese TTF — e.g. one of the Windows system Chinese fonts — using FontFlasher.

Such pixelfonts raise interesting issues: one would be hard pressed to mount an intellectual property challenge to them because they are derived from bitmap output of the original font, not from data or code in the font. But at the same time they leverage the value of that font and the work that has gone into it to make it produce those specific bitmaps. In the past, we’ve had a number of discussions on this forum about things that are legally prohibited (e.g. decompiling fonts in contravention of some license agreements) but which some participants find ethically acceptable. With pixelfonts derived from (someone else’s) original TT font, we have an example of something that is seemingly perfectly legal, but which seems to me ethically questionable if one were to market such pixelfonts as commercial products.

> they are derived from bitmap output of the original font

Are they, or are they “blockified” from the outlines? If the font has no/lousy hinting resulting in bad bitmaps, does the resultant pixelfont exhibit those defects too?

But really, either way, I agree that there are ethical issues that need to be considered (if pragmatically).

hhp

If the font has no/lousy hinting resulting in bad bitmaps, does the resultant pixelfont exhibit those defects too?

FontFlasher makes size specific pixelfonts, which means that it is wrapping ‘blocks’ to pixels in a device-dependent way, i.e. to bitmap output at specific ppms. You can’t wrap to pixels without rasterising.

But what if instead of “wrapping to pixels” it’s taking the original outlines and adding/moving points as needed to render out the “correct” pixels at a certain size? Anyway, I actually suspect you’re right, but I don’t think it’s 100% certain. Adam?

hhp

FontFlasher principally works fine with any Unicode font and should also work on very large fonts. I’m currently travelling so I cannot verify if there are any limitations. FontFlasher doesn’t preserve the glyph naming, if you generate the font in Unicode mode then all glyphs (even those in AGL) get the names uniXXXX, so most likely, you’d need to do Generate Names in FontLab. And note that FontFlasher requires one of Fontlab Ltd.’s editors (TypeTool, FontLab, Asia FontStudio) to produce a working font.

FontFlasher exists on Mac and Windows. BitFonter only exists on Mac.

It should be also noted that it might be actually a good idea to produce a Chinese pixelfont, but not in TrueType format but in OpenType PS format. The subroutinization performed when an OpenType PS font is generated can greatly reduce the size of a Chinese pixelfont in that format. Note however, that generating such fonts with subroutinization enabled make take a LOT of time so for development processes, it’s good to turn subroutinization off — can be done in FontLab’s options.

Regards,
Adam

But what if instead of “wrapping to pixels” it’s taking the original outlines and adding/moving points as needed to render out the “correct” pixels at a certain size?

But how would it know what constitutes ‘correct’ pixels? This is the whole crux of hinting: someone — a human being — needs to determine what a correct bitmap looks like at a given size. If an application could correctly guess what the bitmap should look like at all sizes, there would be no need for manual hinting at all and we could automate the whole process. But the smaller the ppem size, the more we (still) rely on human decision making.

FontFlasher uses the font’s bitmaps as delivered by the OS. So on Windows, for TrueType fonts it uses the Microsoft TrueType rasterizer with hinted or embedded bitmaps, for Type 1 fonts it uses ATM in b/w rendering. On Mac OS 9, it uses the Apple TrueType rasterizer and ATM, respectively. On Mac OS X, it uses the the Apple ATSUI rasterizer for all types of outline.

Regards,
Adam