Discussion:
Creating an [OT]TF font from BDF font
Mark Leisher
2005-12-08 16:26:17 UTC
Permalink
Being lazy, I'm asking here before actually looking around. Can anyone
recommend programs that create [OT]TF fonts from BDF fonts?

I have Taro MURAOKA's bdf2ttf
(http://www.kaoriya.net/dist/bdf2ttf-2.0.tar.bz2), but seem to recall that
someone on one of the Freetype lists might have also written one; I just can't
find the relevant message in my email archive.

The next generation of the http://crl.nmsu.edu/~mleisher/xmbdfed.html editor,
*gbdfed* (not available yet), uses the GTK+ toolkit, so it can be compiled and
run on Windows as well as various species of Unix/Linux. I had a request to
add the ability to create pixel fonts for use with Flash and web pages. So the
plan is to let the user specify a set of strikes to be made into an OTF font.

P.S. Now is a good time to get in your requests for any other features to be
included in gbdfed.

P.P.S. I'm also looking for volunteers to compile and test *gbdfed* on Windows.
--
---------------------------------------------------------------------------
Mark Leisher
Computing Research Lab A sneer is the weapon of the weak.
New Mexico State University -- James Russell Lowell (1819-1891)
Box 30001, MSC 3CRL
Las Cruces, NM 88003
Mark Leisher
2005-12-08 18:46:28 UTC
Permalink
You will find what I believe is the most up-to-date version of
fonttosfnt in the X.Org CVS tree. There's also a version in XFree86,
but I'm not sure it has been kept up to date.
Precisely the answer I was looking for. Thanks, Juliusz.
--
---------------------------------------------------------------------------
Mark Leisher
Computing Research Lab A sneer is the weapon of the weak.
New Mexico State University -- James Russell Lowell (1819-1891)
Box 30001, MSC 3CRL
Las Cruces, NM 88003
Keith Packard
2005-12-08 18:50:06 UTC
Permalink
Post by Mark Leisher
Being lazy, I'm asking here before actually looking around. Can anyone
recommend programs that create [OT]TF fonts from BDF fonts?
Juliusz wrote fonttosfnt which combines multiple BDF sizes into a single
SFNT. It's in CVS at freedesktop.org in the xapps module

$ cvs -d :pserver:***@cvs.freedesktop.org:/cvs/xapps co fonttosfnt

should do the trick. It's reasonably functional, the plan was to use it
to eliminate BDF/PCF fonts from the X distribution and ship only TTF
files. That's been stalled for a couple of years as we need to preserve
all of the mystic BDF properties, and be able to regenerate BDF fonts as
needed (BDF being the only X standard for font distribution).

-keith
Werner LEMBERG
2005-12-09 00:07:15 UTC
Permalink
Juliusz wrote fonttosfnt [...]
[...] the plan was to use it to eliminate BDF/PCF fonts from the X
distribution and ship only TTF files. That's been stalled for a
couple of years as we need to preserve all of the mystic BDF
properties, and be able to regenerate BDF fonts as needed (BDF being
the only X standard for font distribution).
Hmm, why not simply adding a special `BDF ' table which holds all
properties? This should be straightforward, and you get lossless
conversion.


Werner
Keith Packard
2005-12-09 00:46:30 UTC
Permalink
Post by Werner LEMBERG
Hmm, why not simply adding a special `BDF ' table which holds all
properties? This should be straightforward, and you get lossless
conversion.
Yes, this was my plan. I got side-tracked before I managed to implement
it though.

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.

If anyone wants to pick up this little project, I can assure them that
once working, I'll delete all of the BDF files from the X.org CVS
repository and never ship them again, and we'll also deprecate all of
the horrid BDF-based font tools. Note that the X server already happily
loads these .TTF fonts, and will even automatically transcode them to
generate any of the supported encodings, so we actually gain
functionality, reduce disk space usage, reduce code size and eliminate
build-time font compilation. There aren't many projects offering this
kind of win-win-win-win proposition...

-keith
George Williams
2005-12-09 01:46:32 UTC
Permalink
Post by Keith Packard
Yes, this was my plan. I got side-tracked before I managed to implement
it though.
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.
If anyone wants to pick up this little project, I can assure them that
Well I'll certainly make fontforge support a BDF table for otb fonts (ff
can already go bdf->otb->bdf, but it loses the properties -- and then
regenerates the standard ones).

