Summary: | mixed page size creation for fax use | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Lee Howard <faxguy> |
Component: | General | Assignee: | Alex Cherepanov <alex> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | christinedelight.top85 |
Priority: | P2 | ||
Version: | 0.00 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- | |
Attachments: |
changes AdjustWidth from 0,1 to n=columns
patch patch |
Description
Lee Howard
2005-05-02 13:23:00 UTC
Here's the relevant AdjustWidth code from src/gdevfax.c: /* Initialize the stream state with a set of default parameters. */ /* These select the same defaults as the CCITTFaxEncode filter, */ /* except we set BlackIs1 = true. */ private void gdev_fax_init_state_adjust(stream_CFE_state *ss, const gx_device_fax *fdev, int adjust_width) { s_CFE_template.set_defaults((stream_state *)ss); ss->Columns = fdev->width; ss->Rows = fdev->height; ss->BlackIs1 = true; if (adjust_width > 0) { /* Adjust the page width to a legal value for fax systems. */ if (ss->Columns >= 1680 && ss->Columns <= 1736) { /* Adjust width for A4 paper. */ ss->Columns = 1728; } else if (ss->Columns >= 2000 && ss->Columns <= 2056) { /* Adjust width for B4 paper. */ ss->Columns = 2048; } } } This is fine for facsimile with a rough horizontal resolution of 200 dpi (normal, fine, superfine), but it will not work for ultrafine (300 dpi) and hyperfine (408 dpi) because the number of columns will be wrong. Furthermore, (as I indicated already) some PostScript writers format pages with slightly incorrect page sizing, which causes these column checks to fail, which causes the TIFF to be sized incorrectly for fax, which causes the fax to fail to be transmitted properly. Instead of checking columns on the input document, AdjustWidth should simply conform all output to the same width (the width of the page size specified on the command line or the horizontal resolution specified on the command line). You can't fax variable-width TIFFs, anyway. Created attachment 1355 [details]
changes AdjustWidth from 0,1 to n=columns
Here's one idea.
It makes AdjustWidth=n where n is the number of columns. It tries to stay as
backward compatible as possible by defaulting to 1728 columns. If people were
using this and avoiding AdjustWidth before... by luck... then they'll need to
set AdjustWidth=0 to get the previous behavior. If people were using B4 pages
before, then they'll need to set AdjustWidth=2048 to get the previous behavior.
For some reason that I haven't investigated yet the patch I provided only works for -sDEVICE=tiffg3 and not fully for tiffg4 and tiffg32d (in the cases where the pixel width is not 1728). The tiffg4 and tiffg32d matters were addressed on Bug 688748. Alex, assigning this to you because it references a bug you already fixed. Created attachment 2873 [details] patch This is a filly backward-compatible version The values of AdjustWidth now nean 0 - No adjustment, the same as before 1 - low res fax adjustments, the same as before >1 - adjust to the given width, regardless of the document width Thank you for your participation now, here. Understand that although it will typically be acceptable for the interpreter (gs) to make a decision as to the width based on input document size - this will not always be true. The calling application must have the ability to specify which page width is used... even if the input document does not closely match it. Furthermore, there are other horizontal resolutions for fax besides the typical 8 lines per mm (~200 dpi). 16 lines per mm and 300 dpi are two other popular ones (and yet others are also possible). It's not wise to try to build this fax-options intelligence into Ghostscript or to limit Ghostscript's usefulness for the less-used resolutions. Please, leave the width-specification to the application invoking gs. The proposed patch does not fully satisfy the intent of the original bug report. I.e. the original adjustments are broken and should be removed. I'd rather keep Ghostscript backward-compatible. I would strongly doubt that AdjustWidth is being used by many (if any at all) in a way that would prove my suggested approach to be backwards-incompatible. Even so, sometimes I feel that it's necessary to break backwards compatibility in a "bug fix" sense when maintaining backwards compatibility would merely be perpetuating a flawed design. In this case it's a flawed design because it really doesn't give the user good control over the exact width to which the pages are being adjusted. In order to rely on the feature one would essentially have to prepare the input documents beforehand to make sure that they fall within the ranges (and if the user is going to do that - then AdjustWidth becomes superfluous). If complete backwards compatibility is important (shortcomings included), then can I request a new option like, maybe, "FixateWidth" that would override AdjustWidth and allow the user the degree of control that I am requesting? Alex, please commit your proposed patch and I will be happy to see this bug closed with that. Thanks. Created attachment 7570 [details]
patch
Port the last patch to current Ghostscript.
The patch has been committed as a rev. 8b90a80fe86364c0b6c1cad12cfb241c66943c24 |