View Issue Details

IDProjectCategoryView StatusLast Update
0010505ScribusPDFpublic2012-01-10 21:22
Reporterarahne Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
PlatformLinuxOSOpenSUSEOS Version12.1
Product Version1.4.0 
Summary0010505: Big PDF with automatic setting of image compression on colormap images
DescriptionI have a document with 50 pages of colormap (8-bit per pixel) PNG images. Total file size of all images is about 2 MB, and image sizes in pixels are from 200x200 to 2500x2500. Images are mostly flat, with large areas of single color.

If I select automatic handling of image compression, it performs very poorly, it makes 52 MB file size.
If I select lossy-jpeg, best quality, the resulting file is still 52 MB, but full of JPEG artifact trash.
But if I select lossless-zip, file size is only 16 MB, and images are perfect.

PDF export is relatively slow. So this leaves enough time to do some decisions. I think Scribus should do a better job on automatic setting, and do some heuristics on the image type. If image is 8-bit colormap, it should treat it as colormap, and not upscale it to 24 or 32 bits, then compress it with JPEG adding trash, and then making big file while trying to preserve the trash it just generated. Automatic and even lossy JPEG setting should try losless and lossy compression, and use the one which makes smaller file.

Currently, an inexperienced user will choose automatic setting, and be disappointed with huge file. And when trying the lossy setting with high compression, it will only make bigger and uglier PDF. And maybe user will never try lossless-zip, thinking that compression, which does not lose quality, will always be bigger, but this is not the case.
TagsNo tags attached.
Patch

Activities

JLuc

2012-01-10 21:22

developer   ~0027508

Somehow related :
A(nother) user recently noted on irc that progressive mode JPEG induced huge PDFs, when not-progressive type just did fine PDFs (i'm not sure but i seem to remember that this user said it was a new behaviour).

Issue History

Date Modified Username Field Change
2012-01-10 18:10 arahne New Issue
2012-01-10 20:22 jghali Severity major => feature
2012-01-10 21:22 JLuc Note Added: 0027508