So I presume the BDF table would contain an entry for each strike, and
contain any of the junk between STARTFONT and CHARS?

I propose the following format for the BDF table:
<uint16> 1 #version
<uint16> n #number of strikes
<uint16> offset to start of string/atom table

n instances of the following structure
<uint16> #ppem
<uint16> #offset (from start of BDF table) to information on this
strike

Strike info would look like:
<uint16> ni #count of non-property information
FONT, SIZE, FONTBOUNDINGBOX, COMMENT, etc.
<uint16> np #count of property

ni instances of the following structure
<uint16> #offset from start of string table to atom name
<uint16> #type of data: 0 => atom, 1 => string, 2 => integer
<u/int16> #offset into string table for atom/string, or the value for
integers

np instances of the same structure for the properties.

The string table would be a set of NUL terminated ASCII strings.

(BDF fonts are said to be ASCII. I have seen many containing latin1
characters especially the copyright mark ©. I wonder if these should be
converted to UTF-8? or UCS-2?)
Keith Packard
2005-12-12 21:59:33 UTC
Permalink
Keith,
I'm not quite sure what you mean by ``round-trip'', but that might be
more difficult than you think: as you've surely noticed, fonttosfnt
crops glyphs by default, as there's no reason to propagate X's ``-c-''
fonts into the SFNT world.
I hadn't really worried too much about this as it's purely a local
optimization within the X server and is invisible to applications.

However, if we want to propogate this 'feature', we can have the
sfnt->bdf converter application detect 'ink inside' glyphs with constant
escapements and convert them to char-cell fonts on the fly.
(This can be disabled, though, with the ``-c'' flag.)
This isn't invisible as it affects the metrics seen by applications, a
far more important characteristic than the modest speed improvements
available for terminal emulators.

Thanks for raising the issue though; its important to remember all of
the vageries of the BDF format and its usage over the years by X.

