[pdftex] Yet another patch [long]

[Tom Kacvinsky]

Hi all,

And yet another patch.

OK, here is a little more information.  The file that Tom Kiffe sent me used
an *old* Type 1 font -- so old, it came out before the Type 1 specification was
published.  This font had a Subrs array that looked like:

/Subrs 30 array
.
.
.
dup 5 15 RD <15 bytes> noaccess put
.
.
.

My original patch assumed that if the subroutine started with RD, then the
end token must be NP.  So the "empty" subroutines I put in ended with NP.
This is what caused Tom's problems: NP was not defined in the Private
dictionary, so all hell broke loose when printing because the interpreter
did not know about the procedure NP.

Here is the weird part: Acrobat 5.0 printed the file!  Acrobat 4.0.5 did
not!

So, it would seem that not only did Adobe change things around so that what
seemed like perfectly valid PDF (see note at end of message) files do not
print, they also have a bug in their new font engine.  That is, the font
engine in Acrobat 5.0 should have barfed on the poorly contructed font
written out by a "Tom Kacvinsky patched" version of pdftex.

OK, so now back to the last two patches I submitted: the first took care of
the problem with starting with RD and ending with "noaccess put".  But I
missed the case where one could start with -| and end with "noaccess put".

So, the patch I have attached to this message takes into account the
following begin/end pairings:

RD, NP
-|, |
RD, noaccess put
-|, noaccess put

The new patch sets things up so that the begin/end token parsing happens
only once (not for each subroutine defined in the font).

Finally, I have set things up so that if pdftex cannot match one of the four
pairs above, it will fail with the error message:

  "This Type 1 font uses mismatched subroutine begin/end token pairs."

Of course, you will get the name of the PFB/PFA file that caused the problem,
so error reporting will be a lot more meaningful with respect to this patch.

I am not inclined to add support for any more begin/end token pairs.  As for
my reasons, I say this:  the above begin/end pairs should be about all inclusive,
and if they are not, I leave it up to the user to use the t1utils suite of tools
to put the font into a form that pdftex will recognize.  This is not hard to do.

Regards,

Tom

Over last weekend, I heard back from Adobe about this Subr aray gap
problem.  The people at Adobe pointed me to a section in the Type 1
specification in which it is stated that the Subrs array must have no gaps.
This section was on ATM compatibilty, so I guess this means that even if we
are working in a more general setting, we should use the more restrictive
guidelines.  I wish Adobe would make an addendum to the Type 1 format,
stating that "no gaps in the Subrs array" is the law.

The upshot of all of this is that pdftex gnerated PDF files are no longer
valid PDF, because the Type 1 fonts embedded in them are not valid Type 1
fonts.

So,

   foo foo foo, bar bar bar is all I have to say to Adobe!

(with apologies to The Police)

On Wed, 20 Jun 2001, Tom Kacvinsky wrote:

> Here is a new patch.  Tom Kiffe told me that it fixed the problem he had.
>
> Tom
>
> On Tue, 19 Jun 2001, Tom Kacvinsky wrote:
>
> > Tom Kiffe gave me a problem file that pointed out a problem with my patch
> > (and now that I think about it, exhibits how *weird* the Acrobat problem
> > really is).
> >
> > I am in the midst of figuring out how to fix the problem.  The issue only
> > arises when the subrs start with RD (-|) and end with something other
> > than the matching end token NP (|, respectively).  And this only happens
> > with *old* fonts.
> >
> > Tom
> >
> > On Fri, 15 Jun 2001, Tom Kacvinsky wrote:
> >
> > > Hi all,
> > >
> > > Attached is a patch for pdftex 3.14159-14h-released-20010417 that fixes the
> > > following problem:
> > >
> > >   PDF files generated by pdftex in which Type 1 fonts are subsetted do
> > >   not print correctly from Acrobat (Reader) 5.0.
> > >
> > > Having been down this road before (sending a patch in for pdftex whilst
> > > Thanh is away), I feel compelled to state that this patch is for those who
> > > want to use it, and I am not asking for it to be the definitive, official
> > > fix for this problem.
> > >
> > > With that said, the patch just simply fills in the gaps in the Subrs array
> > > with subroutines do nothing.  This does not yield the smallest possible
> > > subsetted font. To do that, one needs to renumber all of the subroutines,
> > > and make sure the charstrings which call these renumbered subroutines use
> > > the new numbers, etc...
> > >
> > > The limited tests I have run indicate the patch does work and does not
> > > introduce any new bugs.  Comments and more testing would be appreciated.
> > >
> > > Regards,
> > >
> > > Tom
> > >
> >
> > _______________________________________________
> > pdftex mailing list
> > pdftex at tug.org
> > http://tug.org/mailman/listinfo/pdftex
> >
>