diff options
Diffstat (limited to 'Master/texmf-dist/doc/latex/IEEEtran/testflow_doc.txt')
-rw-r--r-- | Master/texmf-dist/doc/latex/IEEEtran/testflow_doc.txt | 2000 |
1 files changed, 2000 insertions, 0 deletions
diff --git a/Master/texmf-dist/doc/latex/IEEEtran/testflow_doc.txt b/Master/texmf-dist/doc/latex/IEEEtran/testflow_doc.txt new file mode 100644 index 00000000000..527eae5e30c --- /dev/null +++ b/Master/texmf-dist/doc/latex/IEEEtran/testflow_doc.txt @@ -0,0 +1,2000 @@ + +testflow_doc.txt V1.0a 2002/08/13 + +Note: This text file uses UNIX line feed conventions. When (human) +reading this file on other platforms, you may have to use a text +editor that can handle lines terminated by the UNIX line feed +character (0x0A). + +written by Michael Shell +mshell@ece.gatech.edu + +See the CTAN distribution website for current contact information +and the latest version: +http://www.ctan.org/tex-archive/macros/latex/contrib/supported/IEEEtran/ + + +This is the documentation and user guide for testflow.tex which is designed +to test the "print work flow" of LaTeX systems. Originally constructed for +users of the IEEEtran.cls file, the information contained here has broad +applicability to anyone wishing to obtain correct PS/PDF output on LaTeX +systems. IEEEtran users often have more difficulty in this regard than the +average LaTeX user as IEEE documents use Times Roman for the main text and +Computer Modern for mathematics - a combination notorious for causing +trouble with some dvips configurations. + +IEEEtran users should take note that the IEEE may delay (or refuse to accept) +submitted PostScript or PDF documents that fail to properly use and embed +the Type 1 fonts as tested by testflow. + +Please note that specific recommendations are subject of frequent change, +so that their timeliness cannot be guaranteed. Nevertheless, this guide +might be helpful even if not always quite up to date. + +Testflow.tex is based on Rainer Schoepf's testpage.tex, the standard LaTeX +test page which is included with most LaTeX systems. + + + *** Legal Notice *** +This information is offered as-is without any warranty either expressed or +implied; without even the implied warranty of MERCHANTABILITY or FITNESS +FOR A PARTICULAR PURPOSE! User assumes all risk. The opinions expressed +here are entirely that of the author(s). + +The testflow package may be distributed and/or modified under the terms of +the LaTeX Project Public License, either version 1.2 or, at your option, +any later version. The latest version of this license can be found at: +http://www.latex-project.org/lppl.txt + +Copyright by Michael Shell, 2002 + +------------------------------------------------------------------------ +Changelog: + +V1.0 2002/04/15 Initial release +V1.0a 2002/08/13 Some clarifications and additions to the documentation + +------------------------------------------------------------------------ + + + + *** OVERVIEW *** + +Getting correct PostScript (PS) or Portable Document Format (PDF) output +("post processing") from LaTeX systems can be surprisingly difficult. +A number of factors have conspired to create this situation. + +First of all, TeX, the underlying engine of LaTeX, is designed to do +typesetting only (arrange boxes of objects) and not to handle the +description of those objects that are to be typeset (pdfTeX not +withstanding). It is a stunning revelation to many LaTeX users to realize +that TeX, being able to create the most beautiful documents, is totally +blind! This design choice gives TeX much immunity to changes in the +rapidly evolving computer font/printing world. + +However, there is a price to be paid for this benefit. Because, in TeX, the +act of typesetting a document and the act of describing what the typeset +objects (glyphs, images, etc.) look like, are two different things, it is +possible to do one perfectly (run LaTeX) and yet fail miserably in the other +task (make printable output). + +IT IS NOT ENOUGH TO ENSURE THAT THE .tex FILE IS CORRECT. A USER MUST ALSO +ENSURE THAT THE APPLICATIONS WHICH GENERATE THE PRINTABLE FILES FROM LaTeX +OUTPUT ARE CORRECTLY CONFIGURED FOR THE CURRENT STATE OF PRINTING +TECHNOLOGY. + +Secondly, a rather large number of "interaction" bugs have surfaced as +changing PS/PDF writers, readers and fonts interact with each other in +factorially increasing ways. Compounding this problem even further is the +fact that software vendors are sometimes slow to correct flaws in their +products which affect only free software like LaTeX. + +Finally, most books on LaTeX do not provide adequate information about +making printable files from LaTeX. + +It should be noted that this author's LaTeX system is from the teTeX UNIX +(Linux) based distribution and uses dvips and Ghostscript to obtain PDF +output. A lot of the information contained here is from that perspective. +However, most of this information is broadly applicable to other platforms +such as MS Windows (MiKTeX, etc.). Option names provided by the graphical +interfaces to the PS/PDF utilities almost always correspond closely to +those provided by the basic UNIX command prompt interface. + +Most lacking is information related to the commercial applications like +YandY, VTeX, PCTeX, and Adobe Acrobat as the cost of obtaining various +versions of each is prohibitive. Furthermore, purchasers of these systems +expect, and are entitled to, some degree of support from the software +manufacturer. So, technical support information like this document tends +to be more vital to the users of the free systems. + +Additional sources of information related to PS/PDF generation under LaTeX +include: + +1. Markus Kuhn's "Effective Scientific Electronic Publishing": + http://www.cl.cam.ac.uk/~mgk25/publ-tips.html + +2. Timothy Van Zandt's "Tex to PDF": + http://zandtwerk.insead.fr/tex2pdf.html + +3. Robin Fairbairns' "TeX FAQ": + http://www.tex.ac.uk/cgi-bin/texfaq2html?label=dvips-pdf + + + + *** TERMINOLOGY *** + +Some definitions are in order for those users who are not familiar with the +terminology used here. + +<texmf>: +This refers to the root directory of a TeX installation. For example, +for many UNIX users this often is /usr/share/texmf or +/usr/local/teTeX/share/texmf +For MiKTeX it often is: c:\texmf + +PostScript (PS): +A programming language, developed by Adobe Inc., that is designed for the +mathematical description of the shapes of lines, curves, and other elements +of letters, figures and images. PostScript interpreters, which can run +PostScript code, are often found in high-end printers. Within such +printers, the act of running the PostScript program produces a bitmap of +pixels (this process is called rasterization) which represent the pixelized +image that is to be formed (with ink or toner) on the printed page. + +Portable Document Format (PDF): +Also developed by Adobe Inc., PDF is a kind of subset of PostScript. PDF is +not a programming language as it lacks PostScript's conditional branching +ability. PDF does have very good support for indexes and hyperlinks. It is +designed to be a document archiving and sharing format. + +[Side note: PostScript and PDF are important, even if the target printer + does not understand PostScript, because these languages are the primary + means by which portable, precisely typeset, print documents are described + today. When using non-PostScript printers, the application that is used to + print the PS/PDF file does, possibly with help from another application or + driver, the conversion from PS/PDF to the native printer tongue. With some + recent modern "brain-dead" printers, the host CPU even does the entire + rasterization for the printer.] + +Font substitution: +The process of using a different font, usually for purposes of viewing or +printing, from that which a document originally used. Font substitution +can occur when the font is not available, or when its use is otherwise +not possible or discouraged. + +Font embedding: +The process of placing the description of the glyphs that make up a font, +into a file that uses these glyphs. This allows the file to be +viewed/printed on a system that would otherwise not have access to the +needed fonts. The main disadvantage is an increase in the size of the file. + +Font subsetting: +The process of embedding only those glyphs that are actually used in a +font, rather than all of the glyphs in that font. Files that use subsetting +can be smaller than those in which the full font is embedded. Subsetted +fonts are given new, unique names within the document in which they are +subsetted. Many commercial font licenses require font subsetting for any +document containing the commercial font in order to reduce the possibility +of font "piracy". + +Maximum subset percentage: +For PDF making applications, the percentage of glyphs in a font that must +be used beyond which the entire font is embedded instead of just a subset. +For example, if the maximum subset percentage is 75%, and 77% of the glyphs +in a font are used in a document file, the entire font may be embedded +rather than just a subset. Thus, to always ensure subsetting, the maximum +subset percentage should be set to 100% (or to 99% if that is the maximum +value allowed). + +Adobe Acrobat: +This is Adobe's application family for creating, viewing and printing PDF +files. Adobe Acrobat Distiller, available only at cost, is used to make PDF +from PostScript. Those using the full version of Adobe Acrobat should use +Adobe Distiller, not Adobe Pdfwriter, to make high quality PDF. + +Adobe Acrobat Reader: +Adobe Acrobat Reader is a free utility from Adobe +(see: http://www.adobe.com/products/acrobat/readstep2.html) +that can be used to view and print PDF files. Because Acrobat Reader is +ubiquitous, it is important that all PS/PDF LaTeX output that is intended +to be shared with others should work with it - if at all possible. +Furthermore, because Acrobat Reader can be used to show useful font +information about the PDF files it renders, it is useful as a diagnostic +tool. + +Ghostscript: +Ghostscript is a freely available (the most recently released versions are +subject to a few months of commercial use restrictions) PostScript +interpreter and translator (see www.ghostscript.com). Ghostscript is the +underlying engine behind many applications, especially those in the UNIX +world, that can view PostScript/PDF. Ghostscript can also convert +PostScript to other formats, such as PDF or to various printer languages. +It can be thought of as a free alternative to Adobe's Acrobat Distiller +family. + +Type 1 font: +In the context of this document, a font in which the glyphs are described +in vector form in the PostScript language. This type of font is desirable +because the glyphs will be rendered by the printer as precisely as is +possible for the given printer resolution. Because type 1 fonts are +rasterized only when actually viewed or printed, storing them within a +document requires a constant amount of space - regardless of the resolution +they ultimately will be rendered at (within the printer or on-screen viewer). + +Type 3 font: +In the context of this document, a font in which the glyphs are described +in bitmap form. This type of font is undesirable because the glyphs will be +rendered a bitmaps that often have inferior resolution and quality to that +attainable by the printer. The result can be "jaggedly" looking text. The +space required to store type 3 fonts within a document increases with their +resolution. So, very high resolutions may not be practical for type 3 fonts. + +Base PostScript fonts (also known as the "base 13" or "base 14" fonts): +The fonts that are guaranteed to be resident in every PostScript (and PDF) +interpreter/viewer/printer. These include Times Roman, Helvetica, Courier, +with their bold, italic and italic+bold variants, and Symbol. (In LaTeX, +using the PostScript fonts via times.sty: Times Roman = \rmfamily; +Helvetica = \sffamily; and Courier = \ttfamily.) In addition to these 13, +PDF readers also must also contain the ZapfDingbats font for a total of 14. +Generally speaking, the base 14 fonts are not required to be embedded +within a PDF file. A special thanks to Henry Churchyard for his clear +description of this state of affairs. + +Nimbus fonts: +It may come as a surprise to many people, but the base 14 fonts are +copyrighted and cannot be used for the purposes of document creation +without buying a license to use them from Adobe. This license fee is also +buried within the cost of every "Genuine Adobe PostScript" printer (or +cartridge or SIMM or Distiller program) that is sold. Fortunately, in the +early 1990's the URW font company generously donated their professional +quality type 1 clones of the base 14 fonts to the X Consortium. These +"Nimbus" fonts can now be used without having to pay royalty fees and are +the base 14 fonts that are distributed with the free versions of LaTeX and +Ghostscript. The differences between the "real" Adobe base 14 and the +Nimbus fonts are, to the vast majority of LaTeX users, insignificant. + +Computer Modern (CM) fonts: +The famous Dr. Donald E. Knuth, TeX's creator, also created a set of fonts +to go with it. These Computer Modern fonts are very extensive in that they +contain a comprehensive set of mathematical symbols. The Computer Modern +fonts that Knuth released were created in the METAFONT language - which was +also developed by Knuth. Unfortunately, METAFONT never became widely +available in printers (like PostScript did). For these reasons, the +rasterization of the Computer Modern fonts (conversion from METAFONT to +type 3 bitmap) is often the default behavior of many LaTeX systems when +generating PostScript using dvips. When LaTeX systems use such type 3 +fonts, the resulting PostScript (or PDF) file will not always yield the +best quality possible on every printer because the rasterization process +can be optimal only for a given printer resolution. + +BlueSky fonts: +In 1997, Blue Sky Research Inc., in conjunction with the American +Mathematical Society (AMS) and YandY Inc., released its professional +quality type 1 (PostScript) versions of the Computer Modern fonts into the +public domain. The BlueSky fonts have since been widely distributed with +the free LaTeX systems. However, these systems are often not configured to +use the BlueSky fonts by default. There is also another freely available +set of type 1 Computer Modern fonts that are known as the BaKoMa fonts. +The BaKoMa fonts are generally considered to be inferior in quality to the +BlueSky fonts, so the latter is usually preferred. + + + + *** USING THE TESTFLOW FILES *** + +The testflow suite consists of five main files in addition to this +documentation. + +testflow.tex is to be compiled on the user's system after which a +testflow.ps and/or testflow.pdf output is to be produced. When being +compiled, testflow will prompt the user for the desired paper size. US +letter users should answer with "letterpaper" and A4 paper users should +respond with "a4paper". The user will then be asked if testflow is to also +test the picture and lasy fonts. Most users should answer "yes", even if +they infrequently use these fonts. + +testflow_ctl_LTR.ps, testflow_ctl_LTR.pdf, testflow_ctl_A4.ps, and +testflow_ctl_A4.pdf are "control" PostScript and PDF files, in US letter +and A4 paper sizes, from a (hopefully) known good source. Because PDF is +the primary means by which print documents are shared, the user will +probably be interested only in the PDF versions. However, the PostScript +versions are provided as a way to determine if the problem is occuring when +creating PostScript or when creating PDF. For instance, if a (dvips) user +is having a problem making a good PDF from testflow.tex, but can make a +good testflow.pdf from testflow_ctl_LTR.ps, then chances are the problem is +with their dvips or fonts (that got embedded in the PostScript file) and +not the application that is making PDF from PostScript. The PostScript +versions use level 1 PostScript and so should be compatible with all +PostScript interpreters. The control PDF files use PDF level 1.3 and should +work properly with Acrobat Reader versions 4.0.5 or later. + +The idea is to have the user try to compare their output to the control +files in order to determine if there is a problem and, if so, where it +is occurring. + +The testflow test suite cannot catch every possible type of error, but it +is designed to detect the problems LaTeX users are most likely to encounter. + +BECAUSE MANY PS/PDF GENERATION BUGS SHOW UP ONLY WHEN PRINTING. IT IS NOT +ENOUGH TO VERIFY THAT THE FILES "LOOK OK" ON SCREEN. The on-paper +appearance of the control files should be carefully compared to that +created and printed on the user's system from testflow.tex. Be sure that +the application that is used to print the PDF file (i.e., Acrobat Reader) +does not scale the page - i.e., ensure that any "fit to page" or +"shrink/expand" printing options are not selected. + +TESTFLOW.TEX IN NO WAY DEPENDS ON IEEETRAN.CLS OR ANY OTHER LATEX CLASS OR +PACKAGE OTHER THAN THE BASIC ARTICLE CLASS. Problems with testflow will be +caused by configuration problems with the user's LaTeX setup - not problems +within class files. + +Be forewarned that testflow.tex is designed to trigger many known bugs in +PS/PDF generator applications. + + + + + *** INTERPRETING THE RESULTS *** + +There are several things that testflow is designed to check. Carefully go +through each of the items below to ensure that they are correct for the +testflow.pdf that was created on the LaTeX system to be tested. The +testflow PS/PDF control files serve as "correct" reference examples. + +It is assumed that Acrobat Reader is what is used to view/print the PDF +files. + + + +*** Margins and Indicated Paper Size*** + +Testflow provides both metric (mm) and imperial (0.1in) rulers to indicate +the distance from the edges of the main text area to the edges of the +paper. Testflow should have 1in (25.4mm) margins on all four edges. Note +that most printers cannot print within less than 0.3in (8mm) to the edges +of the paper, so the rulers will usually not be visible all the way to the +edges of a printed page. + +NOT ACCEPTABLE: THE FOUR MARGINS ARE NOT EQUAL ON SCREEN OR ON PAPER. +Printers do not have perfect mechanical accuracy, so offsets of 0.25in +(6mm) or so may be acceptable in print. However, gross errors here should +be investigated and corrected. + +NOT ACCEPTABLE: WHEN VIEWING THE PDF FILE, ADOBE ACROBAT READER INDICATES +A PAPER SIZE THAT IS NOT CORRECT. (It should be 8.5inX11in for US letter, +and about 8.26inX11.69in [210mmX297mm] for A4 pages.) + +BY FAR THE MOST COMMON CAUSE OF INCORRECT MARGINS AND/OR INCORRECT +INDICATED PAPER SIZES IS THAT PDFTEX AND/OR DVIPS AND/OR GHOSTSCRIPT +(PS2PDF) HAVE BEEN CONFIGURED FOR A DEFAULT PAPER SIZE THAT IS DIFFERENT +FROM THAT USED IN THE LATEX DOCUMENT. + +PdfTeX/PdfLaTeX users should read the application configuration section +below for information on configuring pdfTeX. + +dvips can be told to use a certain paper type via the command line: + +dvips -t letterSize -o myfile.ps myfile +or +dvips -t A4size -o myfile.ps myfile + +[Note the difference in the capitalization of the first letter of "Size" + is common in the paper size commands of the dvips' configuration files.] + +However, if the default paper size is not what is normally used, it is +better to modify dvips' configuration files. This is especially important +to US letter paper users as dvips is typically set up to default to A4 +paper. See the application configuration section below for more +information on configuring dvips. + +Ghostscript (ps2pdf) also has a command line option to set the paper size: + +ps2pdf -sPAPERSIZE=a4 myfile.ps myfile.pdf + +Ghostscript users should read the application configuration section below +for information on configuring and using Ghostscript. Advice for Adobe +Distiller is similar to that for Ghostscript. + + +[Side note: HP Laserjet II/III users should take note that a design flaw + in the Canon SX engine can cause these venerable older printers to shift + text (downward) on pages that quickly follow a previous page. The problem, + which affects SX based printers with "high-mileage", is caused by the + magnetization of the paper control solenoid levers coupled with the + degradation of the solenoid stop pad material.] + + + +*** Line Widths *** + +All of the tick marks on all of the rulers have identical line thickness. +Some tick marks should not appear to be thicker than others. This problem +may be visible in the Acrobat Reader display, especially under normal +magnifications such as 125%, as well as in its print (most obviously in +the small tick marks on the metric rulers). + +ACCEPTABLE, BUT UNDESIRABLE: SOME OF THE TICK MARKS ARE THICKER THAN +OTHERS. + +This problem is the result of the way the PostScript algorithm handles the +rasterization of lines (and other constructs). The PostScript rasterization +policy is that, if *any* part of a pixel is touched by a line, then that +pixel is turned on. So, depending upon where a line falls, its thickness +can vary by the width of a printer's pixel. (Thanks to Michael Fryd for his +excellent post on this topic in 1990.) + +This is why dvips features a "snap grid" resolution parameter (e.g., "-D") +that "snaps" image objects to the pixel grid of the user's printer. The +problem with this approach is that one has to know the printer's resolution +in advance, and, therefore, file portability is slightly compromised. + +For instance, to make good PostScript for a 300dpi printer, one could do: + +dvips -D300 -o myfile.ps myfile + +However, for PDF converters, and printers with other than 300dpi resolution, +the resulting PostScript file will be less than optimal. + +Note that dvips also uses the -D parameter to set the resolution at which +type 3 fonts are rendered. The snap grid (positioning) mechanism and the +type 3 font rasterization mechanism cannot be controlled independently +in current versions of dvips. Therefore, if a document is using any type 3 +fonts, -D will have to be kept to a reasonable level (say <= 1200) to prevent +the file size from becoming unacceptably large (or to prevent errors from +occurring because the rasterizing applications could not handle such a high +resolution for type 3 fonts). This is another reason to try to avoid the use +of type 3 fonts. + +This guide assumes that the user wishes to ultimately make PDF (using only +type 1 fonts) and use that as a portable format to distribute documents +(after all that's why they call it Portable Document Format). So, to make +a PostScript file that is more suitable for PDF conversion, dvips should be +told to use a very fine grid: + +dvips -D7200 -o myfile.ps myfile + +The testflow PostScript control files take this latter approach, and so +they may have less than perfectly consistent line thicknesses when printed +to printers with lower resolutions (especially below 600dpi). However, the +testflow control PDF files should print very well on any decent printer. + +The line thickness anomalies are also aggravated by the fact that dvips +treats lines as filled rectangles instead of drawn lines. Fortunately, +Timothy Van Zandt developed an alternative dvips line drawing algorithm +and made it publicly available. + +See the section below on dvips configuration for information on how to +configure dvips to obtain Postscript for making PDF with consistent line +thicknesses + + + +*** Fonts *** + +Because Adobe Acrobat Reader can be used to display font information for +PDF files, it is useful as a diagnostic tool. View the testflow.pdf under +Acrobat Reader. Enlarge the window size and/or zoom out so that the entire +page is visible at once. This step is necessary as Acrobat Reader may need +to see the entire page before full font information is available. Now, +select File->Document Info->Fonts->List All Fonts + +Alternatively, Derek Noonburg's free xpdf viewer now comes with tools for +obtaining information about PDF files, including fonts: + +http://www.foolabs.com/xpdf/ + +On systems with recent xpdf installations, one can easily do: + +pdffonts testflow_ctl.pdf + +to obtain comprehensive font information. Although xpdf is currently only +available for UNIX systems, its associated tools (including pdffonts) is +also available for MS Windows platforms. In my opinion, pdffonts is a better +tool than Acrobat Reader for obtaining font information. Thanks to Mukesh +Agrawal for telling me about pdffonts. + + +Every font should be listed as a Type 1 or Type 1C. Any type 3 fonts that +are listed will likely be rendered as a bitmap. The result will be +"jaggedly" looking text. Type 1 fonts are typically in vector form, which +means that they will always be properly rendered at their sharpest for +every printer. + +Every font, with the allowable exception of those in the Times and Courier +(which may be named as "Nimbus") families, should be listed as "Embedded" +preferably "Embedded Subset". + +NOT ACCEPTABLE: SOME FONTS ARE LISTED AS TYPE 3 +This problem is most often caused by the fact that dvips has not been +configured to use the Type 1 versions of the Computer Modern fonts - also +known as the BlueSky fonts. Most LaTeX systems already have these fonts +installed, so it is usually just a matter of telling dvips to use them. +See the dvips font configuration section below for details. + +NOT ACCEPTABLE: FONTS, OTHER THAN THOSE IN THE BASE POSTSCRIPT FAMILIES, +(TIMES AND COURIER FOR TESTFLOW) ARE NOT LISTED AS BEING EMBEDDED IN THE +"USED FONT" COLUMN. Fonts other than the base PostScript fonts must be +embedded or else these fonts may not be viewable in the PDF file on other +platforms. See the Ghostscript and pdfTeX configuration sections below for +details. The advice for Adobe Distiller users is similar to that of +Ghostscript. An additional discussion on this topic can also be found in +the "The Large Times Roman Italic" section below. + +The American Association for Artificial Intelligence (AAAI) has a nice +web page that dramatically illustrates the difference between Type 1 and +Type 3 fonts: http://www.aaai.org/Publications/Author/latex-fonts.html + + +Note: This is not to suggest that EVERY document the user will ever +generate must always contain only type 1 fonts. Some fonts are not yet +available in type 1. One example is the EC fonts (which are a superset +of the Computer Modern) that are currently installed on most LaTeX systems. +On these systems, using T1 encoding: + +\usepackage[T1]{fontenc} + +will result in the use of type 3 fonts. One workaround is to also call the +ae.sty package ( http://www.ctan.org/tex-archive/fonts/ae/ ): + +\usepackage{ae} + +A better approach is to install Vladimir Volovich's CM super fonts package: + +http://www.ctan.org/tex-archive/fonts/ps-type1/cm-super/ + +which provides type 1 versions of the EC fonts. Another potential way type 3 +fonts can appear in a document is from EPS figures that were created by an +application that uses such fonts. + +However, the user's LaTeX system should be able to create a testflow.pdf +that uses only Type 1 fonts. IEEEtran.cls users should take note that IEEE +may delay acceptance of submitted work that uses type 3 fonts - especially +for the main text and mathematics (for which they use the same fonts that +the testflow page uses). IEEEtran.cls users should not use the EC fonts +until it is known that IEEE's system is "EC ready". + + + +*** The Ligature Test *** + +Two sentences are given. Both should read "The office was affected by the +five flawed mufflers.". The first sentence uses ligatures for the ffi, ff, +fi, fl, and fll letter sequences and so will be slightly shorter than the +one below it which does not use ligatures. + +NOT ACCEPTABLE: BRITISH POUND (STERLING) SYMBOLS OR OTHER STRANGE +CHARACTERS APPEAR IN THE SENTENCE THAT USES LIGATURES. This is caused by a +dvips setup that enables the "G1" option. This dvips feature was designed +to work around a bug in the obsolete Acrobat Reader 3.0 series. "G1" should +no longer be used as it wreaks havoc on documents that use fonts other than +Computer Modern. Either force dvips on the command line to use "G0": + +dvips -G0 -o myfile.ps myfile + +or, better yet, alter its configuration to turn off the G1 option. + +In particular, MiKTeX's dvips config.pdf file enables G1 with a "G" line. +The offending line should be commented out. + +dvips versions 5.86h and later have been revised so as to not cause this +problem even when using the -G1 option with non-Computer Modern fonts. + +See the dvips configuration section below for details. + + + +*** The Large Delimiter and Operator Test *** + +The matrix should be enclosed in brackets. The equation to the right of it +should be enclosed in parentheses. The equation should have a summation +symbol. + +NOT ACCEPTABLE: SOME PARTS OR ALL OF THE BRACKETS, PARENTHESES OR SUMMATION +SYMBOLS ARE MISSING. This is caused by bugs in Acrobat reader 4.0.0 and +prior and/or versions of Ghostscript prior to 6.50. The solution is to +upgrade both these applications. + + + +*** The Minus Sign Test *** + +The equation shown should yield a true statement. + +NOT ACCEPTABLE: SOME OF THE MINUS SIGNS ARE MISSING, ESPECIALLY IN THE +SUPERSCRIPTS. Acrobat readers prior to Version 4.0.5 have this problem. So +does Ghostscript versions prior to 6.50. The solution is to upgrade both +these applications. + +Note: If the minus signs look like underscores, but display properly when +"zoomed in" - this is not a bug, but an Acrobat Reader feature that +"Greeks" text that is smaller than a certain amount. To turn this bogus +thing off, select File->Preferences->General and deselect the "Greek Text" +option. + + + +*** The Math Italic Glyphs *** + +The LaTeX math symbols \Gamma, \Psi, \Omega, \gamma, \psi are shown in +\mathnormal (italic) shape with the text \t{} tie-after accent at the end +of the group. These glyphs are in the "control character" positions of +their font files. + +NOT ACCEPTABLE: SOME OF THE SYMBOLS ARE MISSING OR WRONG. Versions of +Acrobat Reader prior to 4.0.5 and Ghostscript versions prior to 6.50 +assume that these positions will always contain control characters +and never will have a valid glyph. As a result, these glyphs will not +display or print properly. The solution is to upgrade both these +applications. + + + +*** The Large Times Roman Italic *** + +ACCEPTABLE, BUT NOT IDEAL: IT IS PROBABLY OK IF THE STYLE OF THE "z" +DIFFERS FROM THAT OF THE TESTFLOW CONTROL PDF FILE (WHICH EMBEDS THE BASE +14 FONTS). + +A standard PostScript Times Roman italic lower case "z" has a curly bottom. +However, a Times New Roman "z" has a straight bottom. (Note that "new" here +does not mean that this is a newer or otherwise improved font - just one +that is slightly different and whose copyright is owned by a different +party.) + +This test illustrates a little known "feature" of Acrobat Reader. Microsoft +has pressured Adobe to make Acrobat Reader (even UNIX versions) perform +certain font substitutions on the base 14 PostScript fonts when they are +not embedded in the PDF file. However, when printing to a PostScript +printer, the original base 14 fonts will still be used. + +This idiotic policy means that, if the base 14 fonts are not embedded in +the PDF file, when using a PostScript printer, what is printed by the +printer will not be the same as that seen on screen, but will be the same +as is called for in the original LaTeX source of the document. But, for a +non-PostScript printer, what is printed by the printer will be the same as +that seen on screen, but will not be exactly the same as is called for in +the original LaTeX source of the document. + +Everybody got that? What a mess! + +For this reason, Adobe now recommends that all fonts, including the base +14, should be embedded and subsetted in the PDF files. + +For a statement by Adobe, see: +http://www.pdfzone.com/news/adobefontstatement.html + +Additional information on the topic can be found in: +ftp://ftp.tug.org/mail-archives/pdftex/2000.10.gz +(in the entries starting on October 4th) +Thanks to Nelson H. F. Beebe of the University of Utah for posting about +this issue. + + +[Side note: Some of the earlier PostScript interpreters, such as the Adobe + level 1 PostScript Cartridge for the HP LaserJet II and the HP level 1 + PostScript Cartridge for the LaserJet III, used a Times Roman italic z + with a flat bottom, but it was curly in bold italic.] + + +If the "z" has a straight bottom as displayed on screen, it is a sign that +the standard base 14 fonts have NOT been embedded and that Acrobat Reader +has substituted, without the user's consent, some of the base 14 fonts. +This is ordinarily not too much of problem, but there is an issue to be +aware of: SOME OF THE SUBSTITUTE FONTS DO NOT HAVE ALL OF THE GLYPHS OF THE +ORIGINAL FONTS AND MAY NOT BE DISPLAYED ON SCREEN, OR IN THE PRINT OF A +NON-POSTSCRIPT PRINTER! Most of the missing glyphs involve math symbols, +so this is rarely a problem under LaTeX which usually uses the much more +mathematically extensive (non-base 14) Computer Modern fonts for +mathematics. + +THE ONLY WAY TO ENSURE THAT A PDF FILE WILL ALWAYS BE RENDERED ON THE +ACROBAT READER SCREEN EXACTLY AS IT WAS CREATED, AND AS IT WILL BE PRINTED, +IS TO EMBED AND SUBSET THE BASE 14 FONTS INTO THE PDF FILE. Subsetting +provides an additional safeguard against potential font substitution as +subsetted fonts are given unique names. Note that embedding the base 14 +fonts will increase the size of the resultant PDF file. + +Ghostscript versions 7.01 and later will embed the base 14 fonts (Nimbus) +when asked to embed and subset all fonts under a PDF level 1.3 or higher. + +Those using the full version of Adobe Acrobat should use Adobe Distiller, +not Adobe pdfwriter, to make PDF. Recent versions of Adobe Distiller will +embed and subset the base 14 fonts if the "PrintOptimized" or +"PressOptimized" settings are selected. The former is probably preferable +to the latter in most cases. See the Adobe Distiller parameter manual: + +http://partners.adobe.com/asn/developer/acrosdk/DOCS/distparm.pdf + +for more details. + + + +*** The GS Kerning Test *** + +A footnote sized sentence is displayed: + +``The Problematic" little quotes. + +NOT ACCEPTABLE: THE QUOTE MARKS "CRASH INTO" THE "P" OR ARE TOO CLOSE TO +THE WORD "LITTLE". + +This is caused by a bug in the PDF level 1.2 output of Ghostscript versions +7.00-7.05 (as well as the 7.20-7.21 developer versions). It has been fixed in +releases dated after 2002/07/31. A work around is to use only PDF level 1.3 +output via the use of -dCompatibilityLevel=1.3 when making PDF using +Ghostscript. + +Do not ignore this problem because it looks like a small defect. There are +other manifestations that are much more severe. + + + +*** The Picture and Lasy Fonts Test [Optional] *** + +LaTeX has a special set of fonts used to construct simple pictures and a +set of fonts (the "lasy" fonts) with rarely used symbols. The original +release of the type 1 versions (BlueSky) of these fonts contained some, +normally harmless, extraneous information within the font files. However, +Acrobat Readers in the 5.0 series are intolerant of this extra information +and will generate a "font error" when printing to a PostScript printer. +There may or may not be noticeable problems in the resulting print. + +NOT ACCEPTABLE: ACROBAT READER 5.X GENERATES A FONT ERROR WHEN PRINTING TO +A POSTSCRIPT PRINTER. + +This error message may not a reliable indicator of whether or not the +user's LaTeX picture and lasy fonts have the offending data as an error +message may not be triggered unless the document uses a certain number of +glyphs from the affected fonts and Acrobat Readers after 5.0.5 may not be +sensitive to it. + +The purpose of the picture/lasy fonts test is to trigger this error on +Acrobat Reader versions 5.0.0 and 5.0.5. There is nothing in particular in +the picture test that the user need look for. + +The picture and lasy fonts are located in the +<texmf>/fonts/type1/bluesky/cm/ directory and consist of the lasy*.pfb, +lcircle*.pfb and line*.pfb files. + +To correct this problem, a new set of LaTeX picture and lasy fonts were +released on June 6, 2001. It is easy to tell the difference between the old +and new fonts via their file sizes. Two examples are shown here: + +Font File Old New + +line10.pfb 10898 11036 + +lasy10.pfb 4684 4822 + +The latest version of the BlueSky font files can be obtained for free at: + +http://www.ctan.org/tex-archive/fonts/cm/ps-type1/bluesky/ + +Upgrading is as simple as replacing the old .pfb files in +<texmf>/fonts/type1/bluesky/cm with the new ones. + +There are other, less commonly used, fonts that may have other problems. +For example, in December 2000, an update was made to the txfonts: +ftp://ctan.tug.org/tex-archive/fonts/txfonts/ +as the older txfonts caused error messages in dvips versions prior to +5.86d. + +Ghostscript 6.50, dvips 5.86d and later may automatically correct some font +errors and shield the user from some font related problems. However, users +are strongly urged to upgrade to the corrected font sets. + + + + + *** APPLICATION VERSION AND CONFIGURATION INFORMATION *** + +*** Acrobat Reader *** + - version information - +NOT ACCEPTABLE: ACROBAT READERS PRIOR TO VERSION 4.0.5 + +Anything before version 4.0.5 is too buggy to be considered as even +remotely usable with PDF documents created with LaTeX systems. + +Determining the application number on Windows platforms is easy. See the +upper left corner of the Acrobat Reader startup banner, or the +Help->About_Acrobat_Reader window, for the 3 digit version number - i.e., +5.0.5. + +However, determining the version of Acrobat reader is not always trivial +because Acrobat Readers under UNIX may not display a version number. The +version may have to be inferred from the date. For Acrobat readers under +Linux go to the Help->About_Acrobat_Reader window. It should display a date +of January 2000 or later - this will mean version 4.0.5 or later. + + - configuration information - +When printing from Acrobat Reader, make sure that there are not any +selected "fit to page", "shrink page" or "expand page" options. Otherwise, +the print WILL be altered in size. The File->Page_Setup menu should be +checked to ensure that the page size is correct before printing. A4 paper +users should take note that Acrobat Reader has a very vile bug that resets +the printer page size to US letter every time Acrobat Reader is restarted. +The author does not know a workaround for Windows users, but UNIX users can +use a startup ("wrapper") script that resets the default Acrobat Reader +printer page size before starting Acrobat Reader. An example script with +documentation in the comments is shown here: + + +#!/bin/sh +# +# No warranty expressed or implied. User assumes all risk. +# +# This is a start script for Acrobat Reader that adjusts the default +# page size for the printer settings in the user's ~/.acrorc file +# before starting acroread. There is a long standing bug, that has +# been reported to Adobe numerous times over more than a 4 year period, +# in Acrobat Reader in that it will not write the user's choice of +# printer paper size to the .acrorc file, but will instead always +# record the US letter paper size when exiting. This is most +# infuriating to users of other paper types such as A4 as they will +# then have to select their paper size again every time acroread is +# restarted. +# +# If this isn't a good example of the problems with closed source +# software, I don't know what is. +# +# Within the .acrorc file, there is an entry: +# *PaperSize: 0 +# that determines what paper size acroread will default to on startup. +# The integer codes are as follows: +# +# 0 = letter +# 1 = tabloid +# 2 = ledger +# 3 = legal +# 4 = executive +# 5 = A3 +# 6 = A4 +# 7 = A5 +# 8 = B4 +# 9 = B5 +# 10 = other +# +# The idea is to call perl to parse the .acrorc and replace the +# PaperSize integer code with what the user desires and then start +# acroread. This script may be called "acroread" and located in the +# $PATH search before the real acroread, or called something else +# like "acrostart". +# +# Below in the perl line, the number that follows the \t will be the +# value PaperSize is set to - adjust as needed. Also, adjust the exec +# path to point to the acroread executable\start script. +# +# This script was originally posted by Moritz Barsnick in 2000/07. +# Comments added by Michael Shell in 2002/04 for use in the LaTeX +# testflow documentation. +# +# Known limitation: If one goes into the Acrobat Reader File->PageSetup +# menu and then presses <Cancel> - Acrobat Reader will set it back to +# US letter! So, always press <OK> instead to keep the existing page +# size. +# +# Alternatively, one could use a .acrorc2 file and use cp to overwrite +# .acrorc entirely, but this would not allow _any_ options to be saved +# from the acroread menus. +# +perl -i.perlbak -pe 's/^\*PaperSize:.*$/\*PaperSize:\t6/' "$HOME"/.acrorc; +exec /usr/local/Acrobat4/bin/acroread "$@" + + +When printing to a PostScript printer, it may be safest to use the Level 1 +option as the Level 2 and Level 3 options are suspected of producing +incorrect output in some circumstances. It is currently unknown if this +issue was fixed in the Acrobat Reader 5.x series and later. + + + +*** dvips *** + - version information - +RECOMMENDED: DVIPS VERSION 5.85 OR LATER + +Users can identify their dvips version via "dvips -version". + +dvips versions prior to 5.86f have a bug in the subsetting code which can, +with some fonts, cause problems. The symptom will be font related error +messages from dvips like: + +"Second number not found in Char string of /FontName" +or +"XX Subr not found" +or +"ERROR in encoding vector in <XX.pfb>", etc. + +Sometimes these symptoms can manifest themselves in other applications, such +as Adobe distiller or Ghostscript, which are processing (to pdf) the +(improperly subsetted) dvips Postscript output. The one trait they all have +in common is that the problem will go away when the dvips -j0 option is +used to turn off font subsetting: + +dvips -j0 -o myfile.ps myfile + +However, these bugs will manifest themselves only when using fonts that +have subtle problems or that have been reencoded multiple times (a single +glyph is used in more than one font). IEEEtran users should not encounter +this problem unless unusual fonts are used. As mentioned above, the short +term work around is to use the dvips -j0 option which turns off subsetting +- but the resultant files will be larger. A longer term (and better) +solution is to upgrade dvips - see the "Upgrading LaTeX Applications" +section below for information on how to update dvips. + + - default paper size configuration - +In <texmf>/dvips/config there is a file named config.ps. (Note that UNIX +users will require root privileges to alter this file.) Edit config.ps +using a text editor. Toward the latter part of the file, there are lines +that begin with "@". These control the paper size selections. The first +set of these lines determines the default paper size dvips will use. If +this first set of lines does not specify the desired default paper size, +another set of lines can be moved or entered into the first position. +For example, putting: + +@ letterSize 8.5in 11in +@+ %%PaperSize: Letter + +(with a blank line before and after) as the first set of "@" lines will +make dvips will default to using US letter paper. + +Now, there are two types of dvips paper size commands. The first type adds +only paper size *comments* to the PostScript output: + +@ A4size 210mm 297mm +@+ %%PaperSize: A4 + +The @+ line says to place the PostScript comment "%% PaperSize: A4" into +the output file. Such PostScript DSC (Document Structuring Convention) +comments are just hints, or suggestions about which type of paper to use. +In fact many/most PostScript interpreters (Ghostscript, printers) will just +ignore these and use their own default paper sizes. In a way, this is +desirable as the comments will not cause any problems if the PostScript +file is then printed on paper of different size than the comments suggest. + +A second type of dvips paper size command adds a PostScript command which +actively sets and enforces a given paper size: + +@ a4 210mm 297mm +@+ ! %%DocumentPaperSizes: a4 +@+ %%BeginPaperSize: a4 +@+ a4 +@+ %%EndPaperSize + +Note the three comments (The "!" just means place the comment at the +beginning of the PostScript file.) and the "a4" PostScript command. + +Therefore, PostScript produced via "dvips -t A4size ..." is different +from that produced with "dvips -t a4 ...". The former may not always +be automatically identified as wanting A4 paper, the latter may demand A4 +- causing some printers to refuse to print on anything other than A4 paper. + +For instance, ps2pdf (Ghostscript) will have to be told the paper size to +use when processing PostScript files using the first case (without paper +size commands). However, ps2pdf will override command line and/or default +paper selections if it encounters a PostScript paper size command from the +second case. See the Ghostscript configuration section below for more +details. + +Traditionally, the first case has been favored to avoid compatibility +problems (with some buggy older printers). However, there is an increasing +tendency to use the second case as it prevents confusion as to what paper +size a PostScript file "wants". Always use the first case if you think users +might ever want to print on a different paper type, use the second case only +if you know this will never happen. + +There is another dvips paper size issue. The "recommended display window +area" of a PostScript file is contained in a comment known as the +"BoundingBox". A BoundingBox line (for A4) looks like: + +%%BoundingBox: 0 0 595 842 + +The BoundingBox's coordinates are in X0 Y0 X1 Y1 form where X0,Y0 is the +lower left and X1,Y1 is the upper right of the image. The BoundingBox +coordinates must be integers and are in units of 1/72 inch (a PostScript +point, i.e., a LaTeX bp unit). The values used here by dvips are taken from +the lengths given next to the names in its paper size definitions. + +Now, for US letter paper all is well as: + +X1 = 8.5in * 72bp/in = 612 bp +Y1 = 11in * 72bp/in = 792 bp + +But, for A4: + +X1 = 210mm/25.4mm/in * 72bp/in = 595.28 bp +Y1 = 297mm/25.4mm/in * 72bp/in = 841.89 bp + +Now, how should one round? Under normal circumstances, one would say to +round to the closest integer. However, if the BoundingBox is ever smaller +than its contents, some of the image may be clipped. (In practice this may +never happen as printers can not print so close to the edge of the paper +anyway.) Well, guess what: current versions (5.86g and prior) of dvips +always round up and Adobe and Ghostscript round to the closest integer. +So, for A4, the dvips made BoundingBox will be: + +%%BoundingBox: 0 0 596 842 + +While most PostScript parser/reader applications will expect: + +%BoundingBox: 0 0 595 842 + +Normally this is of no consequence. One minor notable issue is that the +UNIX gv (V3.5.8) program uses the BoundingBox to determine the paper size +(if no PostScript paper size commands are present) - and does not recognize +a PS file as wanting A4 if it sees 596 instead of 595. +The workaround is to use: + +@ A4size 594.99bp 841.99bp + +instead of 210mm 297mm for A4 measurements. + +[Those outside the US are probably laughing at this point [pun intended], + but it should be pointed out that this is a standards issue, not a units + issue. Ghostscript versions prior to 7.05 have a very similar problem - + if they are compiled with the -DA4 option, A4 PDF pages produced with + ps2pdf will be very slightly scaled down (about 1%).] + +Versions of dvips after 5.86g will behave like Adobe and GhostScript, +so the work around will then no longer be needed. Thanks to Tomas Rokicki +and Markus Kuhn for finding these little bugs and getting them fixed. + +With all this in mind, a good first set of dvips config.ps paper size +definitions, for US letter paper users, might look like: + + +@ lettersize 8.5in 11in +@+ %%PaperSize: Letter + +@ letter 8.5in 11in +@+ ! %%DocumentPaperSizes: Letter +@+ %%BeginPaperSize: Letter +@+ letter +@+ %%EndPaperSize + +@ a4size 594.99bp 841.99bp +@+ %%PaperSize: A4 + +@ a4 594.99bp 841.99bp +@+ ! %%DocumentPaperSizes: a4 +@+ %%BeginPaperSize: a4 +@+ a4 +@+ %%EndPaperSize + + +A4 users would want to move the "a4size" block to the first position so +that it will be the default. It might also be a good idea to add +"letterSize", "A4size", "A4Size" and "A4" entries so that it will not +matter how a user or script capitalizes the letters in the dvips paper +size definition names. + + + - type 1 font configuration - +Most LaTeX systems already have the Type 1 versions of the Computer Modern +fonts (BlueSky fonts). But, if needed, they can be obtained free of charge +from: + +http://www.ctan.org/tex-archive/fonts/cm/ps-type1/bluesky/ + +However, many LaTeX systems have dvips configurations that are not enabled +to use the BlueSky fonts. To enable their use, dvips' config.ps file should +have the following lines (and they should not be commented out): + +p +bsr.map +p +bsr-interpolated.map +p +hoekwater.map + + +It is normally not needed nor desirable to embed the base 14 fonts into +PostScript files as these are guaranteed to be present in every PostScript +printer and viewer. Furthermore, Acrobat Reader cannot view PostScript, and +therefore is incapable of substituting fonts therein. So dvips' default +settings regarding the base PostScript fonts need not be changed. + + - other configuration - +Other lines which are worthy to be present in dvips' config.ps include: + +D 7200 + +(If dvips output is usually converted to PDF, rather than printed directly.) +This effectively prevents dvips from making adjustments based on an assumed +printer resolution. + +dvips versions 5.86g and later provide increased security against malicious +DVI code (Yes, it is possible to put executable commands in dvi files!). +The z option disables the execution of such code. It is a good idea to put +in the z now, even for systems with older versions of dvips (which will +silently ignore the z option). + +z + +There should NOT be any G option lines like: + +G + +in config.ps or config.pdf. Remove or comment out with "%" any such lines. + +[Note: dvips versions 5.86h and later have been revised so as to not cause + this problem even when using the -G1 option with non-Computer Modern + fonts.] + +In order to implement Timothy Van Zandt's dvips line thickness fix, create +a file named "alt-rule.pro" in the <texmf>/dvips/base directory containing +the following code and comments: + + +% Timothy Van Zandt's alt-rule.pro algorithm to draw rules using +% Postscript's stroke rather than fill. This allows the resulting +% lines to have a more uniform thickness. +TeXDict begin +/QV { + gsave newpath /ruleY X /ruleX X + Rx Ry gt + { ruleX ruleY Ry 2 div sub moveto Rx 0 rlineto Ry } + { ruleX Rx 2 div add ruleY moveto 0 Ry neg rlineto Rx } + ifelse + setlinewidth 0 setlinecap stroke grestore +} bind def +end + + +Now, activate it by inserting the following lines into the +<texmf>/dvips/config.ps file (just before the @ lines is a good place): + + +% Use Timothy Van Zandt's alt-rule.pro algorithm to draw rules using +% Postscript's stroke rather than fill. This allows the resulting +% lines to have a more uniform thickness. It seems to work well with +% no adverse effects. +% tex.pro or texc.pro is loaded by default (texc.pro will be used +% if the Z option is used to compress bitmaps, but we need to call +% tex.pro/texc.pro here because it must be loaded before the +% alt-rule.pro patch). See: http://zandtwerk.insead.edu/tex2pdf.html +% for more details. +% use tex.pro if the dvips Z option is not used +h tex.pro +% or use texc.pro if the dvips Z option is used +% (If in doubt, just use tex.pro - things will work in any case.) +% h texc.pro +h alt-rule.pro + + +After config.ps has been configured as described above, the user can make +good PostScript that is suitable for PDF conversion via: + +dvips -o myfile.ps myfile + +without the need to call any "-Ppdf" options. + +To make PostScript for printing directly to a PostScript printer (or for a +document that is using some type 3 fonts), one should call dvips like: + +dvips -D600 -o myfile.ps myfile + +where the "-D" option specifies the resolution (in dots per inch) of the +printer (or what the desired resolution is for the type 3 fonts - should +be <= 1200 if using type 3 fonts). + +Additional dvips configuration information can be found in the dvips user's +manual which is available at: + +http://www.ctan.org/tex-archive/dviware/dvips/ + + + +*** Ghostscript (Adobe Distiller PDF settings are similar) *** + - version information - + +NOT ACCEPTABLE: GHOSTSCRIPT VERSIONS prior to 6.50 + +Users can identify their Ghostscript version via "gs -version". Anything +prior to 6.50 will cause no end of grief when used with LaTeX. GhostScript +has some impressive progress after the 6.00 release. 6.5x is considered to +be quite stable, but it does not embed the base 14 fonts. The 7.x series +comes with a lot of features, but also with quite a few bugs - two notable +ones of which can bite LaTeX users. Both of these two are related to letter +kerning (spacing). + +The first bug seems to affect the certain small caps fonts such as the AMS +cmcsc8. This bug has been identified, squashed, and is not in the 7.05 or +later releases. It does not seem to affect the standard text fonts used by +LaTeX2e, IEEEtran.cls, book.cls, etc. as these use a scaled cmcsc10 for +\scshape which does not seem to trigger the bug. However, users of the +various AMS classes should watch out for problems. The symptom with be +improper letter spacing (kerning) and is most noticeable in words of +certain lengths that have "av" or "ta" letter sequences in them. The +problem only appears in print - the text will be displayed properly on +Acrobat Reader's screen. + +The second bug causes spacing problems around certain glyphs like quote +marks and ligatures when PDF level 1.2 output is used. This bug is in +versions 7.00-7.05 (as well as the 7.20-7.21 developer versions). It has +been fixed in releases dated after 2002/07/31. A work around is to use +only PDF level 1.3 output via the use of -dCompatibilityLevel=1.3 when +making PDF using Ghostscript. + +Versions 7.04 and later feature an improved security mechanism. This +mechanism can prevent versions of xdvi prior to 22.40j (for the xdvi-k +Kpathsea enabled version which is by far the most popular, for the non-k +version of xdvi the release number to have is 22.57 or later) from being +able to display graphics files referenced by relative paths. i.e., + +\includegraphics{../myfigs/afig.eps} + +would not be shown and an error message like: + +gs: Error: /invalidfileaccess in --file-- + +will be issued. + +A workaround is to to use absolute paths like: + +\includegraphics{/home/myaccount/myfigs/afig.eps} + +or to set the TEXINPUTS environment variable (UNIX) to point to the +directories where the graphic files are and then to avoid placing paths in +the .tex file altogether: + +\includegraphics{afig.eps} + +Other options include: "downgrading" to Ghostscript 7.03 or prior. + +Versions of Ghostscript after 7.04 have even more security enhancements and +even the absolute path PostScript figures that are referenced in dvi file +may not show up under the older versions of xdvi. + +A similar problem may also affect the "gv" viewer (3.5.8 and prior). + + + - configuration information - +A recommended set of command line options when using GhostScript to make +PDF from PostScript is (adjust PAPERSIZE as needed, e.g., a4): +(Note: Commands like this are one long line - line feeds had to be added in +this document to keep line lengths reasonable.) + +gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sPAPERSIZE=letter +-dPDFSETTINGS=/printer -dCompatibilityLevel=1.3 -dMaxSubsetPct=100 +-dSubsetFonts=true -dEmbedAllFonts=true -sOutputFile=myfile.pdf myfile.ps + +The Ghostscript "-dPDFSETTINGS=/printer" is similar to the Acrobat +Distiller "Print Optimized" settings. Some of the other parameters such +as "-dEmbedAllFonts=true" are implied by it, but it is a good idea to be +explicit about them so as not to rely on default values. + +Note: some Ghostscript options begin with "-s" (strings) others begin with +"-d" (values). Ghostscript's "pdfwrite" device is like Acrobat's Distiller, +and should not be confused with the inferior Acrobat "Pdfwriter" device. + +The ps2pdf script should be modified to reflect the above choices of PDF +level and font embedding/subsetting. For instance, a good ps2pdf script on +a UNIX system might look like: + +#!/bin/sh +# Convert PostScript to PDF using LaTeX recommended parameters. +# Adjust default PAPERSIZE as needed. +exec ps2pdfwr -sPAPERSIZE=letter -dPDFSETTINGS=/printer +-dCompatibilityLevel=1.3 -dMaxSubsetPct=100 -dSubsetFonts=true +-dEmbedAllFonts=true "$@" + +Note that the Ghostscript ps2pdfwr script in turn adds the -dSAFER +-dNOPAUSE -dBATCH -sDEVICE=pdfwrite and -sOutputFile options and then calls +gs. + + +Windows based Ghostscript installations use ps2pdf.bat batch files in the +"gs\gsX.YZ\lib" (where X.YZ is the version number of Ghostscript) +subdirectory in the Ghostscript install directory. Users of these should +update them to use the recommended parameters. For example, the PDF level +line in ps2pdf.bat should be changed to 1.3: + +echo -dCompatibilityLevel#1.3 >_.at + +This is important as Ghostscript will *not* embed the base 14 fonts under +PDF level 1.2. Furthermore, PDF level 1.2 is useful only for Acrobat +Reader versions prior to 4.0 - which are too buggy to handle PDF from LaTeX +anyway. + +Then, the other recommended Ghostscript options can be added to +ps2pdfxx.bat (this file is called by ps2pdf.bat, ps2pdf12.bat and +ps2pdf13.bat, hence the "xx" in the filename): + +echo -q -dSAFER -dNOPAUSE -dBATCH -sPAPERSIZE=letter -dPDFSETTINGS=/printer +-dMaxSubsetPct=100 -dSubsetFonts=true -dEmbedAllFonts=true +-sDEVICE#pdfwrite >_.at2 + + +Because additional command line options can override previous ones, it is +easy enough to override ps2pdf's default options if needed: + +ps2pdf -sPAPERSIZE=a4 myfile.ps myfile.pdf + +Note that PostScript files containing PostScript commands that are direct +orders to set the paper size ("a4", "letter", etc.) will countermand any +ps2pdf options to the contrary. + +The Ghostscript -dFIXEDMEDIA option can be used to "lock" the paper size +selection and prevent any PostScript paper size operators in the .ps file +from overriding the ps2pdf options. For example, + +ps2pdf -sPAPERSIZE=a4 -dFIXEDMEDIA myfile.ps myfile.pdf + +*will* force an A4 paper size for myfile.pdf even if myfile.ps contains +hardcoded paper size commands for a different paper type (like from using +the dvips "-t letter" option as opposed to the "-t letterSize" option. See +the dvips configuration section for more details). + +It is not recommended that -dFIXEDMEDIA be used in the ps2pdf script itself +as this will prevent the user from being able to alter the paper size with +ps2pdf command line options. Furthermore, it is unusual to override a +PostScript file in this fashion - such as to force a file to print on a +paper type it was not designed for. + +Additional information can be found in the Ghostscript ps2pdf documentation +at: + +http://www.cs.wisc.edu/~ghost/doc/index.htm + +For example, usage information, including a very informative section on +paper size control, for version 7.04 can be found at: + +http://www.cs.wisc.edu/~ghost/doc/AFPL/7.04/Use.htm + +There is also a section in the above link concerning how to modify +Ghostscript's gs_init.ps file +(e.g., /usr/share/ghostscript/7.04/lib/gs_init.ps) +so that Ghostscript's default paper size (that is, what it defaults to +without any options) can be changed to something different from US letter. +This may be of use to those A4 users who use GhostScript to convert +PostScript to many different formats rather than just PDF. + +Info related specifically to p2pdf conversion can be found at: + +http://www.cs.wisc.edu/~ghost/doc/AFPL/7.04/Ps2pdf.htm + +as well as in the Adobe Distiller parameter manual: + +http://partners.adobe.com/asn/developer/acrosdk/DOCS/distparm.pdf + + +Note that a new Ghostscript upgrade or installation will likely overwrite +any changes to the ps2pdf scripts. For this reason, it might be a good idea +to create ps2pdf scripts with different file names - like "ps2pdfmy", +and/or save copies of them in a directory outside the one in which they are +currently located. + +Users of graphical interfaces to Ghostscript (such as gsview) should set +the options/preferences for PDF output in accordance with the +recommendations above. + +For gsview, these are located in the File->Convert->Properties menu. +"-dFIXEDMEDIA" corresponds to gsview's "Fixed Page Size" option. + + + +*** pdfTeX *** + +The traditional way to produce PDF under LaTeX, is to use dvips followed +by ps2pdf. However, some users use pdflatex. + +[Note: pdflatex is just pdftex called with a different name - the pdftex + application actually does double duty.] + + - version information - + +NOT ACCEPTABLE: pdfTeX VERSIONS PRIOR TO 2001/08/06 (versions before 1.00) + +pdfTeX's version information can be obtained via: + +pdftex --version + +The version code of interest is the group of numbers and letters after "pi" +in the first line displayed. i.e., + +"pdfTeX (Web2C 7.3) 3.14159-0.13c" + +indicates version 0.13c. There may also be an obvious date code within in +the version information - especially on the beta releases. + + +In 2001, several problems with pdfTeX's font subsetting code where +discovered that caused pdfTeX not to work properly with some fonts as well +as with Acrobat Reader 5.0. Older versions are potentially even more +problematic and can yield PDF that will not correctly render minus signs +and some Greek symbols under Acrobat Reader. + +These issues were fixed with the 2001/08/06 (1.00a pretest) and later +releases of pdfTeX. See the "Upgrading LaTeX Applications" section below +for information on how to update pdfTeX. + + + - default paper size configuration - +pdfTeX and pdfLaTeX's default paper size is determined by the configuration +file <texmf>/pdftex/config/pdftex.cfg. Within it, lines like: + +page_width 8.5in +page_height 11in + +determine the default paper size. + + - type 1 font configuration - +pdfTeX's pdftex.cfg configuration file is much like dvips' as fonts are +concerned. It is important that the following lines be present and +uncommented: + +map +bsr.map % CM/AMS fonts +map +bsr-interpolated.map % additional sizes +map +hoekwater.map % additional fonts from Taco Hoekwater + +so that the BlueSky Type 1 Computer Modern fonts will be used. + +Note: The pdftex.cfg file on some systems (MiKTeX) may not have these lines, +but instead uses a "map psfonts.map" line which basically does the same thing +as the three above.) + +pdfTeX can also be configured to embed the base 14 fonts (Nimbus) by +replacing the line (usually the first of the map lines to appear in +pdftex.cfg): + +map acrobat-std-adobe-buildin.map + +with: + +map acrobat-std-urw-kb.map + +This basically tells pdfTeX to use and embed the Nimbus fonts instead of +relying on the (substituted) fonts that are built into Acrobat Reader. + +Note: Some acrobat-std-urw-kb.map files (this will be located in +<texmf>/dvips/config) have a mistake in two lines: + +usyr StandardSymL <psyr.pfb +. +. +uzdr Dingbats <pzdr.pfb + +These should instead read: + +psyr StandardSymL <psyr.pfb +. +. +pzdr Dingbats <pzdr.pfb + + +For systems that do not have a acrobat-std-urw-kb.map file (MiKTeX puts +everything in psfonts.map), the teTeX acrobat-std-urw-kb.map typically +contains: + +pcrb8r NimbusMonL-Regu-Bold "TeXBase1Encoding ReEncodeFont" <8r.enc <ucrb8a.pfb +pcrbo8r NimbusMonL-Regu-BoldOblique "TeXBase1Encoding ReEncodeFont" <8r.enc <ucrbo8a.pfb +pcrr8r NimbusMonL-Regu "TeXBase1Encoding ReEncodeFont" <8r.enc <ucrr8a.pfb +pcrro8r NimbusMonL-Regu-Oblique "TeXBase1Encoding ReEncodeFont" <8r.enc <ucrro8a.pfb +phvb8r NimbusSanL-Regu-Bold "TeXBase1Encoding ReEncodeFont" <8r.enc <uhvb8a.pfb +phvbo8r NimbusSanL-Regu-BoldOblique "TeXBase1Encoding ReEncodeFont" <8r.enc <uhvbo8a.pfb +phvr8r NimbusSanL-Regu "TeXBase1Encoding ReEncodeFont" <8r.enc <uhvr8a.pfb +phvro8r NimbusSanL-Regu-Oblique "TeXBase1Encoding ReEncodeFont" <8r.enc <uhvro8a.pfb +psyr StandardSymL <psyr.pfb +ptmb8r NimbusRomNo9L-Medi "TeXBase1Encoding ReEncodeFont" <8r.enc <utmb8a.pfb +ptmbi8r NimbusRomNo9L-MediItal "TeXBase1Encoding ReEncodeFont" <8r.enc <utmbi8a.pfb +ptmr8r NimbusRomNo9L-Regu "TeXBase1Encoding ReEncodeFont" <8r.enc <utmr8a.pfb +ptmri8r NimbusRomNo9L-ReguItal "TeXBase1Encoding ReEncodeFont" <8r.enc <utmri8a.pfb +pzdr Dingbats <pzdr.pfb + +it is possible to modify the pcrb8r, pcrbo8r, etc., lines in MiKTeX's +psfonts.map to be like the ones above so that pdftex will embed the +Nimbus fonts. + + +Note that pdfTeX will name these embedded fonts like "NimbusRomNo9L-Regu", +while Ghostscript created PDF will use the more traditional name +"Times Roman". + +Some pdfTeX installations also have an issue/mistake in the map files +related to the Lucida font. See the section below on upgrading pdfTeX for +more information. + + + +*** xdvi *** + +xdvi's default paper size is determined by its configuration file: + +<texmf>/xdvi/XDvi + +Within this file, the default paper size can be set with a line like: + +XDvi*paper:us + +for US letter or + +XDvi*paper:a4 + +for A4 paper. + +As stated in more detail in the Ghostscript section, versions of xdvi prior +to 22.40j (For the xdvi-k Kpathsea enabled version, which is by far the most +popular, for the non-k version of xdvi the release number to have is 22.57 +or later. Also xdvi installations from RPM packages seem to have confusing +version numbering systems all their own.) can cause Ghostscript versions +7.04 and later to issue an error: + +gs: Error: /invalidfileaccess in --file-- + +for graphic files that are referenced via relative paths. e.g.,: + +\includegraphics{../myfigs/afig.eps} + +Versions of Ghostscript after 7.04 have even more security enhancements and +even the absolute path PostScript figures of a dvi file may not show up +under the older versions of xdvi. + +Note: The lucida.map file for xdvi in <texmf>/xdvi may have an issue that +could cause trouble for some versions of xdvi. See the section below on +upgrading pdfTeX for more information about this. + + +There are two major support sites for xdvi where the very latest versions +can be downloaded. For the Kpathsea enabled version (which is by far the +most popular in use) see Stefan Ulrich's xdvi-k site on Sourceforge: +http://xdvi.sourceforge.net/ +For the non-k version, see Paul Vojta's site: +http://math.berkeley.edu/~vojta/xdvi.html + + + + +*** YAP *** + +The paper size can be selected in the menu: + +View ->Options->Display + + + + + *** UPGRADING LaTeX APPLICATIONS *** + +Upgrading LaTeX applications and utilities is not always a trivial matter. + +With the possible exception of xdvi (see the xdvi section above), most LateX +applications are distributed as an integral part of their respective LaTeX +distributions and are not generally available from their "own homepages". + +Users with commercial versions of LaTeX should consult the vendor for +upgrade availability. + +MiKTeX users can obtain upgrades at the MiKteX site: +http://www.miktex.org/ +as well as the MiKTeX subdirectories (some of which may pertain to recent +beta releases) of the WIN32 system directories CTAN: +http://www.ctan.org/tex-archive/systems/win32/ + +fpTeX users can obtain updates from several places: +http://www.fptex.org/ +http://www.ctan.org/tex-archive/systems/win32/fptex/ +ftp://ftp.dante.de/pub/fptex/ +The dante site usually carries the most recent versions of fptex. + + +teTeX (UNIX) users might be able obtain some executables from the texlive +distribution: http://www.tug.org/texlive/tlprod/Master/bin/ +(which also carries fptex executables for Windows systems) +Some .pool files (explained below) for these executables can be obtained +at: http://www.tug.org/texlive/tlprod/Master/texmf/web2c/ + +Linux users with RPM-based systems (Red Hat, etc.) will find a large number +of teTeX RPMS at: + +http://www.rpmfind.net/linux/rpm2html/search.php?query=tetex&submit=Search + +there are also a tetex-xdvi rpms: + +http://www.rpmfind.net/linux/rpm2html/search.php?query=tetex-xdvi&submit=Search + +and tetex-dvips rpms: + +http://www.rpmfind.net/linux/rpm2html/search.php?query=tetex-dvips&submit=Search + +among others. These lists might have to be examined carefully to determine +which is the most recent and most applicable to a given existing +installation. Red Hat users should note that Red Hat's "RawHide" rpm +releases are usually more recent than the standard versions from Red Hat. + + + +*** Manually Upgrading Individual Applications *** + +Because the full LaTeX distributions can be very large downloads and their +installation may overwrite existing configuration files, and because +sometimes a user wants to update "just one little thing", it often happens +that a user wants to manually update an individual application. + +The information below gives some tips on how to do this from the teTeX +perspective. However, some of the information below may be useful for other +LaTeX systems - especially the information related to post-upgrade +configuration changes. It should be mentioned that it is not possible to +cover every detail here and any user wanting to undertake this approach +should have a basic knowledge of system administration on their respective +OS platform as well as a basic understanding of the location of the files +(executables, configuration, etc.) for the application that is to be +upgraded. + + + + - Manually Upgrading teTeX (UNIX) Applications From Source - + +teTeX users can update applications by compiling from source. The appeal of +this approach is that it provides a way to obtain extremely recent releases +and allows a great deal of manual control. Users familiar with open source +software will feel much at home with this approach. + +The most recent official teTeX source releases are located at: + +ftp://dante.ctan.org/pub/tex/systems/unix/teTeX/current/distrib/sources/ + +The files of interest will be of the form "teTeX-src..." as these contain +the source code for the executables. The other files of the form +"teTeX-texmf..." and "teTeX-texmfsrc..." contain the various LaTeX font, +sty, metafont source, etc. files and should not be needed just to upgrade +applications. + +The beta versions can lead the official releases by a year or more. Users +should therefore give serious consideration to using a recent beta version +because they often fix known bugs in the previous official releases. + +The beta release can be found at: + +ftp://dante.ctan.org/pub/tex/systems/unix/teTeX-beta/ + +and the files of interest are of the form "teTeX-src-beta...tar.gz" and are +about 10MB in size. + + +- Tips for Compiling/Installing Applications from teTeX Source File - +[beta version illustrated here] + +unpack the tar file (tar xvfz teTeX-src-beta...tar.gz) in a temporary work +directory. Let <tetexsrc> designate the top level directory of the unpacked +source tree. It is recommended that all the unpacking, configuration and +compiling steps NOT be done by the root user. Start by changing to the top +directory of the source tree: + +cd <tetexsrc> + +the file "INSTALL" contains valuable installation instructions. However, it +will be assumed here that the user wants to build the applications and then +copy them out manually - so a more manual approach than that described in +INSTALL is used here. The INSTALL file also has an appendix with a note on +moving binaries (executables) around - read that information too. +Now, + +./configure --datadir=/usr/share + +where datadir is the directory in which the existing <texmf> directory is +(or would be) located (that is the *parent* of <texmf>). +Then: + +make + +to compile the source code. Any compile problems are usually the result of +not having a recent enough version of gcc or make. + + +== DANGEROUS BEND == +Do NOT run "make install", unless one intends to update every application, +as this will start an install script that copies _all_ the installable +files to whatever "-prefix=", et. al. was set to during configuration +(prefix defaults to /usr/local/teTeX). Note that all UNIX systems do not +use the same teTeX directory structures! For instance, Red Hat Linux 6.0 +uses /usr/share/texmf for the <texmf> directory and puts the executables +directly into /usr/bin, while many other UNIX systems use +/usr/local/teTeX/texmf as <texmf> and puts the executables in +/usr/local/teTeX/bin. The latter schema makes upgrades much easier (because +the teTeX files are consolidated in one place), but requires a more +complicated $PATH, $MANPATH, etc. Altering the teTeX layout of an existing +system will likely mean that other upgrade packages that are designed for +that system (rpm, etc.) will no longer work. + +Any user contemplating a "make install" is strongly advised to carefully +read INSTALL, ./configure --help and set all the needed ./configure +options. If something should go wrong with a "wholesale" upgrade, such as +overwritten customized configuration files, recovery could be difficult. +Always make backups. You have been warned. +==================== + + +After the compilation is complete, the user may rummage through the source +code and pick out just the executables of interest. To copy the files to +the needed system directories, the user will need to be root. + +Let <texexec>, <texman1>, <texinfo> designate the directories where the +teTeX executables, man1 pages, and info pages, respectively are kept on +the existing system. + +For Red Hat these are: + +<texexec> = /usr/bin +<texman> = /usr/man/man1 +<texinfo> = /usr/info + +while for many other UNIX systems they are like: + +<texexec> = /usr/local/teTeX/bin +<texman> = /usr/local/teTeX/man +<texinfo> = /usr/local/teTeX/info + +The "which" command can be used to to find out where the existing +executables are. It is recommended that the new ones go in the same +directories as the old ones otherwise some applications may not be able to +properly find their configuration files (long story). The user may wish to +retain copies of the old executables, perhaps putting version numbers in +their names, so that they can be used again if something goes wrong. e.g., + +mv <texexec>/dvips <texexec>/dvips585 + +The user may want to update the UNIX documentation as well. Man pages for +user executables end in ".1" (e.g., dvips.1) Info pages for the executables +end in ".info". There may be more than one info page, the additional pages +will be indicated by appended numbers. (e.g., "dvips.info-1") Info and man +pages are sometimes compressed and have a ".gz" suffix. Compressed and +non-compressed sets are interchangeable. + + + +dvips: +The new dvips binary, man and info pages will be in: <tetexsrc>/texk/dvipsk + +The new dvips .pro files will likely be identical to the originals +(in <texmf>/dvips/base), unless they are very old (pre 5.86). The only +"gotcha" here is that sometimes the originals have been modified. If this +is suspected, it might be good to keep the original .pro files. One very +common modification is to have tex.pro and texc.pro rotate landscape the +"other way" to prevent landscape pages from appearing upside down. This is +accomplished by changing the default /landplus90{false} to +/landplus90{true} in both tex.pro and texc.pro (usually located in the +third line). It is recommended by this author that these be set to "true" +as this produces a "right side up" page under standard Ghostscript on UNIX. +The ".lpro" source code files are used to make the .pro files during teTeX +source compilation. So these should be changed as well if these changes are +to appear in the .pro files of the <tetexsrc> if "make" is ever run again. +There is information about this topic at: +http://www.radicaleye.com/dvips.html + +It is probably a good idea to retain the other (.map, etc.) original dvips +configuration files. + + + +xdvi: (Kpathsea version) +The xdvi executable is a bit unusual in that it is started by a shell +script "xdvi" which in turn calls the "real" xdvi binary executable +"xdvi.bin". The new xdvi executables are located in +<tetexsrc>/texk/xdvik. + +Upgrading from the source tree is usually as easy as + +cp <tetexsrc>/texk/xdvik/xdvi.bin <texexec>/xdvi.bin + +The original <texexec>/xdvi start script can usually be retained. +To change it as well: + +cp <tetexsrc>/texk/xdvik/xdvi-sh <texexec>/xdvi + +The new xdvi man page is located in the same directory as the new +executable. xdvi does not seem to have an info page. + +The new configuration and map files are in <tetexsrc>/texk/xdvik/texmf +and probably should be copied over to <texmf>/xdvi after saving +the originals: + +cp <tetexsrc>/texk/xdvik/texmf/* <texmf>/xdvi + +The old XDvi config file should the reviewed and its customized settings +should be carried over into the new one (or the original retained as-is). + +The xdvi documentation and support sites have very helpful information on +how to configure the XDvi config file as well as the user's ~/.Xdefaults. +By adjusting these files, the user can control the size, shape, fonts, and +even the types of GUI buttons as well as the default (and button) zoom +levels. For my own personal tastes, + +XDvi*pixelsPerInch: 600 +XDvi*shrinkFactor: 8 + +works nicely in the XDvi file, coupled with button shrink factors of 1, 2, +4, and 8 in my ~/.Xdefaults file. See the xdvi installation docs for details. + +Newer versions of xdvi also have a xdvi.cfg file that may not be present in +older xdvi setups. Some distributions of xdvi use a ps2pk.map file (which is +now the preferable one to use if given a choice), others use several other +map files (one of which is xdvifont.map). xdvi.cfg should have lines which +load the needed map files so that direct type 1 font rendering is possible: + +dvipsmap ps2pk.map + +It is a good idea for the <texmf>/web2c/texmf.cfg to have an XDVIINPUTS +line which lets xdvi search its own directory as well as that of dvips for +map files: + +XDVIINPUTS = .;$TEXMF/{xdvi,dvips//} + + +Note: The lucida.map file for xdvi in <texmf>/xdvi may have an issue that +could cause trouble for some versions of xdvi. See the section below on +upgrading pdfTeX for more information about this. + + + +pdfTeX (TeX, eTeX, Omega similar): + +[Note: "pdflatex" is usually just a symbolic link to "pdftex" - + pdflatex will be thus be updated if pdftex is.] + +The new pdftex executable is located in <tetexsc>/texk/web2c +Its new man pages are in <tetexsc>/texk/web2c/man. pdftex does not seem to +have an info page. (but, LaTeX does - it is in <tetexsc>/texk/tetex). + +The pdftex.pool file must also be updated: + +cp <tetexsc>/texk/web2c/pdftex.pool <texmf>/web2c/pdftex.pool + +Now, applications like TeX, pdfTeX, LaTeX, do not read and process their +ASCII initialization language definition files when they are run. Instead +these language definitions are read once, and their memory images are saved +for later use as format (.fmt) files. This technique reduces the required +start-up time because extensive parsing is not needed. However, if the +application executable changes, the format file for it will likely no +longer be correct. + +If the correct format file is incorrect or missing, pdftex will error with: + + "(Fatal format file error; I'm stymied)" + or + "I can't find the format file `pdflatex.fmt'!" + +These format files are not included in the teTeX source files as they +depend on the plain TeX, latex.ltx, etc. files on the user's system. + +Making and installing complete new set can be as easy as calling +fmtutil (as root): + + fmtutil --all + +A fmtutil utility is included in the teTeX source, see the +<tetexsc>/texk/tetex directory. + +(Note: fpTeX also has the fmtutil command. MiKTeX users use "initexmf --dump" +(usually located in <texmf>/miktex/bin/) to rebuild all the format files.) + +However, users wanting a more manual approach can have pdftex make its own +format files. Two will be needed: pdftex.fmt and pdflatex.fmt + +To make pdftex.fmt, change to a work directory and issue: + + pdftex --ini plain + +at the "*" prompt enter: + + \dump + +This will make a pdftex.fmt. + +To make pdflatex.fmt, do: + + pdftex -ini -fmt=pdflatex latex.ltx + +Don't worry if you get a warning about old LaTeX source files - they aren't +any older than what you have been using. ;) + +(Note: recent fpTeX systems use a slightly different form of command for +this: "pdftex -ini -job-name=pdflatex latex.ltx". teTeX systems may one day +do it this way as well.) + + +Then, copy both these .fmt files to <texmf>/web2c + +See the pdftex support page for the pdfTeX user manual FAQ: + +http://www.tug.org/applications/pdftex/ + +for more info. + + +If the new (or old one for that matter!) pdftex gives errors like: + +"Warning: pdflatex (file <texmf>/dvips/config/lucidabr.map): invalid entry + for `hlcbot8rn': too big value of ExtendFont (850)" + +it has detected a mistake that appeared in thousands of teTeX systems. +Earlier versions of pdftex would not indicate a problem unless the affected +fonts were actually used. More recent versions of pdftex will always report +the error every time pdftex is executed. So, the problem may suddenly +appear after a pdftex upgrade. + +In <texmf>/dvips/config, there are two files: lucidabr.map and psfonts.map. +(on teTeX systems, pdftex "eavesdrops" on many of dvips' font map files.) + +In each of these ASCII files there are about eight lines, all related to +the Lucida font family, that look somewhat like: + +hlcbot8rn LucidaTypewriterBoldOblique "850 ExtendFont .... + +The "850"'s are incorrect. They should be ".850" like: + +hlcbot8rn LucidaTypewriterBoldOblique ".850 ExtendFont .... + +Changing all the instances to ".850" will fix the problem. + +The lucida.map file for xdvi in <texmf>/xdvi may have these same issues. + +Note: The original intent was that if an application saw a value greater +than 1, it would automatically divide by 100. However, not all versions +of all applications that access these map files actually do this as they +are supposed to. + +Finally, one might have to upgrade some LaTeX packages that use pdfTeX +drivers/interfaces after pdfTeX is updated. In particular, the +graphics/x package can stop working correctly after a pdfLaTeX upgrade +- giving error messages such as: + +"! Undefined control sequence. + <argument> ...setbox \@tempboxa =\hbox {\pdfimage .." + +The solution is to update the <texmf>/tex/latex/graphics/pdftex.def file. +This file comes with the graphics/x package which can be obtained at (it +is a good idea to go ahead and upgrade the entire package): +http://www.ctan.org/tex-archive/macros/latex/required/graphics/ +Cutting edge releases of pdftex.def can be obtained at: +http://www.tug.org/applications/pdftex/pdftex.def + + + + *** TESTFLOW CONTROL PS/PDF FILE BUILD CODE INFORMATION *** + +A "build code" can be seen when the testflow control PS/PDF files are +viewed. Below is a list of these build codes and information about what +applications and configurations were used to create each of them: + +(Build code 0000 designates a non-control (user made) PS/PDF file.) + + +****** Version 1.0 Build code 0003 ****** +Creation Date: Apr. 17, 2002 +Operating system: Red Hat Linux 6.0 +Test picture fonts: yes +LaTeX2e version: TeX (Web2C 7.3) 3.14159 +dvips version: 5.86g +Ghostscript version: 7.04 + +Computer Modern font: BlueSky, type 1, June 6, 2001 revision +Base PostScript font: Nimbus (in the PDF only) from GhostScript + +work flow: latex->dvips->Ghostscript (ps2pdf) + +notable dvips parameters: D7200, alt-rule.pro + +Ghostscript ps2pdf parameters: -dPDFSETTINGS=/printer +-dCompatibilityLevel=1.3 -dMaxSubsetPct=100 -dSubsetFonts=true +-dEmbedAllFonts=true + +- additional testflow_ctl_A4 parameters - + +ps (dvips): @ a4size 594.99bp 841.99bp + @+ %%PaperSize: A4 + +pdf (ps2pdf): -sPAPERSIZE=a4 + + +- additional testflow_ctl_LTR parameters - + +ps (dvips): @ lettersize 8.5in 11in + @+ %%PaperSize: Letter + +pdf (ps2pdf): -sPAPERSIZE=letter + +****************************************** + +=========================================================================== + + That's all folks ;) + + mds + |