Re: [ft] Creating an [OT]TF font from BDF font
David Turner <[email protected]> Wed, 14 Dec 2005 22:16:07 +0100
| Newsgroups | gmane.comp.fonts.freetype.user,gmane.comp.xfree86.fonts |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============0644542191==
Content-Type: multipart/alternative;
boundary="------------070501020206060409020806"
This is a multi-part message in MIME format.
--------------070501020206060409020806
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 independe=
nt
of size).
I'd like to know the following:
- is this feature useful for fontconfig / libXft ? Or should we yank it f=
rom
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" descriptor=
s
in the first array. The first array item would have ppem =3D=3D 0 to in=
dicate
"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 =E9crit :
>On Sat, 2005-12-10 at 00:42, Werner LEMBERG wrote:
> =20
>
>>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.
>> =20
>>
>Ok. I have a version of fontforge which puts bdf properties into a=20
>'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:=20
> =20
>
>>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.=20
>> =20
>>
>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=20
> 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.
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>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:=20
> 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=20
>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 =3D> non-property string
> (e.g. COMMENT)
> 1 =3D> non-property atom
> (e.g. FONT)
> (also SIZE even though not
> really an atom)
> 2 =3D> non-property int32
> 3 =3D> non-property uint32
> 0x10 =3D> flag for a property,=20
> ored with above value
> types)
> ULONG item_value : item value.=20
> strings =3D> an offset into the string
> table of the corresponding
> string, without the surrounding double-quotes
>
> atoms =3D> an offset into the string
> table
>
> integers =3D> the corresponding 32-bit
> value
>Then the string table of null terminated strings. These strings should
>be in ASCII.
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>Comments?
>
>
>
>_______________________________________________
>Freetype mailing list
>[email protected]
>http://lists.nongnu.org/mailman/listinfo/freetype
> =20
>
--------------070501020206060409020806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi George,<br>
<br>
I just added support to this new table to FreeType, it's now in the CVS.<br>
This is controled through TT_CONFIG_OPTION_BDF within ftoption.h<br>
(enabled by default, at the moment).<br>
<br>
When defined, FT_Get_BDF_Property will work IF you have previously<br>
selected a size that correspond to one of the strikes listed in the BDF
table<br>
(i.e. "face->size->metrics.y_ppem" is listed in the table)<br>
<br>
Moreover, FT_Get_BDF_Charset_ID works as well, *under* the same<br>
conditions (which is sad, since it's supposed to return results
independent<br>
of size).<br>
<br>
I'd like to know the following:<br>
<br>
- is this feature useful for fontconfig / libXft ? Or should we yank it
from<br>
FreeType ?<br>
<br>
- should we update the BDF table format to include size-independent<br>
data (e.g. the CHARSET_REGISTRY and CHARSET_ENCODING<br>
atoms). This could be done trivially by using "numStrikes+1"
descriptors<br>
in the first array. The first array item would have ppem == 0 to
indicate<br>
"global" values, instead of size-specific ones.<br>
<br>
- I don't understand completely the difference between atoms and
non-property<br>
strings. Aren't these the same things ? Why distinguish them then ?<br>
<br>
Hope this helps,<br>
<br>
- David Turner<br>
- The FreeType Project (<a class="moz-txt-link-abbreviated" href="http://www.freetype.org">www.freetype.org</a>)<br>
<br>
PS: By the way, your .otb file doesn't display correctly in ftview,
I'll try<br>
to investigate this later...<br>
<br>
George Williams a écrit :
<blockquote cite="mid1134539103.2556.62.camel@lynch" type="cite">
<pre wrap="">On Sat, 2005-12-10 at 00:42, Werner LEMBERG wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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
<a class="moz-txt-link-freetext" href="http://fontforge.sf.net/fontforge_full-20051213.tar.bz2">http://fontforge.sf.net/fontforge_full-20051213.tar.bz2</a>
I've also posted an otb file containing 3 bitmap strikes and a BDF table
<a class="moz-txt-link-freetext" href="http://fontforge.sf.net/hidden/FixedMedium.otb">http://fontforge.sf.net/hidden/FixedMedium.otb</a>
On Thu, 2005-12-08 at 16:46, Keith Packard wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->A couple of caveats about "lossless" round-trips:
* BDF format supports an (x,y) advance for both horizontal & vertical
metrics
(ie. it could support Urdu where there is a vertical advance
as well as horizontal)
EBLC metrics only support one advance for each writing
direction.
hmtx/vmtx also only support one advance
In other words for those rare fonts with an advance vector rather than
a simple advance an otb font can't retain that info.(I don't think
that's an issue for X)
* BDF format supports advances, pixelsizes > 255 pixels
EBLC metrics don't
* FontForge doesn't really support VVector
So this data will be lost (I don't think that's an issue for X)
* Each otb file should be single resolution:
X/BDF can distinguish between
-gww-caslon-medium-r-normal--12-120-75-75-p-150-iso8859-1
-gww-caslon-medium-r-normal--12-100-100-100-p-150-iso8859-1
(same pixel size, but potentially different bitmap patterns because
designed for different point-sizes at different resolutions)
But EBLC can only have one strike per pixelsize.
* If FontForge can't recognize the encoding of a font it doesn't know
how to map glyphs into the cmap table.
=====================================================================
I changed my BDF table proposal, taking out the idea of an array type
and reverting to David's suggestion of treating them as atoms. So here
is my current spec:
/* Format:
USHORT version : 'BDF' table version number, must be 0x0001
USHORT strikeCount : number of strikes in table
ULONG stringTable : offset (from start of BDF table) to string
table
followed by an array of 'strikeCount' descriptors that look like:
USHORT ppem : vertical pixels-per-EM for this strike
USHORT num_items : number of items (properties and
atoms), max is 255
this array is followed by 'strikeCount' value sets. Each "value set" is
an array of (num_items) items that look like:
ULONG item_name : offset in string table to item name
USHORT item_type : item type: 0 => non-property string
(e.g. COMMENT)
1 => non-property atom
(e.g. FONT)
(also SIZE even though not
really an atom)
2 => non-property int32
3 => non-property uint32
0x10 => flag for a property,
ored with above value
types)
ULONG item_value : item value.
strings => an offset into the string
table of the corresponding
string, without the surrounding double-quotes
atoms => an offset into the string
table
integers => the corresponding 32-bit
value
Then the string table of null terminated strings. These strings should
be in ASCII.
==================================================================
Comments?
_______________________________________________
Freetype mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="http://lists.nongnu.org/mailman/listinfo/freetype">http://lists.nongnu.org/mailman/listinfo/freetype</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------070501020206060409020806--
--===============0644542191==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Freetype mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype
--===============0644542191==--