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 ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
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 ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
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 ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
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. ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft-devel] Re: [ft] Creating an [OT]TF font from BDF font
On Sun, 2005-12-18 at 18:20, Chia-I Wu wrote: FT_Get_BDF_Fontname(face) FT_Get_BDF_Comments(face) Couldn't they just be treated like normal properties? Well they aren't in the bdf file format, they are handled quite differently, so the bdf parser handles them differently. The pcf file format does not contain the comments but does treat the fontname as a normal property. I thought bundling them into the property list might offend some purists. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: [ft] Creating an [OT]TF font from BDF font
On Sun, 2005-12-18 at 18:20, Chia-I Wu wrote: FT_Get_BDF_Fontname(face) FT_Get_BDF_Comments(face) Couldn't they just be treated like normal properties? Ok, I have removed those entry points and made them behave like normal properties. This is incompatible with previous behavior. But since the previous behavior was inconsistent between BDF PCF that may not matter. iterate_bdf3.patch.bz2 Description: application/bzip iterate_sfnt3.patch.bz2 Description: application/bzip ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
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 ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft-devel] Re: [ft] Creating an [OT]TF font from BDF font
On Sat, 2005-12-17 at 18:42, Chia-I Wu wrote:
I suggest the following APIs, making iterator merely an iterator:
/* to iterate... */
FT_Get_BDF_Iterator( face, iter );
while ( FT_Iterare_BDF_Property( face, iter, name, aprop ) )
{
/* do something; */
}
/* to get property count... */
FT_Get_BDF_Property_Count( face );
Is that really an improvement? It means adding three function calls
instead of one, and it isn't compatible with the List_Iterator either.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: [ft] Creating an [OT]TF font from BDF font
On Sat, Dec 17, 2005 at 04:01:38PM -0800, George Williams wrote:
Ok, here is an iterator.
FT_GetIterate_BDF_Property(FT_Face,BDF_PropertyIteratorRec *aprop)
To get the first property set,
aprop-index = 0
(each call will automagically increment)
aprop-cnt will be set to the number of properties in the face
aprop-name the name string
aprop-property standard BDF_PropertyRec with the value.
I suggest the following APIs, making iterator merely an iterator:
/* to iterate... */
FT_Get_BDF_Iterator( face, iter );
while ( FT_Iterare_BDF_Property( face, iter, name, aprop ) )
{
/* do something; */
}
/* to get property count... */
FT_Get_BDF_Property_Count( face );
--
Regards,
olv
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: [ft] Creating an [OT]TF font from BDF font
Drat. PCF fonts include the FONT keyword and value in the list of properties. Strictly speaking FONT is not a bdf property (it comes outside of the STARTPROPERTIES list) -- however to do round trip conversion it is necessary. The value is available internally as face-bdffont-name, but I don't see any API to get this. I see three possibilities: * Add an API to retrieve face-bdffont-name * Add this to the property list on parsing Will make the BDF properties match the PCF ones, but would be incompatible with existing code * Change my new iterator so that it manufactures a fake entry for FONT ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
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;
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Creating an [OT]TF font from BDF font
___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Creating an [OT]TF font from BDF font
Hi George, I just added support to this new table to FreeType, it's now in the CVS. This is controled through TT_CONFIG_OPTION_BDF within ftoption.h (enabled by default, at the moment). When defined, FT_Get_BDF_Property will work IF you have previously selected a size that correspond to one of the strikes listed in the BDF table (i.e. "face-size-metrics.y_ppem" is listed in the table) Moreover, FT_Get_BDF_Charset_ID works as well, *under* the same conditions (which is sad, since it's supposed to return results independent of size). I'd like to know the following: - is this feature useful for fontconfig / libXft ? Or should we yank it from FreeType ? - should we update the BDF table format to include size-independent data (e.g. the CHARSET_REGISTRY and CHARSET_ENCODING atoms). This could be done trivially by using "numStrikes+1" descriptors in the first array. The first array item would have ppem == 0 to indicate "global" values, instead of size-specific ones. - I don't understand completely the difference between atoms and non-property strings. Aren't these the same things ? Why distinguish them then ? Hope this helps, - David Turner - The FreeType Project (www.freetype.org) PS: By the way, your .otb file doesn't display correctly in ftview, I'll try to investigate this later... George Williams a crit: On Sat, 2005-12-10 at 00:42, Werner LEMBERG wrote: All of this looks very promising. I think the final decision on the table format can only be done after converting a bunch of BDFs forth and back. Ok. I have a version of fontforge which puts bdf properties into a 'BDF ' table in an sfnt, and then reads them back and writes them out into bdf. The data seem to survive the round trip. I've posted a source tarball http://fontforge.sf.net/fontforge_full-20051213.tar.bz2 I've also posted an otb file containing 3 bitmap strikes and a BDF table http://fontforge.sf.net/hidden/FixedMedium.otb On Thu, 2005-12-08 at 16:46, Keith Packard wrote: I need this + a utility to regenerate BDF files from the TTF so I can validate a lossless round-trip for the existing BDF files. A couple of caveats about "lossless" round-trips: * BDF format supports an (x,y) advance for both horizontal vertical metrics (ie. it could support Urdu where there is a vertical advance as well as horizontal) EBLC metrics only support one advance for each writing direction. hmtx/vmtx also only support one advance In other words for those rare fonts with an advance vector rather than a simple advance an otb font can't retain that info.(I don't think that's an issue for X) * BDF format supports advances, pixelsizes 255 pixels EBLC metrics don't * FontForge doesn't really support VVector So this data will be lost (I don't think that's an issue for X) * Each otb file should be single resolution: X/BDF can distinguish between -gww-caslon-medium-r-normal--12-120-75-75-p-150-iso8859-1 -gww-caslon-medium-r-normal--12-100-100-100-p-150-iso8859-1 (same pixel size, but potentially different bitmap patterns because designed for different point-sizes at different resolutions) But EBLC can only have one strike per pixelsize. * If FontForge can't recognize the encoding of a font it doesn't know how to map glyphs into the cmap table. = I changed my BDF table proposal, taking out the idea of an array type and reverting to David's suggestion of treating them as atoms. So here is my current spec: /* Format: USHORT version : 'BDF' table version number, must be 0x0001 USHORT strikeCount : number of strikes in table ULONG stringTable : offset (from start of BDF table) to string table followed by an array of 'strikeCount' descriptors that look like: USHORT ppem : vertical pixels-per-EM for this strike USHORT num_items : number of items (properties and atoms), max is 255 this array is followed by 'strikeCount' value sets. Each "value set" is an array of (num_items) items that look like: ULONG item_name : offset in string table to item name USHORT item_type : item type: 0 = non-property string (e.g. COMMENT) 1 = non-property atom (e.g. FONT) (also SIZE even though not really an atom) 2 = non-property int32 3 = non-property uint32 0x10 = flag for a property, ored with above value types) ULONG item_value : item value. strings = an offset into the string table of the corresponding string, without the surrounding double-quotes atoms = an offset into the string table integers = the corresponding 32-bit value Then the string table of null terminated strings. These strings should be in ASCII.
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. ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
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 ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
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
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 ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
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 ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Creating an [OT]TF font from BDF font
Can anyone recommend programs that create [OT]TF fonts from BDF fonts? fontforge: http://fontforge.sourceforge.net/ --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: [EMAIL PROTECTED] - - 155 S 1400 E RM 233 [EMAIL PROTECTED] [EMAIL PROTECTED] - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - --- ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
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 ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
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 ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
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
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
