Preview "save as" creates bigger file than input. Why?

I have a PDF of a 12 page document, about 600 KB file size. I open it in Preview, and "save as" another file. The new PDF is about 7 MB file size, more than 10 times the original file size.


Additional info:


1. If I just wanted another copy of the PDF I could copy the file. I know that. But I used Preview with "Create Booklet" and the booklet file was about 7 MB. I used "save as" to show that "Create Booklet" has nothing to do with increasing the file size.


2. The PDF was created in Scribus. Scribus outlines fonts it thinks it's not allowed to embed, and the text in the PDF is almost all in outlined fonts.


3. The font produced from Scribus is about 1.5 KB file size. Processing it with Ghostscript, using "gs -sDEVICE=pdfwrite ..." reduced the file size to about 600 KB.


4. I have another DTP application that embeds the same fonts. The PDF output is a little over 1 MB, Ghostscript shrinks it to well under 1 MB, and it does not become larger when saved from Preview.


Bottom line: After Scribus output and processing with Ghostscript, the PDF has outlined fonts in well under 1 MB file size. Open it in Preview and save it, and the file becomes ten times larger. Why?

Posted on Apr 22, 2012 5:17 PM

Reply
28 replies

Apr 25, 2012 6:14 PM in response to etresoft

Simple document with one sentence in Lucida Bright Regular:


In Pages, save as PDF via the print dialog. Preview can save it as another PDF and open the other PDF, and the text is selectable. Adobe Reader says both files have an embedded subset of Lucida Bright Regular in TrueType format.


In Scribus, export to PDF, asking for all fonts to be embedded, but it says it will outline Lucida Bright Regular, not embed it. Adobe Reader says it has a Type 3 font named Fo050. Preview can save it as another PDF and open the other PDF, but the text is not selectable. Adobe Reader does not list any fonts in this file.


Conclusion: Preview can't handle the Type 3 fonts that Scribus creates from TrueType fonts. It isn't a matter of Adobe not adhering to its own standard; if there's any nonstandard behavior, it's in Scribus.

Apr 26, 2012 7:38 AM in response to etresoft

It is Scribus that is converting the fonts into pure outlines, perhaps to stay legal. Then it is Preview that scrambles that.

You may still be correct on that point. We've only seen the finished PDF, not the original fonts used. Some of them may have copyright protections that Scribus deals with by converting them to embedded Type 3 PS.


Still, while Type 3 PS is obsolete, OS X does support them. So I couldn't guess why Preview isn't just carrying those fonts over into a new document as Adobe's software does instead of converting them to art.

May 1, 2012 6:52 PM in response to Kurt Lang

The original font families used for the text are Lucida Bright and Lucida Sans, with others less used. The fonts Scribus would not embed are TrueType fonts that came either with the OS or bundled with applications. When I replaced them with free downloaded fonts, such as Lucida Becker Bright and Lucida Becker Sans for the Lucida families, URWClassicoT for Optima, etc., Scribus embedded all the fonts and the problems disappeared.


About staying legal: etresoft asked me on April 25 whether I had considered using Apple Pages. I replied that Pages wants to be a word processor, not a desktop publisher. I just found out that I missed the fact that Pages has two modes, depending on the template you start with. If you start with a "layout template," Pages is a desktop publisher, not with all the features I want, but with all the features I need.


The interesting part of that is that if Scribus "outlines" (embeds as Type 3) certain fonts to stay legal, then Pages does not stay legal. I started to recreate the newsletter in Pages, using the original Lucida and Optima fonts, and according to Adobe Reader, all the fonts that Scribus converted to Type 3 are embedded as subsetted TrueType in the PDF created by Pages.


That still doesn't explain why Preview reads Type 3 fonts but does not write them out again.

May 3, 2012 6:44 AM in response to marty39

The original font families used for the text are Lucida Bright and Lucida Sans ... When I replaced them with free downloaded fonts, ... the problems disappeared.

May I ask where Lucida Bright and Lucida Sans came from? Are they purchased fonts? I have them a couple of ways myself. Lucida Bright was included with OS 9, and is also installed with MS Office 2008 and 2011. Lucida Sans was available these same three ways, and was also part of the Adobe Font Folio (Type 1 PS).


