amend 2-GB workaround in GrayscalePdf to use variable '-quality'

Bug #174534 reported by Hank Bromley
2
Affects Status Importance Assigned to Milestone
Deriver
Confirmed
Low
Unassigned

Bug Description

Currently, the first uses the default quality level, and if that produces too large a pdf to provide pdf_comp as input, it remakes all the grayscales at quality 70 (typically cutting the file size by about 4).

That has drawbacks:

- time wasted in redoing all the grayscales when output is too large
- default quality probably higher than necessary for good results (and may therefore take longer than necessary)
- 70 may be lower than is needed to shrink output enough to fit
- hasn't happened yet, but potentially failing on the second pass, if 70 is still too high, and giving up

If we can produce a decent estimate of file size under different quality levels, it should be possible to choose an optimal quality level on the first pass: if the lowest quality that yields good results will produce small enough output, use it; otherwise drop quality just far enough to make the output fit.

Tags: grayscale
Changed in deriver:
status: New → Confirmed
Changed in deriver:
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.