%\pdfmapline{cmr10 <8r.enc} \font\ff=cmr10 \font\fg=cmr10 at 60pt As Akira described: without the \pdfmapline, there are two different Type3 fonts. I presume that one is constructed from cmr10.600pk and one from cmr10.3600pk. With the \pdfmapline, the PDF output has only one Type3 font. I surmise it is cmr10.600pk geometrically scaled by a factor of 6, hence the extremely visible jaggies. (By the way, you can see the usual bitmap jaggies in all cases if you sufficiently increase the magnification in your PDF viewer, so at least it's clear that bitmaps are correctly being used in all cases.) In other words, something in your patch is causing pdftex to reuse the first (normal) instance of cmr10 for the second (at 60pt) instance, instead of creating a new instance. However, I'm afraid I have no immediate clue about where to find the problem in the code. It was your patch :), so maybe you'll have a better idea of how to debug? I hope so, because it's not a project I can undertake. FWIW, if you add \pdfcompresslevel=0 \pdfobjcompresslevel=0 the output .pdf file will be more or less readable ASCII, which may help in debugging. Or you can use pdfinflt.ps from Ghostscript to do the same thing: gs -q -dNODISPLAY -- pdfinflt.ps infile.pdf outfile.typ Hope something in there helps, Karl P.S. By the way, it has nothing to do with the problem, but 8r.enc should be 7t.enc. That is the actual encoding of cmr10.tfm. You can see the difference if you typeset the "ff" ligature, for instance. Below is my modified test file, which will run with pdftex -ini; more convenient for development than worrying about fmt files. \pdfoutput=1 \catcode`\{=1 \catcode`\}=2 \pdfpkresolution=600 \hsize=4in \vsize=4in \parfillskip=0pt plus1fil \pdfcompresslevel=0 \pdfobjcompresslevel=0 \output={\shipout\box255} \input glyphtounicode \pdfgentounicode=1 \pdfmapline{} % disable all Type1 fonts \pdfmapline{cmr10 <7t.enc} \font\ff=cmr10 \ff fftest \vskip10pt \font\fg=cmr10 at 60pt \fg fgtest \end