|Subject:||Re: [ft] Creating an [OT]TF font from BDF font|
|Date:||Wed, 14 Dec 2005 22:16:07 +0100|
|User-agent:||Mozilla Thunderbird 1.0.2 (Windows/20050317)|
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
I'd like to know the following:
- is this feature useful for fontconfig / libXft ? Or should we yank it from
- 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
|[Prev in Thread]||Current Thread||[Next in Thread]|