Could you tell me which version you were using? I'd like to examine my copies to see what may be going on. But if they're distributed in any of the ways mentioned above, the only copyright in them should only be a general copyright notice to protect the name and design. There shouldn't be any restrictions on their use at all.


If any of these are the versions you're using, Scribus may be balking at something as simple as the general copyright information, regardless of the fact the fonts have no use restrictions.

May 3, 2012 5:00 PM in response to Kurt Lang

Scribus has it backwards. It will embed the font if I choose not to allow subsetting.


Anyway, I have TrueType versions. I have Lucida fonts that came with Microsoft Office 97 Pro, but they're copyright 1991, and the versions I have installed are copyright 1998. I don't know where I got the installed versions. No matter, if I remove the 1998 Lucida Bright and substitute the 1991 fonts from Office 97, Scribus still refuses to embed them subsetted -- in spite of the fact that Fontforge says the "Embeddable" option is "Installable Font," and "No Subsetting" and "Only Embed Bitmaps" are not checked.


I don't know what Scribus is balking at. I can't imagine it's reading the copyright text.


In any case, Preview should be able to output something readable from Type 3 font input. I imagine the two problems, unreadable text and expanded file size, are related. When the embedded font is replaced by outlines, the many instances of the same character that referred to the same outline in the font are now represented by one outline for each instance.


BTW that screenshot looks like Fontforge, but it doesn't look like any version I have.

May 4, 2012 6:44 AM in response to marty39

Scribus has it backwards. It will embed the font if I choose not to allow subsetting.

Hmm, that can't be right. Looking at one of your two samples in Acrobat Pro, the five TrueType fonts are marked (Embedded Subset).

I don't know what Scribus is balking at. I can't imagine it's reading the copyright text.

No, I don't either. That was just a very wild guess at what Scribus may be doing. Most fonts have copyright text in them, as do two of the fonts which remained TrueType; Skia Regular and Skia Black.

In any case, Preview should be able to output something readable from Type 3 font input.

Yes. The Acrobat Reader has no trouble moving the Type 3 converted fonts into a new document. There's no reason Preview shouldn't be able to.

When the embedded font is replaced by outlines, the many instances of the same character that referred to the same outline in the font are now represented by one outline for each instance.

Correct. As I mentioned above, "All of the Type 3 PS fonts have been stripped and turned into vector art."

BTW that screenshot looks like Fontforge, but it doesn't look like any version I have.

The screenshot is from FontLab Studio.

May 5, 2012 5:08 AM in response to Kurt Lang

Scribus has it backwards. It will embed the font if I choose not to allow subsetting.

Hmm, that can't be right. Looking at one of your two samples in Acrobat Pro, the five TrueType fonts are marked (Embedded Subset).


The five fonts in apr12.pdf that are marked "Embedded Subset" are fonts that Scribus does not treat as protected. The Lucida and Optima fonts are treated as protected and embedded as Type 3.


Scribus has a font preview tool in which it lists every available font with some information (not including whether the font is considered to be protected) and three options for each: whether to use the font, whether to embed it in PostScript output, and whether to subset it. If I uncheck the "subset" option for the "protected" fonts, Scribus embeds them as TrueType. The PDF file is only a little bit larger, the Lucida fonts are OK but the Optima fonts can't be extracted (maybe because Optima is installed in .ttc format). I didn't make that output file publicly available.


Aside: I said Pages has everything I need. It does not. It doesn't do drop caps. There are workarounds for drop caps but they don't work in justified text in text boxes, due to known unique features (I won't call them bugs) in Pages. I may have to stay with Scribus.

Jan 15, 2013 2:02 PM in response to marty39

I am having a similarly infuriating problem with Preview, but using scanned documents that I don't think have any fonts embedded. Deleting or reordering pages causes massive increases (on the order of 10-20x) in file size, which is causing all kinds of havoc.


(Using quartz filters to reduce the file size again helps somewhat, bringing the file sizes down to maybe 2x the original, but we work with literally hundreds of documents a week and can't waste time doing this to every one for no good reason.)


Using Acrobat Pro doesn't cause the file size increase, but we have people all over the world and not all of them have Acrobat Pro installed. Is Preview really incapable of removing or reordering PDF pages, and we need to spring for Acrobat Pro for everyone??

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Preview "save as" creates bigger file than input. Why?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.