rrthomas / psutils

Utilities for manipulating PostScript documents
GNU General Public License v3.0
39 stars 11 forks source link

pstops: shifting relative to page dimensions fails without a --paper option #35

Closed ppisar closed 1 year ago

ppisar commented 3 years ago

I got a report that ptops of psutils-2.05 fails:

$ perl -I. ./pstops '0L@.7(1w,0)+0L@.7(1w,.5h)' </tmp/input.ps >/tmp/bad.ps
pstops: paper size not set

while it used to work with psutils-1.23 where it used a default paper size if not specified with the option.

I can see that pstops(1) manual permits a case without a known output paper size when dealing with the final bounding box:

   Paper  size names are converted to dimensions using paper(1).  The output paper size,
   if set, is used (after scaling) to set the clipping path for each page.

When fixing the page shift, would you accept a change that would change this behavior (i.e. use a default page size even for the clipping), or would you rather preserve it? I think it's more useful to default in all cases to the default paper size.

Also please notice this mishandling of an empty string:

$ perl -I. ./pstops --paper '' '0L@.7(1w,0)+0L@.7(1w,.5h)' </tmp/input.ps >/tmp/bad.ps
Use of uninitialized value in subroutine entry at PSUtils.pm line 39.
Use of uninitialized value in subtraction (-) at PSUtils.pm line 40.
Use of uninitialized value $str in substr at PSUtils.pm line 40.
Use of uninitialized value in subroutine entry at PSUtils.pm line 39.
Use of uninitialized value in subtraction (-) at PSUtils.pm line 40.
Use of uninitialized value $str in substr at PSUtils.pm line 40.
[1] [2] Wrote 2 pages
rrthomas commented 3 years ago

When fixing the page shift, would you accept a change that would change this behavior (i.e. use a default page size even for the clipping), or would you rather preserve it? I think it's more useful to default in all cases to the default paper size.

I think I agree that using the default paper size in all cases would be fine. However, there are cases where you don't want an output paper set. At least, I presume so, from the fact that parse_file in PSUtils.pm takes a parameter $explicit_output_paper. So it seems that pstops would need a flag -no-output-paper or similar. I guess psselect should use this new flag? This flag could also be used if there were a problem with setting the clipping path.

Also please notice this mishandling of an empty string:

Thanks, this should be fixed now.

rrthomas commented 1 year ago

I would like to avoid adding a new flag. On reflection, I think it's better to keep the previous behaviour, and not set the clip path if no paper size is set.

Hence, if the paper size is not set, w and h should refer to the default paper size but this should not cause a paper size to be set in the output.