Re: [Devel] PFR/OpenDoc driver now available

[Jon M. Taylor]

On Thu, 25 Oct 2001, David Turner wrote:

> Hello Jon,
> 
> "Jon M. Taylor" a ?crit :
> > 
> >         I have written a simple PFR/OpenDoc font driver module for
> > Freetype 2.  It handles basic glyph outlines, simple and compound glyphs,
> > and scaling.  It does not yet handle blue values, secondary strokes/edges
> > or kerning.  Autohinted characters are rendered at 2x size for some
> > reason, probably a simple bug.
> > 
> >         A compressed diff against a vanilla 2.0.5 tree is available from:
> > 
> > http://gaia.ecs.csus.edu/~taylorj/freetype.diff.bz2
> >
> >         Please give it a whirl if you can.  Feedback is appreciated, and
> > in particular if anyone can point me to a freely available PFR which
> > contains kerning tables so I can implement kerning, that would be quite
> > useful as I cannot find one.
> > 
> > Jon
> > 
> > P.S. This is commercially sponsored by my employer, Pioneer Electronics.
> >
> Just to be certain, under which license do you release this source code ?
> It seems that it's under the FreeType license but we need to be 100%
> sure about that !!

        It is under the FreeType license.
 
> And now, some information regarding PFR/TrueDoc:
> 
>   - it's a "compressed" font format developed by Bitstream; it is
>     also fully covered by patent 5,099,435 though I could be wrong
>     (but doubting it). The "compression" is lossy, with
>     auto-generated hints, but the font files are really small.
> 
>   - the only tools that produce these fonts are converters sold
>     or licensed by BitStream so it's not like they're widely
>     available (well, to be fair, it seems that a few applications
>     have licensed the Bitstream converters too, but you hardly hear
>     about these..). You should be able to get a few ones at the
>     www.truedoc.com site (look at the HTML for <embed> tags and
>     start downloading for testing purposes..).

        Yes, I've pilfered (|->) many fonts from the truedoc.com site for
testing purposes already.  None of them that I saw had kerning tables,
however perhaps I was just looking at the wrong ones or something.
 
>   - Bitstream has suceeded in pushing their format as a standard for
>     a number of embedded specifications, especially in the field of
>     digital television. 

        That's why I wrote this.

>     As a consequence, they have published the
>     specification for these publicly. For example, see annex A of
>     this PDF document: ftp://ftp.davic.org/Davic/Pub/Spec1_4/14p09ml.pdf

        That's what I used as a reference, although it has several
inconsistencies and "bugs" that I found (see the source)....

>   - _Implementors_ of these specifications are generally given a
>     royalty-free or RAND license. Yes, that's the Reasonable And
>     Non-Discriminatory) that have been talked about so much
>     recently regarding the W3, don't get me started on this ;-)
> 
>     Notice that you must be an official member of DAVIC, DVB or any
>     other such standardisation commitee to be eligible for this
>     license. Otherwise, normal patent law applies, and Bitstream is
>     able to charge wathever they want for it, or simply prevent you
>     from using it..

        Do you think that this poses a problem for releasing the PFR
driver code under an open source license?

>     a single PFR font contains one or more "physical fonts", each one
>     of them containing "master outlines". Then "logical fonts" can
>     be generated by applying emboldening, stroking or affine transformation
>     (i.e. obliquing) with parameters contained within the logical font
>     descriptor.
> 
>     this also means that you need a path stroker/emboldener in order to
>     fully implement the specification (However, I don't really think
>     there is a need for this within a font driver, and it's clearly
>     not top-priority..)

        Many PFRs contain multiple font faces which implement bold, italic
and bold+italic directly.  However, not all PFRs contain these.
 
>   - I have written a PFR font driver for a proprietary prototype of
>     FT2 in 1998 (when working for Canal+) and getting all things to
>     work correctly has been _hell_. 

        Yeah, I sweated a few times myself.

>     The specification was unclear
>     or missed key information on many points, especially regarding
>     hinting. I even remember that the example PFR font provided by
>     BitStream to the DAVIC commitee included embedded bitmaps that
>     just looked _real_ crap. It took me some time to realize that
>     there was nothing wrong with my code !!
> 
>     For example, I noticed that your code has a problem determining
>     the exact glyph count in a font and that you hard-coded it to
>     97 !! this just rings a bell or two :o)

        I have to wonder why the spec has not been fixed on these points
for all these years....
 
> The conclusion of all of this, for now, is that I'm still unsure
> if we'll distribute the sources of a PFR module within the FreeType 2
> distributions.
> 
> If we do, the code will most certainly be disabled by macro definitions
> in order to avoid patent issues (ain't the software world funny ;-).

        The patents link on the FreeType home page is broken, as is the
patents item link in the FAQ.  Is that macro-disabling thing the standard
way to work around patent issues in FreeType?  The language of the license
in the spec file ("Make _and_ use" (emphasis mine)) would seem to allow
for open-source distribution and coding development, as long as the actual
use of the software is restricted as noted, which is the responsibility of
the user of FreeType.  But IANAL.  If there's anything I can do to help
clarify this, let me know.
 
> If not, we could distribute it as a separate module either from the
> FreeType site or an alternative download location..

        Pioneer is basing much of our code for the current project I'm
working on upon open-source software, so we will need to provide a web
site and/or a CD of sources in any case.  I was just hoping that our work
could be incorporated into FreeType for the widest possible distribution,
as well as to create a common source code base for all the people out
there working on interactive TV projects, so we can pool our resources
working on this crazy spec |->.
 
> Until this question is unanswered (and I'm asking for comments), I
> will not commit the PFR module to the HEAD branch. I'll probably
> create a new branch soon, however, if there are no license
> restrictions..
> 
> Any comments welcomed :-)

        Thanks for your detailed reply.

Jon