Closed ppisar closed 1 year 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.
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.
I got a report that ptops of psutils-2.05 fails:
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:
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: