[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
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
> > 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 ___ 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. In connection with that I wonder which of your patches you've sent to the list shall go into FreeType. > 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 ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Mon, 2006-01-16 at 21:45, Werner LEMBERG wrote: > 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 > 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. ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[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 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
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
> 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
> 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
On Mon, 2005-12-12 at 20:12 +0100, Juliusz Chroboczek wrote: > 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 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-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
> 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
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. So I'd like to make the following changes to David's proposal: On Fri, 2005-12-09 at 02:02, Turner, David wrote: > 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 ULONGstringTable : offset (from start of table) to string table > Each string is 8-bit and > 0-terminated. the end of the string sub-table will be the start of the array sub-table. ULONGarrayTable : 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. > > 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 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) > > ULONGitem_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 > >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 ___ 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 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: 1 #version n #number of strikes offset to start of string/atom table n instances of the following structure #ppem #offset (from start of BDF table) to information on this strike Strike info would look like: ni #count of non-property information FONT, SIZE, FONTBOUNDINGBOX, COMMENT, etc. np #count of property ni instances of the following structure #offset from start of string table to atom name #type of data: 0 => atom, 1 => string, 2 => integer #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, 200
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Thu, 2005-12-08 at 16:07, 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. Well, you would need a separate sub-table for each BDF 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 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
> 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 ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
Hi,
> 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
___
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
> 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
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"-.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
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 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 believe the entrySel field in the table directory of the output sfnt is off by 1. *** write.c~ 2005-12-16 15:10:29.0 -0800 --- write.c 2005-12-16 15:10:29.0 -0800 *** *** 358,364 writeULONG(out, 0x1); /* version */ writeUSHORT(out, numTables); /* numTables */ writeUSHORT(out, 16 * ti); /* searchRange */ ! writeUSHORT(out, i - 1);/* entrySelector */ writeUSHORT(out, 16 * (numTables - ti)); /* rangeShift */ /* see fixupDir */ --- 358,364 writeULONG(out, 0x1); /* version */ writeUSHORT(out, numTables); /* numTables */ writeUSHORT(out, 16 * ti); /* searchRange */ ! writeUSHORT(out, i);/* entrySelector */ writeUSHORT(out, 16 * (numTables - ti)); /* rangeShift */ /* see fixupDir */
[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_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.
*** 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_ppem>>6,
! face->available_sizes[i].y_ppem>>6);
if(strike == NULL) {
fprintf(stderr, "Couldn't allocate strike.\n");
return -1;
[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 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 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
