Summary: | pdftocairo ignores output filename | ||
---|---|---|---|
Product: | poppler | Reporter: | Robert Sachunsky <robert.sachunsky> |
Component: | utils | Assignee: | poppler-bugs <poppler-bugs> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | ori |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Robert Sachunsky
2014-11-13 14:27:34 UTC
I'm not seeing what the problem here is. The appended page number for the image formats is documented in the man page. The help summary is only intended to provide a reminder of the options. What specifically do you think needs to be changed? (In reply to Adrian Johnson from comment #1) I must apologize for not reading and testing thoroughly. Indeed the output filename is perfectly predictable, once you know the meaning of "output filename". However, for the image formats, it is against expectations, and not consistent with the manual, which states: > The image formats (PNG, JPEG, and TIFF) generate one file per page > with the page number and file type appended to output-file > (except when -singlefile is used). When the output format is a vector > format (PDF, PS, EPS, and SVG) or when -singlefile is used, > output-file is the full filename Despite this, using -singlefile does append the file type, thus output-file is not a "full filename". (In reply to Robert Sachunsky from comment #2) > Despite this, using -singlefile does append the file type, thus output-file > is not a "full filename". Yes, the behavior is inconsistent with man page. I checked pdftoppm -singlefile and it also appends the file type. I'll update the pdftocairo man page to correctly document the behavior of -singlefile. I've pushed an update to the documentation to state that -singlefile appends the file type. If you want to specify the full name you can use '-' to write to stdout and redirect it to the file. Note there is a bug in writing to stdout with image files. I've also pushed a fix for this. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.