1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
<HTML>
<HEAD>
<!-- Created with AOLpress/2.0 -->
<!-- AP: Created on: 31-Aug-2006 -->
<!-- AP: Last modified: 2-Sep-2006 -->
<TITLE>Several formats for bitmap only sfnts (truetype files)</TITLE>
<LINK REL="icon" href="ffanvil16.png">
<LINK REL="stylesheet" TYPE="text/css" HREF="FontForge.css">
</HEAD>
<BODY>
<DIV id="in">
<H1 ALIGN=Center>
Several formats for bitmap only sfnts<BR>
<SMALL><SMALL>(the file type which holds a truetype or opentype
font)</SMALL></SMALL>
</H1>
<P>
Unfortunately every system has its own way of storing bitmap only fonts into
an sfnt wrapper (or the system just doesn't support it)
<UL>
<LI>
<A HREF="bitmaponlysfnt.html#Apple">Apple</A>
<LI>
<A HREF="bitmaponlysfnt.html#X11">X11 (Unix/Linux)</A>
<LI>
<A HREF="bitmaponlysfnt.html#MS">MS</A>
</UL>
<H2>
<A NAME="Apple">Apple</A>
</H2>
<P>
Apple documents the existence of a bitmap only format, and gives some hints
about the requirements of it. Their documentation is far from complete and
the following is determined in part by that documentation, in part by examining
the (few) bitmap only fonts of theirs I have found, and in part by error
messages given by some of their tools.
<UL>
<LI>
As is expected on Apple, the bitmap data reside in
'<CODE><A HREF="http://developer.apple.com/fonts/TTRefMan/RM06/Chap6bloc.html">bloc</A></CODE>'
and
'<CODE><A HREF="http://developer.apple.com/fonts/TTRefMan/RM06/Chap6bdat.html">bdat</A></CODE>'
tables.<BR>
(These are identical in format to the
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_eblc.html">EBLC</A></CODE>'
and
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_ebdt.html">EBDT</A></CODE>'
tables used in OpenType)
<LI>
The
'<CODE><A HREF="http://developer.apple.com/fonts/TTRefMan/RM06/Chap6head.html">head</A></CODE>'
table is replaced by a
'<CODE><A HREF="http://developer.apple.com/fonts/TTRefMan/RM06/Chap6head.html">bhed</A></CODE>'
table which is byte for byte identical
<LI>
There are no
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_glyf.html">glyf</A></CODE>',
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_loca.html">loca</A></CODE>'
nor '<CODE>CFF</CODE> ' tables.
<LI>
There are no '<CODE>hhea</CODE>' nor '<CODE>hmtx</CODE>' tables (metrics
data are provided in the bitmap strikes themselves)
<LI>
(Presumably there are no '<CODE>vhea</CODE>' nor '<CODE>vmtx</CODE>' tables
either)
<LI>
'<CODE><A HREF="http://developer.apple.com/fonts/TTRefMan/RM06/Chap6maxp.html">maxp</A></CODE>'.<CODE>numGlyphs</CODE>
is set to the number of bitmap glyphs
</UL>
<H2>
<A NAME="X11">X11</A> (Unix/Linux)
</H2>
<P>
The X consortium have devised their own format which they call "OpenType
Bitmap" with extension .otb.
<UL>
<LI>
The bitmap data reside in
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_eblc.html">EBLC</A></CODE>'
and
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_ebdt.html">EBDT</A></CODE>'
tables.
<LI>
There is a zero length
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_glyf.html">glyf</A></CODE>'
table
<LI>
There is a
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_loca.html">loca</A></CODE>'
table with one entry in it
<LI>
There is a
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_head.html">head</A></CODE>'
table (not a '<CODE>bhed</CODE>')
<LI>
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_maxp.html">maxp</A></CODE>'.<CODE>numGlyphs</CODE>
is set to the number of bitmap glyphs, not to the size of the
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_loca.html">loca</A></CODE>'
table
<HR>
<LI>
The fonts I generate also contain the metrics tables as appropriate
</UL>
<H2>
<A NAME="MS">MS</A>
</H2>
<P>
MicroSoft Windows provides no support for a bitmap only sfnt. So I have created
a faked up format which should work in most cases
<UL>
<LI>
The bitmap data reside in
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_eblc.html">EBLC</A></CODE>'
and
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_ebdt.html">EBDT</A></CODE>'
tables.
<LI>
There are
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_glyf.html">glyf</A></CODE>'
/
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_loca.html">loca</A></CODE>'
tables with entries for every glyph. If used the entries will produce blank
glyphs (spaces).
<LI>
There is an
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_ebsc.html">EBSC</A></CODE>'
table which maps common pixel sizes to the supplied pixel sizes. (so if a
user asked for a 20 pixel strike s/he might get an 18 pixel strike -- as
opposed to getting a set of blanks.
<LI>
There is a
'<CODE><A HREF="http://partners.adobe.com/public/developer/opentype/index_head.html">head</A></CODE>'
table (not a '<CODE>bhed</CODE>')
<LI>
Since these fonts try to look like scalable fonts (to MS anyway) they contain
metrics tables.
</UL>
</DIV>
</BODY></HTML>
|
