[pdftex] xpdf (was: [Gs-devel] Re: [gnu@toad.com: Re: EFF place holder page for when we have PDF rather than HTML])

[Raph Levien]

On Sun, Feb 10, 2002 at 09:30:20PM -0800, L. Peter Deutsch wrote:
> > Looking at the work required at the technical level, you're right.  But I
> > had a feeling that there were patents in PDF 1.4 that might stop a
> > competing implementation dead.  :-(
> 
> I hope Raph Levien, who has studied the PDF 1.4 transparency specification
> very carefully and has some opinions on the patent situation with respect to
> it, will reply on this issue.

Very well.

> > Someone should look into the patent situation.  Ah, actually, I think I'm
> > remembering patents on parts of PostScript level 3, that prevent a PS
> > level 3 clone.  I don't know if they would include PDF 1.4.
> 
> I know of no such patents.  Adobe may have patented some implementation
> techniques for their "accurate screens" technology, but the PS LL3
> specification does not, as far as I know, require using Adobe's
> implementation approach.

This is correct. The patent situation on Accurate Screens is murky. At
least one other patent on the basic technique exists (to Intergraph),
but as far as I know, none of these patents have ever been pursued.
Of course, unlike trademarks, patents don't have a "use it or lose it"
provision, so there's always the possibility of a sudden change of
heart.

Fortunately, however, it's possible to produce results at least as
good as Accurate Screens with other techniques, including my own
Well Tempered Screening.

There are three other areas of patent difficulty surrounding a truly
compliant PostScript LanguageLevel 3 implementation. Of these, the most
intractable is in-RIP trapping. I expect that enough of these patents
may expire over the next few years to make a truly free implementation
feasible. I plan to analyze the patent literature much more fully.

Also difficult are the TrueType hinting patents. Fortunately, it is
possible to implement unhinted TrueType rasterization without any
patent difficulties. There are a few fonts that abuse the TrueType
specification, and produce incorrect fonts (the notorious PMingLiu of
DynaLab) if the hints are simply ignored, but we're actively
investigating ways of handling this without infringing Apple's
patents.

Lastly, there is the spectre of the Schreiber patent on color
management. The exact scope of validity of this patent is a subject
of intense controversy. The current assignee (EFI) has pursued it
very aggressively, and has apparently collected a lot of money in
settlements. It's also a matter of some debate whether PostScript
LL3 really does "color management" - in the graphic arts market,
native PostScript "color rendering dictionaries" have been all but
abandoned in favor of ICC.

Fortunately, the Schreiber patent expires early this May.

> With respect to PDF, see
> 
> 	http://partners.adobe.com:80/asn/developer/legalnotices.html
> 
> The only one of the 6 patents listed there that I looked at is U.S. patent
> 5,860,074, which appears to deal with using "optimized" PDF to provide quick
> early display of pages containing both text and other objects.  It is
> licensed only for generating (optimized) PDF, not for rendering it.

Also correct. I've been watching for patents related to the fancy
transparency functionality of PDF 1.4, but none have issued yet. I
expect they will, and I think it is likely that Adobe will grant
rights to implement these patents. To do otherwise, while not out of
the question, would be a fairly drastic reversal of their previous
direction.

In addition to the possible transparency issues, there are two other
areas of potential patent difficulty. For one, PDF 1.4's approach to
color management is considerably more aggressive than PostScript's has
been. Particularly, ICC profiles for both input and output colorspaces
are provided. PostScript does not support ICC profiles at all.

Second, PDF 1.4 contains JBIG2 by reference. I believe the JBIG2
standards body tried their best to make this standard patent-free
(unlike the first JBIG, for which Lucent is charging royalties).
However, the patent situation has not been fully clarified. In any
case, I believe it considerably more likely that patent problems exist
for encoders (which have a great deal of latitude in producing
compressed bitstreams) than for decoders. Hence, our own
implementation is a decoder only, at least for the time being.

There are a number of other patents that one would run into if one
were doing a feature-for-feature clone of Acrobat Reader, including a
number of tricks used in rendering PDF files downloaded incrementally
from the Web. The current technique of downloading the entire PDF file
before launcing the viewer avoids this class of patents, even if it
increases the latency a few seconds.

Another Adobe patent covers the technique of decomposing areas of
transparency into a planar map of solid-color vector regions. This
is a neat trick for speeding up rendering of certain transparent page
images, but is not fully general. Our technique of rendering all
transparency by rasterizing avoids this problem, and is technically
a good one (even if it isn't the fastest on all possible files and
all possible devices).

Then there's the usual background radiation level of bad patents. For
example, Microsoft has a patent on combining hinting and antialiasing.
It's (a) very likely obvious, (b) very possibly covered by prior art,
and (c) never been enforced. Apple has the notorious patent on
per-channel alpha compositing (a technique _not_ used in PDF 1.4),
for which the broadest claims cover all alpha compositing. Sony has
a patent on alpha-compositing in a gamma corrected color space. BT's
patent on hyperlinking might cover PDF links as well as HTML ones.
I personally feel that these sorts of patents should be ignored. If
you let them stand in your way, basically no modern software would
be possible.

In summary, there are quite a few areas in implementing PDF where
there are potential patent problems, but none of them are
showstoppers. In all cases, either the risk from the patent is very
low, there's a reasonable patent-free workaround, or both. We feel
confident moving ahead with our own implementation efforts, and are
also arguably a lot more careful about patent issues than some
other free software projects (which shall remain nameless). I think
it is wise to continue to track the patent situation carefully, but
at the same time, that shouldn't prevent us from getting our work
done.

I am not a lawyer (and praise God for that!) If you want a real legal
analysis of the patent situation, you will have to pay real lawyers
way too f---ing much money.

Raph
(who would be pleased if those last three lines were to be stored in
a file entitled stdianal.h)