MicroPress Inc.
The Home Of Visual Tex

Welcome to Acrobat 5: new features, new bugs.

"Acrobat" is so named because of the contortions one must do to get around its bugs.---Donald Arseneau.

Preliminary draft III

(updated May 29, 2001)


Features of MicroPress Products
Features of MicroPress Products
Mailing list
Products demo
Frequently Asked Questions
What's New
Order Now!
Ask Micropress
Acrobat4 bugs

Over the last three weeks, since Adobe has released the new major version of the Acrobat and Acrobat Reader software, we have received a number of queries regarding the use of AR5 with VTeX and various problems which have been encountered by the users. This article summarizes what we know to date and provides the recommendations we have.

This document is intended primarily for VTeX users, but it should be applicable to users of other TeX systems interested in producing AR5-compatible PDF files.

For an impatient reader, who wants the answers without reading the full text, it all boils down to

Can I install AR5 (to replace AR 4.05 as shipped with VTeX)?
Should I install AR5 (to replace AR 4.05 as shipped with VTeX)?
Probably, NO.
Should I read the rest of the article, even if I am not installing AR 5 now?
If you are distributing your PDF files, YES.

Quo vadis, Adobe?

The following post signed by Gaius Helen Mohiam appeared in comp.text.pdf on May 19, 2001:

Does anyone know when Adobe will fix this bug-ridden, unstable and slow mess they let loose on the public as Acrobat 5? I had made the mistake of upgrading, and now many pdf documents won't print correctly, Acrobat hangs on certain actions, and is generally noticeably slower than Acrobat 4.

To add insult to injury, when I called their Tech Support with a printing problem, the support person asked whether the pdf file was generated by an Adobe product. When it turned out that it wasn't (it was generated by Ghostscript, and had worked fine in version 4, btw), I was essentially told "your screwed": Adobe only guarantees that Acrobat can deal with PDF files generated by Adobe products. Pdf as an open file format? Forget about that...

Quo vadis, Adobe?

Here we go again.

Usually, .0 versions of software products come with new features and new bugs; Adobe Acrobat products consistently follow this pattern. AR 3 was followed by (working) AR 3.01; the infamous TvZ's bug in AR 4.00 has been (only partially) fixed in AR 4.05; and AR 5.00 will likely to be followed by a corrected version (5.05? -- surely not 5.01, since 5.01 has been already released and it does not seem to correct any of the known problems.)

Our general recommendation is to avoid .0 products; however, in the case of Adobe Reader, it is not a recommendation one can always follow:

Even if you do not use AR 5 yourself, if you distribute your PDF's to other people, they might install it. Thus, indirectly, you are still opened to the AR 5 bugs, since your readers may encounter problems. Thus, make sure to read the Bugs Added section below.

This page provides examples of the harder-to-reproduce bugs; if you are interested in more details about the others, ask!

What is new.

