View previous topic :: View next topic |
Author |
Message |
yoxi Cipher
Joined: Sep 07, 2004 Posts: 1799 Location: Dawlish, Devon
|
Posted: Tue Dec 28, 2010 2:52 am Post subject: PDF file size redux |
|
I've just been turning a 400-page .odt file (of plain text at 24-point) into a PDF file (using NeoOffice 3.1.2 patch 2 in OSX 10.6.5). The PDF generated by NeoOffice comes out at 2.4Mb, and the Print to PDF one at only 1.3Mb. Any ideas why this size discrepency?
Here's a lorem sample file that does the same thing, in case that's useful. |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Tue Dec 28, 2010 10:11 am Post subject: |
|
I can reproduce the size difference on Mac OS X 10.4.11 as well and I found the cause. It is caused by my fixes for bug 3348 and bug 3442. Both were font kerning bugs and all that extra glyph positioning information is what is increasing the file size.
I am not yet sure if I can safely remove these two bug fixes without reintroducing kerning problems, but I will try removing the fixes and test if the either of the previously fixed bugs reappear.
Patrick |
|
Back to top |
|
|
yoxi Cipher
Joined: Sep 07, 2004 Posts: 1799 Location: Dawlish, Devon
|
Posted: Tue Dec 28, 2010 1:30 pm Post subject: |
|
Good hunting - I was just surprised to see the size difference, I can use whichever is smaller for the moment. |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Tue Dec 28, 2010 2:25 pm Post subject: |
|
I definitely think it is worthwhile to fix this as the large PDF sizes that this bug creates can really slow down upload times when mailing such PDFs. Also, it can really slow down the upload of documents into NeoOffice Mobile.
Patrick |
|
Back to top |
|
|
yoxi Cipher
Joined: Sep 07, 2004 Posts: 1799 Location: Dawlish, Devon
|
Posted: Tue Dec 28, 2010 4:12 pm Post subject: |
|
Good, I just wanted to let you know there was no rush just on my account . I always got a weird rush of pride in the past when NeoOffice's PDFs were so tiny compared to the native ones... |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Sun Jan 02, 2011 12:25 pm Post subject: |
|
I think that I have fixed this problem and, when using the following test patch and your sample document, I have found that the Export as PDF feature now creates a PDF that is roughly only 25% of the size without the test patch. Interestingly, I also found that when using the following test patch and your sample document that NeoOffice exports your document to PDF roughly 4 times as fast as OpenOffice 3.1.1 - the version of OpenOffice.org that NeoOffice 3.1.2 is based on.
Can you install the following test patch and tell us if the Go-oo bug is fixed for you?:
Intel:
http://joe.neooffice.org/test/NeoOffice-3.1.2-Patch-2-Test-1-Intel.dmg
PowerPC:
http://joe.neooffice.org/test/NeoOffice-3.1.2-Patch-2-Test-1-PowerPC.dmg
Patrick |
|
Back to top |
|
|
yoxi Cipher
Joined: Sep 07, 2004 Posts: 1799 Location: Dawlish, Devon
|
Posted: Fri Jan 07, 2011 11:15 am Post subject: |
|
The first time I tried printing to PDF after installing the patch, the resultant PDF wouldn't open, but it's been fine since then - and the Export to PDF works fine too, coming out at 680kb to the other's 1.3Mb (and also seems faster). Many thanks... |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Fri Jan 07, 2011 11:23 am Post subject: |
|
yoxi wrote: | The first time I tried printing to PDF after installing the patch, the resultant PDF wouldn't open, but it's been fine since then - and the Export to PDF works fine too, coming out at 680kb to the other's 1.3Mb (and also seems faster). Many thanks... |
I am not sure what the printing to PDF problem is as the are completely separate pieces of code and neither the printing or export to PDF code share any common code. But I am glad to hear that it did not reoccur. If it happens again, can you attach the PDF. I can run a PDF decompressor program on it and see what, if anything, is scrambled in the PDF.
One thing to watch for in my patch is glyph kerning. The change that I implemented was to no longer set each glyph at an absolute X,Y coordinate on the page. In the test patch, the code only positions the first glyph in a word at an absolute coordinate and then the code puts in an amount of pixels to shift to the right or left from the end of the native glyph's width.
The risk here is that our code comes up with a different "native glyph width" than the PDF viewing application does. If that happens, then you will see some glyphs which too much or too little whitespace between it and the preceding glyph.
Patrick |
|
Back to top |
|
|
ovvldc Captain Naiobi
Joined: Sep 13, 2004 Posts: 2352 Location: Zürich, CH
|
Posted: Sat Jan 08, 2011 1:40 am Post subject: |
|
I ran a quick test and glyph spacing seems OK.
best wishes,
Oscar _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi |
|
Back to top |
|
|
yoxi Cipher
Joined: Sep 07, 2004 Posts: 1799 Location: Dawlish, Devon
|
Posted: Sat Jan 08, 2011 1:43 am Post subject: |
|
I'm on the road until Monday, so won't have a chance to road test this properly until then, but it seems fine at a quick glance. |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Wed Feb 02, 2011 10:22 am Post subject: |
|
FYI. I have included the new PDF export code in NeoOffice 3.1.2 Patch 3. You can download the patch from the NeoOffice patch download page.
Please let us know if you find any new font kerning issues in exported PDF files with Patch 3 and we will investigate them immediately.
Patrick |
|
Back to top |
|
|
|