Re: [ft] Creating an [OT]TF font from BDF font

[David Turner]

Hi George,

I just added support to this new table to FreeType, it's now in the CVS.
This is controled through TT_CONFIG_OPTION_BDF within ftoption.h
(enabled by default, at the moment).

When defined, FT_Get_BDF_Property will work IF you have previously
selected a size that correspond to one of the strikes listed in the BDF table
(i.e. "face->size->metrics.y_ppem" is listed in the table)

Moreover, FT_Get_BDF_Charset_ID works as well, *under* the same
conditions (which is sad, since it's supposed to return results independent
of size).

I'd like to know the following:

- is this feature useful for fontconfig / libXft ? Or should we yank it from
  FreeType ?

- should we update the BDF table format to include size-independent
  data (e.g. the CHARSET_REGISTRY and CHARSET_ENCODING
  atoms). This could be done trivially by using "numStrikes+1" descriptors
  in the first array. The first array item would have ppem == 0 to indicate
  "global" values, instead of size-specific ones.

- I don't understand completely the difference between atoms and non-property
  strings. Aren't these the same things ? Why distinguish them then ?

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)

PS: By the way, your .otb file doesn't display correctly in ftview, I'll try
      to investigate this later...

George Williams a écrit :

On Sat, 2005-12-10 at 00:42, Werner LEMBERG wrote:
  

All of this looks very promising.  I think the final decision on the
table format can only be done after converting a bunch of BDFs forth
and back.
    

Ok. I have a version of fontforge which puts bdf properties into a 
'BDF ' table in an sfnt, and then reads them back and writes them out
into bdf. The data seem to survive the round trip.

I've posted a source tarball
	http://fontforge.sf.net/fontforge_full-20051213.tar.bz2

I've also posted an otb file containing 3 bitmap strikes and a BDF table
	http://fontforge.sf.net/hidden/FixedMedium.otb

On Thu, 2005-12-08 at 16:46, Keith Packard wrote: 
  

I need this + a utility to regenerate BDF files from the TTF so I can
validate a lossless round-trip for the existing BDF files. 
    

A couple of caveats about "lossless" round-trips:
* BDF format supports an (x,y) advance for both horizontal & vertical
metrics
	(ie. it could support Urdu where there is a vertical advance
	 as well as horizontal)
	EBLC metrics only support one advance for each writing
	 direction.
	hmtx/vmtx also only support one advance
 In other words for those rare fonts with an advance vector rather than 
  a simple advance an otb font can't retain that info.(I don't think
  that's an issue for X)

* BDF format supports advances, pixelsizes > 255 pixels
	EBLC metrics don't

* FontForge doesn't really support VVector
   So this data will be lost (I don't think that's an issue for X)

* Each otb file should be single resolution:
   X/BDF can distinguish between
	-gww-caslon-medium-r-normal--12-120-75-75-p-150-iso8859-1
	-gww-caslon-medium-r-normal--12-100-100-100-p-150-iso8859-1
   (same pixel size, but potentially different bitmap patterns because
    designed for different point-sizes at different resolutions)
   But EBLC can only have one strike per pixelsize.

* If FontForge can't recognize the encoding of a font it doesn't know
  how to map glyphs into the cmap table.
=====================================================================
I changed my BDF table proposal, taking out the idea of an array type
and reverting to David's suggestion of treating them as atoms. So here
is my current spec:
/* Format:
	USHORT	version	    : 'BDF' table version number, must be 0x0001
	USHORT	strikeCount : number of strikes in table
	ULONG	stringTable : offset (from start of BDF table) to string
                                 table

followed by an array of 'strikeCount' descriptors that look like: 
	USHORT	ppem	    : vertical pixels-per-EM for this strike
	USHORT	num_items   : number of items (properties and
                                   atoms), max is 255

this array is followed by 'strikeCount' value sets. Each "value set" is 
an array of (num_items) items that look like:
	ULONG	item_name	: offset in string table to item name
	USHORT	item_type	: item type: 0 => non-property string
					 (e.g. COMMENT)
 					     1 => non-property atom
					 (e.g. FONT)
					 (also SIZE even though not
                                           really an atom)
					     2 => non-property int32
					     3 => non-property uint32
					  0x10 => flag for a property, 
						  ored with above value
						  types)
	ULONG	item_value	: item value. 
				strings	 => an offset into the string
					  table of the corresponding
					  string, without the 					  surrounding double-quotes

				atoms	 => an offset into the string
					  table

				integers => the corresponding 32-bit
					  value
Then the string table of null terminated strings. These strings should
be in ASCII.
==================================================================
Comments?



_______________________________________________
Freetype mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/freetype