375750 - PDFs generated by trunk are huge

Status: RESOLVED FIXED

(Core :: Graphics, defect, P2)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

STR:

1. Grab today's branch and trunk builds
2. http://www.google.com
3. Print -> Save to PDF
4. Compare file sizes

Expected: Roughly identical, small, file sizes

Actual: Trunk weighs in at 224K, Branch at only 56K.

Bug 375749 has the branch PDF; the trunk PDF exceeds Bugzilla attachment size, so the trunk PDF there has been run through Acrobat's "reduce file size" first.

The fact that we're creating such large files might explain bug 362325; we're probably sending a lot more data to printers.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

I thought I recalled stuart talking about how we're saving the entire page as an image embedded in the PDF, rather than text, which would explain the larger size. But maybe I'm thinking of something else.

Comment 2

[Josh Aas]

I would be really nice if somebody could devise a test to find out whether or not large PDF sizes are really responsible for the slow printing, post the test method and results here.

Comment 3

[Stuart Parmenter]

the cairo pdf stuff has nothing to do with the cocoa pdf stuff.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Acrobat's space audit on branch and (original) trunk PDF

Part of the problem here is that we're embedding each font used in the document multiple times; on branch, there are 4 embedded fonts (LucidaGrande, Times-Roman, ArialMS, and Arial-BoldMS), whereas trunk lists 24(!) embedded fonts (multiple copies of the above 4), which is more than 1 font per block of text!

As you can see from Acrobat's Space Audit, fonts are the major part of bloating, but the other categories seem to be anywhere from 2x to 6x larger also.

Comment 5

[Samuel Sidler (old account; do not CC)]

Because PDFs being generated are so huge can we assume that in general, the data we're sending to printers is also huge? If so, this could cause some printers to be unable to print.

Comment 6

[Josh Aas]

It seems unlikely that a fix for this on our end is going to involve cocoa widgets - more likely something in gfx. Switching components.

Also, are we realistically going to block on this? I agree it is a bummer that PDFs are huge, but it seems more like a wanted fix than a blocker.

Comment 7

[Samuel Sidler (old account; do not CC)]

Since this potentially breaks printing for a number of printers (see comment 5), I'm not sure how we couldn't block for this.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

See also bug 378307

Comment 9

[Stuart Parmenter]

I'm not sure what we can do about this bug besides use the cairo PDF surface?

Comment 10

[Ryan VanderMeulen [:RyanVM]]

As I understand things, the issue is outlined in bug 378307 comment #14. The problem is that the text is all being saved in the PDF as images instead of as text, causing the massive bloat seen here (and also seemingly the root of all the "printing is slow on the trunk" bugs floating around out there).

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #10)
> As I understand things, the issue is outlined in bug 378307 comment #14. The
> problem is that the text is all being saved in the PDF as images instead of as
> text,

No, as you can see from the attachment in comment 4, the main problem on Mac OS X is that the fonts are being re-embedded multiple times.  The size of "image" data in the two PDFs is virtually unchanged (actually, it's slightly smaller).

Either that or Acrobat is lying ;)

Comment 12

[Stuart Parmenter]

Attachment: fix

what seems to be happening here is that every time we draw text in cairo we have the same set of 3 or 4 atsfrefs (one for each font we're using) and when drawing to the screen CGFontCreateWithPlatformFont returns the same presumably cached CGFont but when drawing to a PDF (and perhaps a printer -- untested) it creates a different font and ends up embedding the font over and over again.  This caches the CGFontRef with the scaled font which greatly reduces the number of embedded fonts (we should probably cache more aggressively but this should be enough.)

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 286775 [details] [diff] [review]
fix

Looks ok, just get rid of the printf()

Comment 14

[Stuart Parmenter]

Comment on attachment 286775 [details] [diff] [review]
fix

this speeds up printing on the mac pretty significantly -- would be good to get this in for beta

Comment 15

[Mike Schroepfer]

Comment on attachment 286775 [details] [diff] [review]
fix

a+ for schrep - see linked bug for how much this affects mac printing speed - looks like a reasonable fix for b1

Comment 16

[Stuart Parmenter]

checked in.

Comment 17

[Marcia Knous [:marcia]]

Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9a9pre) Gecko/2007110304 Minefield/3.0a9pre, here is what I get when I save the google.com page as a PDF:
Safari->68 KB
Latest Branch->60 KB.
Trunk->104 KB

So while it is not 224 KB as in the original report, the trunk is still larger than both the branch and safari on the mac.