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...
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.
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:
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].
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.
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.
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.
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.
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.
| Problem | Error on PostScript print.
|
|---|
| Cause | Adobe bug in handling subsetted fonts.
|
|---|
| Solution | Embed fonts as CFF's.
|
|---|
| Credit | DR, 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.
| Problem | Error on PostScript print.
|
|---|
| Cause | AMS/BlueSky/trY&crY coding.
|
|---|
| Solution | Embed fonts as CFF's.
|
|---|
| Credit | IT.
|
|---|
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).
| Problem | JavaScript broken when /NeedAppearances occurs.
|
|---|
| Cause | Adobe.
|
|---|
| Solution | None yet.
|
|---|
| Credit | IT.
|
|---|
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.
| Problem | RadioButtons cannot be printed.
|
|---|
| Cause | Adobe.
|
|---|
| Solution | None yet.
|
|---|
| Credit | IT.
|
|---|
(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.
| Problem | AR5 rejects field values given as strings.
|
|---|
| Cause | Adobe.
|
|---|
| Solution | Code them as names, or use HH's Perl script to fix
older documents.
|
|---|
| Credit | HH
|
|---|
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
support@micropress-inc.com.
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
support@micropress-inc.com.
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
support@micropress-inc.com
MICROPRESS HOME
