Sophie: fontforge-1.0-1.20120731.9.mga5 i586

fontforge-1.0-1.20120731.9.mga5.i586.rpm

<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="fftype16.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>