101

I feel that PDF documents when intended to be uploaded on the Internet should be of minimal final size in bytes. Many strategies exist to create such small documents:

  1. Pay attention to the size of the embedded raster images.

  2. Create diagrams with tikz or pstricks and avoid external applications that can create unwanted big files. Using tikz or pstricks provides access to an almost unlimited control of the properties of a specific object. For instance, creating a point A of coordinates (1,1) should be preferred to a point A of coordinates (1.0000000,1.00000000), that you cannot control in many applications.

  3. Pay attention to the fonts used in your documents. Some fonts contain a coding for a single size and are then scaled, when used in titles or equivalents. Some other fonts contain a coding for different size, making the document a bit larger. You may observe a non negligible difference.

I am interested in this 3rd point: have some of you investigated the best fonts for smaller PDF files?

Edit Compress.SmallPDF sounds like a good online solution to efficiently compress pdf files for free.

5
  • 3
    your question seems to be about fonts, so the title should reflect that.
    – Vivi
    Aug 23, 2010 at 4:52
  • 2
    you are right but but maybe we should open it to all the possible tricks. Thanks
    – pluton
    Aug 23, 2010 at 13:27
  • I just go to the compress pdf web site and it does amazing job in compressing my pdf files :)
    – Nasser
    Feb 6, 2015 at 17:01
  • 2
    Compressing pdfs on some random websites is insecure, they might insert some dirty scripts into them. However, SmallPDF seems to be some kind of business so probably they are not doing it. It makes great job and feels legit. May 17, 2016 at 17:41
  • As online service there is also adobe.com/acrobat/online/compress-pdf.html
    – Stephen
    Mar 4, 2021 at 9:50

7 Answers 7

78

There are a number of tricks for getting optimized pdfs. Many of them are implemented in the tool pdfsizeopt. With some patches (posted in the pdfsizeopt bugtracker) this tool can run on all my tex-generated pdfs (and nearly all of the non-tex-generated ones). I use the commandline:

python ./pdfsizeopt.py --use-pngout=true --use-jbig2=true --use-multivalent=true --do-unify-fonts=false filetocompress.pdf

I use --do-unify-fonts=false even though it produces slightly larger pdfs, because of a bug where a few glyphs are not displayed with certain pdf viewers (windows adobe reader, for example).

There are indeed various things you can do during document production with tex, to make sure that the compressed pdf ends up as small as possible: several of these are discussed in the EuroTeX 2009 White paper about pdfsizeopt (available at https://github.com/pts/pdfsizeopt/releases/download/docs-v1/pts_pdfsizeopt2009.psom.pdf).

As regards fonts, pdfsizeopt will recode fonts to the very compressed CFF format, and take care of subsetting and duplication issues. I haven't investigated deeply, but in my tests it seems that of the 2 options for type 1 encoded T1 (multilingual) tex fonts, the Latin Modern fonts generally produce significantly larger PDFs than the CM-Super version (which is unfortunate, because Latin Modern is superior in just about every other way (see this question). I just did a quick experiment and this difference in size seems to be only for the pre-pdfsizeopt pdfs: after pdfsizeopt, Latin Modern is the same or smaller than CM-Super.

Using fonts that don't have optical scaling will indeed produce a smaller PDF, but I don't recommend it because if you are using multiple sizes then the non-optically scaled fonts will look much worse.

9
  • 8
    About Latin Modern: most of the information in latin modern is encoded as subroutines instead of directly into the glyphs. This makes the total font size smaller, but it makes creating an efficient subset of the font a lot harder. As a consequence, most (if not all) Type1 subsetting routines do not have enough code to create a nice small subset for latin modern Type1 fonts. Aug 23, 2010 at 6:52
  • 3
    @Taco: I wrote something like that in my answer to the previous question. I just checked, and it seems that pdfsizeopt is smarter than most (if not all) Type1 subsetting routines!
    – Lev Bishop
    Aug 23, 2010 at 7:31
  • 1
    pdfsizeopt seems to have been taken down.
    – giordano
    Oct 11, 2013 at 21:36
  • 1
    @giordano the python files are now at github.com/pts/pdfsizeopt but Péter is waiting to resolve the DMCA issues before putting the other files back.
    – Lev Bishop
    Oct 12, 2013 at 12:34
  • 2
    @Colas That's a message from multivalent tool.pdf.Compress and you should ignore it. It produces a "compact PDF" file, that is not a true PDF and can't be read by anything other than multivalent tools (unfortunately, since it generally is significantly smaller, due to using bzip2 compression and other sensible but not-standard-conforming techniques).
    – Lev Bishop
    Oct 21, 2013 at 16:29
27

If for some reason you don't want to use pdfsizeopt: both XeTeX and LuaTeX typically generate smaller PDF files than pdfTeX because OpenType fonts are already encoded in either CFF or TrueType outlines.

1
  • Presumably one also has to switch to OpenType/TrueType fonts for using XeTeX or LuaTeX to be of any use on this front?
    – SamB
    Nov 30, 2010 at 1:19
25

There is the program pdfopt provided by Ghostscript which converts the PDF in the official web optimised format. This (quote from man pdfopt) puts the elements of the file into a more linear order and adds "hint" pointers, allowing Adobe's Acrobat(TM) products to display individual pages of the file more quickly when accessing the file through a network (unquote).

The usage is straigt forward:

pdfopt [ options ] input.pdf output.pdf

Just make sure that both PDF filenames are not the same. You might want to move output.pdf to input.pdf afterwards. This is what I do in my Makefile's for my LaTeX package prior to uploading them to CTAN.

5
  • 4
    I just gave it a try. First, I used Martin Heller's parameters then pdfopt with no option. It went from 857ko to 1163ko. It looks like it is not optimizing here of maybe the document gets larger in order to make the display of individual pages possible.
    – pluton
    Mar 4, 2011 at 13:29
  • 4
    @pluton: Yes pdfopt is more for the web optimised format to be able to browse through the PDF without downloading it completely. The size might actually increase because of that. If the PDFs are intended to be simply downloaded as a whole another approach is more useful. Mar 4, 2011 at 13:42
  • 6
    I use qpdf instead of pdfopt. It web optimizes but doesn't increase the file size as much as pdfopt. According to Martin Schröder in the comment of tex.stackexchange.com/questions/19263/… it is so that "pdfopt runs a PDF through ghostscript: It's rendered into PDF. qpdf on the other hand knows about PDF and just fixes the file".
    – N.N.
    Aug 11, 2011 at 17:17
  • That line of code I need to put it on the CMD window of my Windows machine?
    – manooooh
    May 12, 2019 at 18:32
  • Yes, the CMD window in the document directory. May 12, 2019 at 18:35
22

(Not specifically font related)

A way to create smaller documents with pdf(La)TeX is to use

\pdfminorversion=5
\pdfobjcompresslevel=3 
\pdfcompresslevel=9

This will generally produce considerably smaller files but it requires pdf version 1.5 and might not be readable by old pdf-viewers.

3
  • 10
    This is going to be the default in TeX Live 2010 (and is for those of us with thre pretest)
    – Joseph Wright
    Aug 23, 2010 at 21:11
  • 1
    I've tried this and found no difference in the output (using MacTeX 2009). The \pdfminorversion setting just seems to change the version number arbitrarily (I can set it to any value it seems). Are there more requirements to making these commands actually have an effect? e.g. a specific version of pdf(la)tex? Aug 24, 2010 at 3:04
  • 2
    \pdfminorversion=X will generate a pdf in version 1.X. Some packages will set \pdfminorversion or \pdfcompresslevel (hyperref, flashmovie). Try use the commands in a minimal document. They are not changing things in arbitrary ways. Aug 24, 2010 at 20:52
16

Using true type fonts that are specified in the PDF standard (and thus available with every conforming pdf viewer) dramatically reduces for me the file size of PDFs generated with pdflatex. Else, other fonts are included in the generated PDF which increases the file size.

For example via

\usepackage{mathptmx}
\usepackage[scaled=.95]{helvet}
\usepackage{courier}

The scaling of helvet is needed, because it is by default a bit larger.

Note that the package times is obsolete.

Using common PostScript fonts with LaTeX describes these packages and more.

Edit To get a list of fonts the PDF standard 1.4 specifies see section 2.2.3 (page 36) and section 5.5.1 (page 339). To quote:

These fonts, or their font metrics and suitable substitution fonts, are guaranteed
to be available to the viewer application.

Section 9.6.2.2 of the PDF standard 1.7 uses a slightly other wording:

[..]These fonts, or their font metrics and suitable substitution fonts, shall be available
 to the conforming reader.

Thus for example, the acrobat reader on an (relatively) obscure Solaris system comes with some otf/pfb font files.

6
  • 3
    Whether or not these fonts actually get embedded depends on the configuration of your tex setup. In texlive, the settings dvipsDownloadBase35 and pdftexDownloadBase14 control this for the dvips and pdftex compilation routes, respectively.
    – Lev Bishop
    Aug 23, 2010 at 7:55
  • 2
    And always embedding these "standard" fonts might be a good idea, as they are not available e.g. in Adobe Reader. Aug 23, 2010 at 8:36
  • 6
    Besides the Reader issue: if the fonts are not embedded than you have to pray that the font named 'Times-Roman' on the client side is indeed identical to the one you used for creating the PDF. I have had a few problems in the past where this was not the case. For safely, always embed subsets of all fonts. Aug 23, 2010 at 10:41
  • 4
    responding to the answer Edit: be warned that 'a suitable substitution' according to Adobe may not be at all what you had in mind when creating the document. I just tried a document with non-embedded fonts, and got Adobe Sans MM and Adobe Serif MM as the used fonts. Aug 23, 2010 at 13:32
  • 2
    you note the difference between "are guaranteed to be available" (pdf standard 1.4) and "shall be available" (pdf standard 1.7). the words are different, but "shall be available" is standard-ese for the guarantee (remember that the pdf standard has been through the iso standardisation process, and that's one of the things that happens in that operation. Feb 24, 2012 at 12:00
10

Give this a try:

#!/bin/bash
file=$1
filebase=$(basename $file .pdf)
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dQUIET -dBATCH -sOutputFile=${filebase}_verkleinert.pdf ${filebase}.pdf

Save it as a shell script and call it with

sh <shellscriptname>.sh <nameofyourpdffile>
2
  • 8
    Since you're using bash you don't need basename. You can just do this instead: ${file%.pdf}. q.v. tldp.org/LDP/abs/html/string-manipulation.html
    – kahen
    Feb 24, 2012 at 12:32
  • 3
    Running a bash script (as declared in the shebang) with sh is strange, although it works in this case as the original script does not use any non-sh features.
    – mvkorpel
    Sep 19, 2014 at 9:14
1

I just open the PDF with Okular (any viewer should work) and then print to a PDF file. It looks exactly the same as the original, although it loses the hyperlinks. However, the savings is measureable. A 1.3 MB file drops to 80K ! There are no unused fonts or anything like that and the fonts aren't that big to begin with, so I don't know why the savings is no significant, but this should be the default output (with links - a link can't add but a few bytes).

2
  • 2
    Not quite. The `pgfmanual.pdf' file (9.8MB) was transformed into a 19.5MB monster with your method.
    – NVaughan
    Sep 2, 2014 at 16:49
  • 1
    I don't use pdfopt because it looks like too much trouble to bother with the install for my purposes when running the file through GS (script above or below) seems to get all the needless cruft out for the files I use (resume should be 80K, not 1.3MB!) For your test file, I get 12MB with Okular and 19+MB with the gnome viewer. The script below specifically avoids making it larger (it won't compress that way). Have you found a solution that makes that file significantly smaller? My resume is 6% of original size! Sep 2, 2014 at 17:56

You must log in to answer this question.

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