(/me really wishes he'd never raised the issue of ink vs glyph metrics)

-keith
Juliusz Chroboczek
2005-12-12 19:12:41 UTC
Permalink
Post by Keith Packard
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.
Keith,

I'm not quite sure what you mean by ``round-trip'', but that might be
more difficult than you think: as you've surely noticed, fonttosfnt
crops glyphs by default, as there's no reason to propagate X's ``-c-''
fonts into the SFNT world.

(This can be disabled, though, with the ``-c'' flag.)

Juliusz
George Williams
2005-12-09 01:22:21 UTC
Permalink
Post by Werner LEMBERG
Hmm, why not simply adding a special `BDF ' table which holds all
properties? This should be straightforward, and you get lossless
conversion.
Well, you would need a separate sub-table for each BDF strike.
Chia-I Wu
2005-12-09 02:35:13 UTC
Permalink
Hi,
Post by Keith Packard
Juliusz wrote fonttosfnt which combines multiple BDF sizes into a single
SFNT. It's in CVS at freedesktop.org in the xapps module
I tried fonttosfnt some weeeks ago and found that it uses
FT_Bitmap_Size->{height,width} for ppemY and ppemX. Shouldn't it be

ppemX = ppemY = FT_Bitmap_Size->y_ppem?

The reason that ppemX should be equal to ppemY is that an em-sqaure with
unequal ppems means x and y axes are scaled differently so that the
glyphs would look stretched.
--
Regards,
olv
Juliusz Chroboczek
2005-12-12 14:44:38 UTC
Permalink
Post by Chia-I Wu
I tried fonttosfnt some weeeks ago and found that it uses
FT_Bitmap_Size->{height,width} for ppemY and ppemX. Shouldn't it be
ppemX = ppemY = FT_Bitmap_Size->y_ppem?
The reason that ppemX should be equal to ppemY is that an em-sqaure with
unequal ppems means x and y axes are scaled differently so that the
glyphs would look stretched.
I believe that's the expected result.

x/y_ppem are the number of horizontal/vertical pixels by horizontal
em. They should normally be equal, except in the case of bitmap
strikes designed for displays with non-square pixels (such as EGA
displays).

Juliusz
George Williams
2005-12-21 17:36:13 UTC
Permalink
Post by Keith Packard
should do the trick. It's reasonably functional, the plan was to use it
to eliminate BDF/PCF fonts from the X distribution and ship only TTF
files. That's been stalled for a couple of years as we need to preserve
all of the mystic BDF properties, and be able to regenerate BDF fonts as
needed (BDF being the only X standard for font distribution).
I can now convert the bdf properties with fonttosfnt but I neglected to
note that fonttosfnt fails to preserve the bdf SWIDTH values (the
unscaled "PostScript" widths of each glyph).

fonttosfnt can't retain them because there is no API to get them out of
freetype.

So I shall give up on my attempts to produce a round-trip bdf->sfnt->bdf
path based on fonttosfont.

FontForge can provide a round-trip path.
Keith Packard
2005-12-21 18:24:17 UTC
Permalink
Post by George Williams
Post by Keith Packard
should do the trick. It's reasonably functional, the plan was to use it
to eliminate BDF/PCF fonts from the X distribution and ship only TTF
files. That's been stalled for a couple of years as we need to preserve
all of the mystic BDF properties, and be able to regenerate BDF fonts as
needed (BDF being the only X standard for font distribution).
I can now convert the bdf properties with fonttosfnt but I neglected to
note that fonttosfnt fails to preserve the bdf SWIDTH values (the
unscaled "PostScript" widths of each glyph).
Hmm. We want the same effect as FT_LOAD_NO_SCALE; is there some way to
make this work here? Obviously you wouldn't get a bitmap, but you should
be able to see the values in font units.
Post by George Williams
So I shall give up on my attempts to produce a round-trip bdf->sfnt->bdf
path based on fonttosfont.
So this is the only limitation? For purposes of X font distribution,
this might be tolerable as X provides no mechanism to expose SWIDTH in
any case.
Post by George Williams
FontForge can provide a round-trip path.
That's certainly an acceptable alternative; as I said, I'm only
interested in verifying the accuracy of the round-trip so we can discard
the BDF files and distribute only the TTF versions. Those are already
usable by any recent X.Org or XFree86 X server, so it's purely a matter
of ensuring that people running legacy X servers can get at the font
contents through some known mechanism.

-keith
Turner, David
2005-12-09 10:02:18 UTC
Permalink
Hi George,

I think it's a nice proposal, but I'd like to provide an alternative.
The idea being that to avoid two subtables indirections, as well as
the separation of properties/non-properties you made, since I believe
it might be important to re-create a BDF font file with atoms listed
in the correct order:

----------------------------------cut here-------------------------------
the format of the 'BDF' SFNT table is the following:

USHORT version : 'BDF' table version number, must be 0x0001
USHORT strikeCount : number of strikes in table
USHORT stringTable : offset (from start of table) to string table
note that the string table ends at the end
of the BDF table. Each string is 8-bit and
0-terminated.

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:

USHORT item_name : offset in string table to item name
USHORT item_type : item type: 0 => non-property (e.g. COMMENT, FONTBOUNDINGBOX, etc..)
1 => string property
2 => int32 property
3 => uint32 property

ULONG item_value : item value.
non-prop => an offset into the string table
that contain the original text
that followed the item in the
original BDF font

strings => an offset into the string table
to the corresponding string,
without the surrending double-quotes

integers => the corresponding 32-bit value

note also that:

- the string table is always stored after all value sets, i.e.
stringTable = 6 + 4*strikeCount + 6*sum(n in [0..strikeCount-1], num_items[n])

- here's some (unsafe) code to parse the table in order to find properties:

extern FT_Error
find_bdf_property( FT_Byte* bdf_table,
int strike_ppem,
const char* prop_name,
BDF_PropertyRec *aprop )
{
FT_Byte* p = bdf_table + 2;
FT_UInt num_strikes = TT_NEXT_USHORT(p);
FT_Byte* strings = bdf_table + TT_NEXT_USHORT(p);
FT_Byte* strike = p + 4*num_strikes;
FT_UInt num_items = 0;

/* first of all, find the strike */
for ( ; num_strikes > 0; num_strikes-- )
{
FT_UInt ppem;

ppem = TT_NEXT_USHORT(p);
item_count = TT_NEXT_USHORT(p) & 0xFF;

if ( ppem == strike_ppem )
goto FoundStrike;

strike += item_count*8;
}
goto NotFound;

FoundStrike:
p = strike;
for ( ; item_count > 0; item_count--, p += 8 )
{
FT_UInt kind = TT_PEEK_USHORT(p+2);

if ( kind >= 2 && kind <= 4 )
{
FT_Byte* name = strings + TT_PEEK_USHORT(p);

if ( ft_strcmp( name, prop_name ) == 0 )
{
FT_UInt32 value = TT_PEEK_ULONG(p+4);

switch ( kind )
{
case 1: /* string */
aprop->type = BDF_PROPERTY_TYPE_ATOM;
aprop->u.atom = (const char*)(strings + value);
break;

case 2: /* int32 */
aprop->type = BDF_PROPERTY_TYPE_INTEGER;
aprop->u.integer = (FT_Int32)value;
break;

default:
aprop->type = BDF_PROPERTY_TYPE_CARDINAL;
aprop->u.integer = value;
}

return 0;
}
}
}

NotFound:
aprop->type = BDF_PROPERTY_TYPE_NONE;
return FT_Err_Invalid_Argument;
}


What do you think about it ?

- David Turner
- The FreeType Project (www.freetype.org)
-----Message d'origine-----
part de George
Williams
Envoyé : vendredi 9 décembre 2005 02:47
À : Keith Packard
Objet : Re: [ft] Creating an [OT]TF font from BDF font
Post by Keith Packard
Yes, this was my plan. I got side-tracked before I managed
to implement
Post by Keith Packard
it though.
I need this + a utility to regenerate BDF files from the
TTF so I can
Post by Keith Packard
validate a lossless round-trip for the existing BDF files.
If anyone wants to pick up this little project, I can
assure them that
Well I'll certainly make fontforge support a BDF table for
otb fonts (ff
can already go bdf->otb->bdf, but it loses the properties -- and then
regenerates the standard ones).
So I presume the BDF table would contain an entry for each strike, and
contain any of the junk between STARTFONT and CHARS?
<uint16> 1 #version
<uint16> n #number of strikes
<uint16> offset to start of string/atom table
n instances of the following structure
<uint16> #ppem
<uint16> #offset (from start of BDF table) to information on this
strike
<uint16> ni #count of non-property information
FONT, SIZE, FONTBOUNDINGBOX, COMMENT, etc.
<uint16> np #count of property
ni instances of the following structure
<uint16> #offset from start of string table to atom name
<uint16> #type of data: 0 => atom, 1 => string, 2 => integer
<u/int16> #offset into string table for atom/string, or the value for
integers
np instances of the same structure for the properties.
The string table would be a set of NUL terminated ASCII strings.
(BDF fonts are said to be ASCII. I have seen many containing latin1
characters especially the copyright mark ©. I wonder if these
should be
converted to UTF-8? or UCS-2?)
_______________________________________________
Freetype mailing list
http://lists.nongnu.org/mailman/listinfo/freetype
***********************************************************************************
Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the ***@nds.com and destroy the original message.
***********************************************************************************
George Williams
2005-12-09 22:46:33 UTC
Permalink
I realized last night that my proposal was incomplete. I like David's
suggestion of getting rid of my separate lists (for prop/non-prop) and
including that in the type field -- however non-properties can have
non-string values and both properties and non-properties can have arrays
of integers as values.

There is a distinction between keywords that take atoms as values (FONT)
and those which take strings as values (most everything else). I think
that should be maintained.

David suggests storing 32 bit values. I don't see that is needed in a
BDF file... unless we get fonts with ppem around 64k. But perhaps it
would be needed for offsets if there are a lot of strikes. So I'd
suggest changing the offset to the string table to be 32bit too.
Post by Turner, David
I think it's a nice proposal, but I'd like to provide an alternative.
The idea being that to avoid two subtables indirections, as well as
the separation of properties/non-properties you made, since I believe
it might be important to re-create a BDF font file with atoms listed
----------------------------------cut here-------------------------------
USHORT version : 'BDF' table version number, must be 0x0001
USHORT strikeCount : number of strikes in table
ULONG stringTable : offset (from start of table) to string table
Post by Turner, David
Each string is 8-bit and
0-terminated.
the end of the string sub-table will be
the start of the array sub-table.
ULONG arrayTable : offset (from start of table) to array
sub-table
Each array of type LONG and is preceded
by an element count.
the sub-table will end will be the end of
the BDF table itself.
Post by Turner, David
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
USHORT 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)
2 => non-property int32
3 => non-property uint32
4 => non-property array of int32
(e.g. SIZE, FONTBOUNDINGBOX, DWIDTH)
0x10 => flag for a property, ored
with above value types)
Post by Turner, David
ULONG item_value : item value.
strings => an offset into the string table
to the corresponding string,
without the surrending double-quotes
atoms => an offset into the string table
Post by Turner, David
integers => the corresponding 32-bit value
arrays => an offset into the array table
an array starts with an element
count and is followed by that
many signed int32s. So
SIZE 8 75 75
would be stored as
3 8 75 75
Werner LEMBERG
2005-12-10 08:42:56 UTC
Permalink
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.


Werner
George Williams
2005-12-14 05:45:03 UTC
Permalink
Post by Werner LEMBERG
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
Post by Werner LEMBERG
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?
George Williams
2005-12-14 22:30:01 UTC
Permalink
- I don't understand completely the difference between atoms and
non-property
strings. Aren't these the same things ? Why distinguish them then ?
Well 5005.BDF_Spec.pdf says that the thing that comes after the FONT
keyword should be a PostScript name-literal (which has no quotes), while
properties are either integers or quoted-strings.

I have no idea what the significance of this distinction is in the BDF
format, therefore I thought I had better preserve it. You may be right
that there is none.

If anyone can guarantee that it doesn't matter, I'll remove it and say
that non-property strings get no quotes, while property strings need
quotes.
David Turner
2005-12-14 21:16:07 UTC
Permalink
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...
Post by George Williams
Post by Werner LEMBERG
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
Post by Werner LEMBERG
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.
* 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)
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
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
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
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
http://lists.nongnu.org/mailman/listinfo/freetype
Keith Packard
2005-12-15 00:33:45 UTC
Permalink
Post by David Turner
- is this feature useful for fontconfig / libXft ? Or should we yank it from
FreeType ?
It's not terribly useful for fontconfig or libXft, where it is useful is
in converting sfnt back into BDF files in case you want to take a font
and use it with old non-TTF supporting X servers.
Post by David Turner
- I don't understand completely the difference between atoms and
non-property
strings. Aren't these the same things ? Why distinguish them then ?
All I care about is regenerating a matching BDF file; I'd like to see
whatever it takes to preserve every aspect of the original font files.

-keith
Keith Packard
2005-12-21 17:03:10 UTC
Permalink
Post by Keith Packard
It's not terribly useful for fontconfig or libXft, where it is useful is
in converting sfnt back into BDF files in case you want to take a font
and use it with old non-TTF supporting X servers.
Well, that you already can do, using fstobdf (it's still in the tree,
right?). Now, if there are clients that still make use of ad hoc font
properties, they should be shot.
Right, we can easily generate a BDF file, but without some place to
store the properties that only BDF exposes in the TTF file, we'll lose
some data. It's probably not terribly important data, but I think saving
all of it is a prerequisite for switching from BDF to SFNT files as the
canonical delivery and archival mechanism.

-keith
George Williams
2006-01-16 04:39:17 UTC
Permalink
I've finally released a build of fontforge containing the code for the
'BDF ' sfnt-table.

I'm attaching two (fontforge) scripts that can be used to convert a
bunch of bdf/pcf files into an otb and back to bdf files.

$ fontforge -script bdf2sfnt.pe outputfile.otb strike1.bdf [strike2.bdf ...]
$ fontforge -script sfnt2bdf.pe baseoutputname.bdf input.otb

The first coagulates all the bdf/pcf strikes given on the command line
and then produces an otb file named "outputfile.otb".
The second takes all strikes out of the input file (otb, ttf, otf) and
generates a series of bdf files with names like
"baseoutputname"-<pixelsize>.bdf
Werner LEMBERG
2006-01-17 05:45:27 UTC
Permalink
Post by George Williams
I've finally released a build of fontforge containing the code for
the 'BDF ' sfnt-table.
In connection with that I wonder which of your patches you've sent to
the list shall go into FreeType.
Post by George Williams
I'm attaching two (fontforge) scripts that can be used to convert a
bunch of bdf/pcf files into an otb and back to bdf files.
BTW, have we finally decided that such fonts have the extension .otb?
This might be worthwhile to mention in the FreeType docs and to add to
the demo programs.


Werner
George Williams
2006-01-17 23:12:35 UTC
Permalink
Post by Werner LEMBERG
In connection with that I wonder which of your patches you've sent to
the list shall go into FreeType.
I rather think none. The more I looked into it the more changes I needed
to make to the bdf loader to avoid losing information, and eventually I
decided that freetype wasn't the right place for all that junk. It would
cumber the library with a bunch of junk only useful for font2sfnt
Post by Werner LEMBERG
BTW, have we finally decided that such fonts have the extension .otb?
This might be worthwhile to mention in the FreeType docs and to add to
the demo programs.
I was told so when I implemented them in fontforge. But I wasn't in the
initial discussions so I'm not the best source.
Werner LEMBERG
2006-01-17 23:45:03 UTC
Permalink
Post by Werner LEMBERG
In connection with that I wonder which of your patches you've sent
to the list shall go into FreeType.
I rather think none. The more I looked into it the more changes I
needed to make to the bdf loader to avoid losing information, and
eventually I decided that freetype wasn't the right place for all
that junk.
Do you think that the current support in FreeType for a `BDF ' table
is sufficient? Or shall we remove it altogether? Is there any useful
information in the BDF properties which can't be preserved during
conversion to OTB?


Werner
Keith Packard
2006-01-17 23:29:24 UTC
Permalink
Post by George Williams
I was told so when I implemented them in fontforge. But I wasn't in the
initial discussions so I'm not the best source.
I also recall discussions which discovered that the .otb extension was
otherwise unused in most of the world. It doesn't matter at all to me; I
ask FreeType to try and open the font, completely ignoring the extension
has proven a valuable property, although it does sometimes challenge the
FreeType font file handling code with 'unusual' file data.
--
***@intel.com
Werner LEMBERG
2006-01-18 06:04:38 UTC
Permalink
Post by Keith Packard
I also recall discussions which discovered that the .otb extension
was otherwise unused in most of the world. It doesn't matter at all
to me; I ask FreeType to try and open the font, completely ignoring
the extension has proven a valuable property, although it does
sometimes challenge the FreeType font file handling code with
'unusual' file data.
I fully agree, but Windows allows to hide the display of file name
extensions -- the demo program might also try `foo.otb' to find the
real file name if the user just gives `foo'.


Werner
Juliusz Chroboczek
2006-01-17 17:59:04 UTC
Permalink
Post by Werner LEMBERG
BTW, have we finally decided that such fonts have the extension .otb?
This was discussed on the xfree86-fonts and -devel lists a long time
ago (before the events), and this was definitely the best suggestion.
In particular, it was only used by one obscure piece of MS-DOS software,
and works on 8+3 filesystems.

So I guess you might as well adopt this extension, unless someone
objects loudly.
Post by Werner LEMBERG
This might be worthwhile to mention in the FreeType docs and to add
to the demo programs.
Aye.
Juliusz

Juliusz Chroboczek
2005-12-21 14:18:02 UTC
Permalink
Post by Keith Packard
It's not terribly useful for fontconfig or libXft, where it is useful is
in converting sfnt back into BDF files in case you want to take a font
and use it with old non-TTF supporting X servers.
Well, that you already can do, using fstobdf (it's still in the tree,
right?). Now, if there are clients that still make use of ad hoc font
properties, they should be shot.

Juliusz
George Williams
2005-12-15 04:13:12 UTC
Permalink
Post by David Turner
PS: By the way, your .otb file doesn't display correctly in ftview, I'll try
to investigate this later...
I believe this is because the three strikes I used to build the otb file
have different character sets -- none of which is complete. So the 14
pixel strike says it "fails" because it does not contain U+0180 while
the 16 pixel strike does contain it. The 16 pixel strike is lacking
U+02B0 (present in the 24 pixel strike) and the 24 pixel strike is
lacking U+060c (present in the 16 pixel strike). And so on.

I had assumed they'd all have the same character set since they had the
same name, but I guess they don't.

As far as I can tell, it displays the glyphs that exist correctly, but
complains about glyphs not in the current strike.
Juliusz Chroboczek
2005-12-08 18:29:06 UTC
Permalink
Post by Mark Leisher
Being lazy, I'm asking here before actually looking around. Can anyone
recommend programs that create [OT]TF fonts from BDF fonts?
[I] seem to recall that someone on one of the Freetype lists might
have also written one;
You may be thinking of my fonttosfnt. It does something completely
different: it takes a BDF font (or any other format grokked by
FreeType), and produces a bitmap font in a SFNT wrapper, commonly
known as a ``bitmap-only TTF font''.

Such fonts are not TTF fonts, they are just a way of representing
bitmap data in the hightly-efficient (both space and time) SFNT
format. Another way of looking at it is that they are TTF fonts that
happen to lack outline data, and only have embedded bitmaps.

Both FreeType and your favourite X server grok such fonts.

While I warmly recommend that gbdfed should support generating such
fonts (fontforge already does), this might or might not be what you
want.

You will find what I believe is the most up-to-date version of
fonttosfnt in the X.Org CVS tree. There's also a version in XFree86,
but I'm not sure it has been kept up to date.

Juliusz
George Williams
2005-12-16 22:16:47 UTC
Permalink
You will find what I believe is the most up-to-date version of
fonttosfnt in the X.Org CVS tree. There's also a version in XFree86,
but I'm not sure it has been kept up to date.
I downloaded fonttosfnt from x.org's cvs repository.

I build my little test case (same one ff generated) using this
fonttosfnt. Neither fontforge nor ftview would read the result.

This turned out to be because the faces have different x_ppem and
y_ppem, while the original bdf fonts have the same x/y resolution.

I believe this problem occurs because the call to makeStrike in read.c
uses face->available_sizes[i].width when it should be using
face->available_sizes[i].x_ppem>>6.

So I suggest the following patch (I have no write access to the cvs tree
myself) -- there are several other uses of
face->available_sizes[i].width which may also need to be changed, but
with this patch I can now produce a font which loads.
George Williams
2005-12-16 23:14:46 UTC
Permalink
You will find what I believe is the most up-to-date version of
fonttosfnt in the X.Org CVS tree. There's also a version in XFree86,
but I'm not sure it has been kept up to date.
I believe the entrySel field in the table directory of the output sfnt
is off by 1.
Alan Coopersmith
2005-12-17 01:55:33 UTC
Permalink
Post by George Williams
I downloaded fonttosfnt from x.org's cvs repository.
So I suggest the following patch (I have no write access to the cvs tree
myself)
To get patches into code in X.Org's CVS, please file bug reports at:

https://bugs.freedesktop.org/enter_bug.cgi?product=xorg

and then use the "Create Attachment" link in the resulting bug report to
attach the patch to it.
--
-Alan Coopersmith- ***@sun.com
Sun Microsystems, Inc. - X Window System Engineering
George Williams
2005-12-17 13:32:50 UTC
Permalink
Post by Alan Coopersmith
https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
and then use the "Create Attachment" link in the resulting bug report to
attach the patch to it.
Thank you.
Loading...