27

I have been writing my formal documents, such as scientific publications, professional CV, cover letter and so on, with TeX. Basically, I write every important document with TeX.

Whistle-blower

Recently during a paper submission, the format checker tells me that my document may appear in an unexpected way because I have not embedded all the fonts to the document itself. I successfully embedded all the fonts in by doing the "reexporting it as another PDF" trick.

Concern raised

Alerted by this incident, I suddenly realise that TeX-rendered documents still cannot guarantee what you see is what everyone else sees, although it does a much better job than Word.

However, like I've said before, all my TeX-rendered files are important files that I must make sure everyone else on any other computer must see the document just as I see it. (e.g., I would never wish to see my CV gets screwed up when opened on the admission committee's don't-know-which-OS-or-how-old computer)

Questions

Besides the "embedding all the fonts" pitfall, what are other pitfalls that make my TeX-rendered documents look different?

How may I avoid them, if any?

Improve this question
11
  • No it does. This is about PDF compatibility. TeX is not responsible for which compatibility level of the end product you are going for unless you really pay attention to it. By the way, journal paper-uploading mechanisms are often stupid (my personal opinion e.g., paper size letter size etc.).
    – percusse
    Apr 5, 2014 at 22:45
  • 1
    I compiled the same latex file on linux and windows. On windows (miktex) I get the pdf file size to be 934,355 bytes and on Linux with texlive 2013, the pdf file is 864,217 bytes. But when looking at the pdf files, I can't see any difference on the screen. So I am sure this has to do with what fonts are used on windows vs. linux or other meta data added to the pdf file on window vs. Linux. Screen shot: !Mathematica graphics again, same exact Latex source. Same images. Everything is the same. Just different platform/distribution. (need to do a pdfdiff...)
    – Nasser
    Apr 5, 2014 at 23:09
  • 4
    Recent versions of TeX Live embed all fonts for Western European languages by default. Older versions and/or installations configured by you or your distro may not do so. You can change this using updmap or (preferably) updmap-sys. A lot depends on how you are generating the PDF. If you use pdfTeX, different versions will default to different versions of the PDF specification (e.g. 1.4 or 1.5 etc.). That can make a difference to the file size. Also, fonts may have been updated and that might change the size. If you are using Xe/LuaTeX, with system fonts these will obviously vary.
    – cfr
    Apr 5, 2014 at 23:31
  • I use MikTeX and recently found an odd situation where I used an \includegraphics on a PDF image that contained some text. When displaying the pdflatex result with MikTeX's native viewer, a font substitution is made on the text in the image, whereas when viewing the same file on Adobe reader, the PDF graphic is rendered correctly.
    – Steven B. Segletes
    Apr 6, 2014 at 1:52
  • 7
    @StevenB.Segletes While pdflatex embeds all the document fonts, it doesn't embed the fonts in included PDF images, which are inserted into the document "as is". You need to ensure that whatever you used to create your PDF images embeds the fonts in the image files (or post-process them with ghostscript or something similar).
    – Nicola Talbot
    Apr 6, 2014 at 10:51

2 Answers 2

Reset to default
10
+50

Fonts:

As already mentioned from you and in the comments: The biggest problems are not embedded fonts!

  • Make sure your font license (if any) allows full embedding
  • Make sure all of your fonts are embedded. You may check this with pdffonts, see: Using and interpreting pdffonts
  • Check your included PDF graphics as well for font embedding!

Colors:

When I view my document once with Evince and once with Adobe Acrobat, my images are colored differently. Someone told me that I need to install correct ICC color profiles. Of course you may circumvent, if you hand out a printed (approved) version, but for online applications, this is defenitely an issue. My advise:

  • Use different PDF viewers: Adobe Reader, Evince, Foxit,.. but also Firefox, Chrome,..
  • Make some test prints: Laser Printer, Ink Printer (This is what probably some personell manager do)
  • Try not to use extreme RGB colors, as they look very different in CMYK. You may switch to cmyk colors (not for the images, but for all TeX generated colors) with \usepackage[cmyk]{xcolor} to see what it would look like.

Validation:

Beside all testing you may consider to validate your PDF if it is standard compliant. I would assume, that pdflatex and friends will only produce standard compliant PDF's but post processing might invalidate them. Free tools for validations are: JOHVE and JOHVE2. They may check the following PDF formats:

  • PDF version 1.0-1.6 [PDF 1.4, PDF 1.5, PDF 1.6]
  • PDF/X-1 (ISO 15930-1:2001) [PDF/X-1], PDF/X-1a (ISO 15930-4:2003) [PDF/X-1a], PDF/X-2 (ISO 15930-5:2003) [PDF/X-2], and PDF/X-3 (ISO 15930-6:2003) [PDF/X-3]
  • Linearized PDF [PDF 1.4]
  • Tagged PDF [PDF 1.4]
  • PDF/A (ISO/DIS 19005-1) [PDF/A]

There is also the pdfx package dedicated to the cre­ation of PDF/X-1a and PFD/A-1b com­pli­ant doc­u­ments

Improve this answer
3
  • You can correct the colors relatively easier in Adobe Suite. Almost always, if you are not going to print it you don't need CMYK. However, you can't embed the fonts that easily, especially in the old documents.
    – percusse
    Apr 9, 2014 at 20:26
  • Actually, I find that Acrobat (Linux acroread 9.4.1) renders colors inconsistently sometimes depending on the content of a particular page. Especially beamer slides. Evince, in constrast, is consistent (with itself, across documents and across pages).
    – alfC
    Apr 9, 2014 at 21:00
  • 1
    @percusse, yes, but you don't know if the addressee will print or not, so I just say: be prepared.
    – math
    Apr 10, 2014 at 7:31
6

This is a PDF compatibility and PDF rendering issue. TeX doesn't know what to do if PDF reader doesn't understand Javascript etc. So your alert is a misattributed one. TeX puts stuff in. Readers render it. If both read the same statement and give you different results, then you need a viewer aware compilation which is pointless.

My personal opinion; embedding all fonts is not a pitfall but a necessity. Often you don't need Times New Roman or Arial sort of common fonts to be embedded because they are ubiquitous. But if you open a Chinese article on a European computer, it looks like the factory that produces Tetris pieces. So if you are worried about font issues, embed them.

Regarding the compatibility or archival purposes, you can convert your document to a PDF/A compatible version and check the result if everything is OK, transparencies and newer other goodies are not working always good. It is meant for archiving. For example;

  • All fonts must be embedded and also must be legally embeddable for unlimited, universal rendering. This also applies to the so-called PostScript standard fonts such as Times or Helvetica.

Rather unfortunately, you need to keep your Acrobat Reader as the test case. Because they define the standards.

Related

hyperref, natbib and PDF/A-compliance

PDF/A with hyperref on TeX Live 2013

Revisiting producing structured PDFs from LaTeX

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .