Martin Heller has stated the correct answer: dvipdfm
uses a different font format than pdftex
. You can look into the PDF file by loading it into a text editor. Sometimes (well, often), the objects are compressed and you only see some data. So you either need a decompression algorithm built into your head, or use a tool like qpdf to uncompress the objects (that is what I do):
qpdf --qdf --object-streams=disable test-pdflatex.pdf test-pdflatex-long.pdf
Now the output file is much more readable and you can now compare the output of dvipdfm
and pdftex
. I don't know if this applies to all cases, but in this example you can take a look at the font object:
% dvipdfm:
9 0 obj
<<
/FontFile3 11 0 R
/Ascent 694
/CapHeight 683
/Descent -194
/Flags 6
/FontBBox [-40 -250 1009 750 ]
/FontName /DJLCQW+CMR10
/ItalicAngle 0
/StemV 69
/Type /FontDescriptor
>>
endobj
and
% pfdtex
9 0 obj
<<
/FontFile 11 0 R
/Ascent 694
/CapHeight 683
/CharSet (/A/C/D/E/I/L/M/N/P/Q/S/U/V/a/b/c/comma/d/e/f/g/h/hyphen/i/j/l/m/n/o/one/p/period/q/r/s/t/u/v/w/y)
/Descent -194
/Flags 4
/FontBBox [ -40 -250 1009 750 ]
/FontName /QJZLYL+CMR10
/ItalicAngle 0
/StemV 69
/Type /FontDescriptor
/XHeight 431
>>
endobj
Both have different entries referring to the font file (/FontFile3
and /FontFile
). According to the table 126 "Embedded font organization for various font types" in the PDF specification, the entry /FontFile
refers to a Type1 font program and /FontFile3
to whatever the subtype in the referred stream is. So we need to take a look at object #11 in the dvipdfm
file:
11 0 obj
<<
/Subtype /Type1C
/Length 12 0 R
>>
stream
....
endstream
endobj
So it is Type1C
, which is according to the same table in the PDF spec: "Type 1–equivalent font program represented in the Compact Font Format (CFF), as described in Adobe Technical Note #5176, The Compact Font Format Specification."
To find out what the secret of CFF is, a look at the introduction of "The Compact Font Format Specification" suffices:
Principal space savings are a result of using a compact binary representation for most of the information, sharing of common data between fonts, and defaulting frequently occurring data.
ghostscript
on the PDF frompdflatex
, I got pretty much the same size as the other one. Still, that doesn't answer the why part of the question.dvipdfm
processes an already processed version of a file (.dvi
), whilepdflatex
processes a file from scratch (.tex
). As such, there could be additional (unused) information contained within when processing it with the latter, while the former could selectively include only "the necessary components."pdffonts <pdf-file>
to see the difference in embedded fonttypes.