A new major release of a software product is supposed to provide new features, and AR 5 is not an exception. Some new features are in indeed; most of them, however, are not of much use. Here is the partial list:
  • Page thumbs, if not present in the document, are automatically generated and shown. [Nice for presentations.]
  • It is possible to define Outline entries attributes (Bold and Italic) and color. [Very limited use.]
  • It is possible to use any font, not just Base 13, in fields like list and edit boxes. [Very limited use, since the great majority of TeX-generated documents do not use forms.]
  • There are some enhancements to JavaScript implementation. [Very limited use, since the great majority of TeX-generated documents do not use forms. Despite the enhancements, Acrobat JavaScript is still not up to being able to play animations.]
  • There is some ability to export PDF as RTF. [If you are thinking about using this for TeX-to-Word conversion, don't].
  • There is a new syntax to specify the internal (logical) structure of the document; this may lead one day to XML conversion.

Use with VTeX 7.

Good news on this front: Acrobat 5 uses the same registry entries as Acrobat 4; therefore both the Preview and Help facilities even of pre-AR5 versions of VTeX will sense AR 5 correctly.


The downside of Acrobat 5 is the its slowness comparing to the previous versions. On a 1.5 GHZ computer this is not a problem, but if your machine is older, waiting for Acrobat 5 to load may be irritating. Installing AR 5 on a 200mhz may be not a good idea just for this reason.

Furthermore, there are chances of Acrobat 5 crashing during the loading. [While this has never been observed by us, it has been reported by users].

ProblemAcrobat 5 crashes on loading
SolutionRemove unneeded API files; the error seems to be connected to DOCBOX.API, which is non-essential for most purposes. Either delete it move it elsewhere.
CreditFirst reported by J.F., US.

Another way to crash Acrobat could be to use the [Print] selection in its menu. If the default Windows printer driver is the PDF Writer from the Acrobat 4 distribution, selecting [Print] causes an immediate crash of Acrobat; it may also bring down the entire Windows (unconfirmed).

Notice that AR 4 would not allow to print to the PDF Writer (why not, really?), but would not crash.

ProblemAcrobat 5 immediately crashes on print.
SolutionChange the default Windows printer.


Acrobat 5 seems to be using a new Type1 rendering engine. It is not clear what are the advantages of this change; the disadvantages are that a number of (non-Adobe) Type1 fonts look worse under Acrobat5 (preview or non-PostScript print) than they did under AR 3 or 4.

In the case of MicroPress' fonts the effect is most pronounced on the BTT family; a new version of it has been included in 7.31+ distributions.

ProblemFonts do not look as good on the screen as they used to.
SolutionSee if new version of the fonts is available from the manufacturer.
CreditIT, mostly.

Bugs Removed

Before we get to the real bad bugs. there are some good news as well: Adobe has corrected a couple of font-related bugs which were present in AR 4. The two bugs we are aware of are very rare; they relate to ususual fonts which most end-users are not likely to have or need.

ProblemSome glyphs when printed on HP LaserJet (PCL) printers are truncated.
SolutionFixed finally in AR 5,
Solution for AR 4Use PostScript print, if your printer supports PostScript; or use GhostScript.
This is of course the widely known bug, first reported by Timothy van Zandt when Adobe released AR 4. While the most dangerous manifestation of the bug has been fixed in AR 4.05 (math symbol fonts truncation), the problem has been only partially fixed: AR 4.05 solved the problem for the fonts with unusually large depth; but did not for the (less common ones) with the unusually large height.

ProblemSome composite characters had accents totally misplaced.
SolutionFixed finally in AR 5,
Solution for AR 4Use GhostScript.
This bug occurred only on large fonts embedded as CFF's (Type1C).

Bugs Added

The problems described in this section are most serious since they affect a possibly a large number of documents created with all kinds of tools (distiller, gs, pdftex, and ---yes--- older versions of VTeX) which were deemed working before and no longer work properly with A5/AR5.

The two most important problems have identical manifestation: when printing to a PostScript printer, AR5 says

"An error occured while downloading a font. This document might not print correctly."

and, truly, it does not.

While the effect is identical, there are at least two totally different problems involved, and there could be additional causes for this effect (see below).

There is no easy way to know which of the two bugs ruins your document and you may need to take the corrective actions for both. The default corrective action is identical, anyway.

ProblemError on PostScript print.
CauseAdobe bug in handling subsetted fonts.
SolutionEmbed fonts as CFF's.
CreditDR, US.

In some cases, fully subsetted fonts which are embedded as Type1, are rejected by AR5/PostScript print. The bug affects all Pdf-making software that embeds fonts as Type1; this may include all versions of pdftex, dvipdfm, as well as older versions of VTeX, GhostScript, and the Adobe Distiller.

The generally correct approach is to use Pdf-making tools that produce CFF's; besides fixing this problem, the output tends to be much smaller and overall more reliable. However, embedding fonts in full (without subsetting) also may solve the problem (even if it leads to much larger output).

With pre-7.3 versions of VTeX, the required switch for full font embedding is -oc.

The direct cause of the problem is the erroneous handling of the /Subrs array in AR5. If the /Subrs contains fewer entries that are actually supplied AR5 rejects the font. For example, if /Subrs is declared to contain 100 entries, entries 0 through 98 are supplied, and last entry (100) is neither supplied nor used, AR5 will view the font as erroneous. Of course, such a font is perfectly valid according to the PostScript standard, and accordingly to all other implementations of PostScript; and, of course, non-including unneeded /Subrs entries is the legitimate way to minimize the output size.... well, AR5 does not think so.

It is not guaranteed that full font embedding will solve the problem in every case; this is because (1) the problem may be caused by the other PostScript bug or (2) because the font may contain incomplete /Subrs table to start with (none of the MicroPress-supplied fonts does).

While the full honors for creating this bug should go solely to the Adobe Systems, Inc., the credit for the second bug (with identical manifestation) goes to a small company famous for a bizarre claim to be "involved in the conversion and hinting of all of the quality fonts now available in Type 1 format" (?!) as well as many other equally strange claims.

ProblemError on PostScript print.
CauseAMS/BlueSky/trY&crY coding.
SolutionEmbed fonts as CFF's.

Unlike the previous error, this one is specifically caused by several strangely coded fonts, which --- unfortunately --- are in wide use, being released into the public domain. Among the bad fonts are the line* and lcircle*; while it has been reported on the Usenet that other trY&crY fonts, like mathtime (tm), cause the same problem; and, likely, contain the same design error.

05/26/01: trY&crY responded to this page: fonts that are copyrighted AMS ... have a benign typo in the encrypted section, which creates a useless key / value pair. Of course, there is no prohibition against having extra keys in font dictionaries, but some software that does not follow the spec may stumble over this. (Acrobat 5 happens to be such some software, of course, and the use of the word benign in conjunction with a very serious bug or, as trY&crY prefers, typo, is bizarre. Inability to print documents is anything but benign.)

Unlike the previous error, this problem cannot be solved by full embedding, since the affected fonts are bad to start with. To overcome the problem, you should use a CFF-capable PdfMaking program (VTeX 7.30+, or the distiller), or download corrected fonts: VTeX users should take the distribution that uses the lowercase font names, for other systems, use the distribution with the uppercase names.

If you want to see this bug in action, compare a pdf file that uses the bad fonts with the one that uses the corrected ones; both files were made using pdfTeX. You can also take the TeX source. It is important to notice that there is nothing special about the source file; the problem occurs whenever you do not CFF-convert the bad fonts.

Other bugs with the same effect?

It is entirely possible and even likely that there are additional bugs which lead to the same problem; we have seen two .pdf files that exhibit the same behaviour when printed on PostScript printers and cannot be readily explained in terms the two known described here. (for example, trY&crY states that the problem with mathtime reported in the comp.text.tex has a different cause.)

However, the errors in these files (distiller- and gs- generated) seem to be non-reproducible under any version of VTeX; thus it is not necessary to examine them further.

Forms and JavaScript bugs (05/26/01)

Substantially less important for the average user is the mess Adobe has introduced into forms and JavaScript. There are likely to be a dozen or more of separate bugs there; for now we demonstrate only two which are easy to see.

The first one involves a calculator example borrowed from the VTeX forms guide.

The first calculator was a working file under all versions of AR4; AR5 no longer executes it. The problem is not in JavaScript per se; it is caused by the /NeedAppearances setting in the /Catalog. Removing this flag produces a working(?) file. Notice that the two files are identical otherwise. The problem is that the /NeedAppearances is actually a useful option; not supplying it makes Acrobat show the initial values incorrectly. Whereas the first calculator begins with 20.00 in the display field (as intended), the second has 0.00 (wrong).

ProblemJavaScript broken when /NeedAppearances occurs.
SolutionNone yet.

For curious, the VTeX source of this example is here.

The problem seems to be deeper than just mishandling JavaScript; playing with the 2nd calculator in AR5 may cause a GPF in Kernel32 (and subsequently unstable Windows).

Adobe also seems to haven taken a dislike toward Radio Buttons. Here is a very minimal example with VTeX source which, while works, cannot be any longer printed.

ProblemRadioButtons cannot be printed.
SolutionNone yet.

(05/29/01) Another form-related bug that has been reported has to do with fields values specified as strings "(Off)" rather than names "/Off". Whereas previous versions of AR took this fine, AR5 rejects this. This problem does not affect VTeX (which emits names, rather than strings), so the self-explaining supplied example comes from pdfTeX (which is affected). Hans Hagen, who discovered the bug, also provides a Perl script for fixing the existing Pdf documents.

ProblemAR5 rejects field values given as strings.
SolutionCode them as names, or use HH's Perl script to fix older documents.

Of course this bug can be also reproduced under VTeX if you code in pdfmark's with strings; but there are plenty of other ways to enter pdfmark's incorrectly, and, generally, it is best not to program pdfmark's at all, but use VTeX's \special's.

Other types of bugs?

There seems to be additional bugs (or, at least, incompatibilies between A4 and A5) which we are still investigating; however, these additional bugs occur in very rare situations. If/when additional information becomes available, it will be posted here.

It is entirely possible that there are additional bugs in Acrobat 5 which we are not yet aware of; if you have any information about them (or simply encounter any kind of bizarre or unnatural behaviour of AR5 on documents that work with AR4), please let us know.

Why all the mess?

While bugs in new programs are unavoidable, it is our opinion that the wounds in the case are totally self-inflicted.

The basic problem with Adobe is the lack of testing; in its desire to release the product quickly they skip on testing which is essential for products that are as widely used as Acrobat. Such a rush would be explainable if Adobe was compteting with another firm (cf. the Browser Wars of the mid-90's), but they don't; Adobe could have easily waited one, or two, or even six months, just to release a working program.

Beta-testing is important, especially for a product like Acrobat.

The fundamental problem is that Adobe does not have resources to undertake testing on a scale MicroSoft uses with their new products (not that it helps); but in reality no resources are needed at all:

Adobe's approach is to release the new version of the reader at the same time as its full Acrobat package; this really makes no sense. Instead, they should have released AR5 as a public beta at least three months in advance of releasing the full package and clearly mark it as a beta; this would have provides sufficient time for the end users to locate the bugs and for the Adobe programmers to fix them.

It would have been even a better idea if such a public beta had a short expiration date (Netscape did this); and it would have been totally unnecessary to advertise any new features; compatibility is more important than minor enhancements. This would have saved Adobe the embarassment, and the users the headaches.

Oh well, perhaps we are dreaming...

Corrective Actions

No corrective action needs to be taken at this time if you are not distributing your .pdf output; we suggest simply continuing using AR4 until the time when a fixed version of AR5 becomes available.

However, if you are distrubuting your output files (for example, posting them on your Web site), you probably should take the corrective action now, before your readers have discovered problems. Even if Adobe fixes all the problems with AR5 tomorrow (which, surely, would not happen), a suffiently large number of buggy AR5's is already out.

The very first thing is to check if you are affected. Install AR5 and try to print your documents to a PostScript printer. Notice that it is not important if you actually have a PostScript printer connected; you may simply print to a file; it is not even necessary to examine the output (if the error occurs, you will see a Message Box from AR5 during the print). Printing to file would also save time and paper.

If any of your documents exhibits the problem, you should rebuild the document.

For this, it may be necessary to obtain the current compiler and or fonts.

If you are using VTeX 7.30, it should be sufficient to recompile the document(s) with the CFF compression turned on (this was the recommended setting anyway, but who reads the docs...).

If you are using VTeX 7.15-7.30, you can obtain the current compiler by email; please request it by writing to Make sure to indicate your serial number.

The current VTeX compiler is not compatible with older versions of VTeX (the support files and the interface are different); the upgrade of versions 7.00--7.15 requires a (low cost) CD replacement.

If you are using free versions VTeX on Linux/OS/2 you can obtain the 7.3+ pre-release versions; the details had been previously posted on the support maillist.

If your document uses line*, lcircle*, or lasy* fonts, you should also obtain the corrected versions of these, please request them by writing to Make sure to indicate your serial number.

Notice that if you use an older version of VTeX for which we cannot provide a free email upgrade, or while you are waiting for the CD replacement to arrive, you still should be able to overcome the AR5 problems by installing the corrected versions of the fonts and then embedding all fonts in full.

If the problem is related to mathtime, or any other commercial non-MicroPress font set, and if the problem is not cured by CFF-compilation, we probably cannot help you; you may want to contact the vendor, or if the vendor cannot/wouldn't fix the problem, attempt to fix the fonts yourself. (loading and resaving the fonts in a standard font editor, like FontLab or Fontographer, should fix this error, but may introduce others.) In the case of mathtime, you may consider switching to TMMath, which is a better designed and a larger font family which is also AR5-compatible.

If you encounted a problem with Acrobat5 which this document does not explain, please contact us at


Last Updated: May 16, 2001.
(C) MicroPress Inc., 2001. All Rights Reserved.