[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
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 ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Thu, 2005-12-08 at 09:26 -0700, Mark Leisher wrote: 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:[EMAIL PROTECTED]:/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 signature.asc Description: This is a digitally signed message part
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Fri, 2005-12-09 at 01:07 +0100, Werner LEMBERG wrote: 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 signature.asc Description: This is a digitally signed message part
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Thu, 2005-12-08 at 16:46, Keith Packard wrote: 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?) ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] RE: [ft] Creating an [OT]TF font from BDF font
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
ULONGitem_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_UIntnum_strikes = TT_NEXT_USHORT(p);
FT_Byte* strings = bdf_table + TT_NEXT_USHORT(p);
FT_Byte* strike = p + 4*num_strikes;
FT_UIntnum_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_UIntkind = 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-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] la
part de George
Williams
Envoyé : vendredi 9 décembre 2005 02:47
À : Keith Packard
Cc : freetype@nongnu.org; fonts@xfree86.org
Objet : Re: [ft] Creating an [OT]TF font from BDF font
On Thu, 2005-12-08 at 16:46, Keith Packard
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
So I'd like to make the following changes to David's proposal: 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 ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Wed, 2005-12-14 at 22:16 +0100, David Turner wrote: I'd like to know the following: - 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. - 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 signature.asc Description: This is a digitally signed message part
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
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
___
Fonts mailing list
Fonts@XFree86.Org
http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
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 ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Wed, 2005-12-21 at 15:18 +0100, Juliusz Chroboczek wrote: 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 signature.asc Description: This is a digitally signed message part
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Wed, 2005-12-21 at 09:36 -0800, George Williams wrote: On Thu, 2005-12-08 at 10:50, Keith Packard wrote: 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. 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. 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 signature.asc Description: This is a digitally signed message part
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
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. This might be worthwhile to mention in the FreeType docs and to add to the demo programs. Aye. Juliusz ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Tue, 2006-01-17 at 15:12 -0800, George Williams wrote: 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. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
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 ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
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 bdf2sfnt.tgz Description: GNU Zip compressed data
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Thu, 2005-12-08 at 10:50, Keith Packard wrote: 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. ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Fri, 2005-12-16 at 17:55, Alan Coopersmith wrote: 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. Thank you. ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Thu, 2005-12-08 at 10:29, Juliusz Chroboczek wrote:
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_ppem6.
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.
*** read.c~ 2005-12-16 14:04:44.0 -0800
--- read.c 2005-12-16 14:07:04.0 -0800
***
*** 250,257
}
strike = makeStrike(font,
! face-available_sizes[i].width,
! face-available_sizes[i].height);
if(strike == NULL) {
fprintf(stderr, Couldn't allocate strike.\n);
return -1;
--- 250,257
}
strike = makeStrike(font,
! face-available_sizes[i].x_ppem6,
! face-available_sizes[i].y_ppem6);
if(strike == NULL) {
fprintf(stderr, Couldn't allocate strike.\n);
return -1;
Re: [Fonts] Re: [ft] Creating an [OT]TF font from BDF font
George Williams wrote: 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- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Wed, 2005-12-14 at 13:16, David Turner wrote: - 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. ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Wed, 2005-12-14 at 13:16, David Turner wrote: 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. ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
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? ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
Juliusz Chroboczek wrote: 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 LabA sneer is the weapon of the weak. New Mexico State University -- James Russell Lowell (1819-1891) Box 30001, MSC 3CRL Las Cruces, NM 88003 ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
