| Summary: | Scale-to arguments not working in some cases | ||
|---|---|---|---|
| Product: | poppler | Reporter: | Stephen E. <bhs2007> |
| Component: | utils | Assignee: | poppler-bugs <poppler-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
ZIP archive containing good.pdf and bad.pdf
Calculate rotation before scaling |
||
Created attachment 122599 [details] [review] Calculate rotation before scaling (In reply to Stephen E. from comment #0) > I have encountered some strange PDF files which seem to cause pdftocairo and > pdftoppm to scale incorrectly with the -scale-to-x and -scale-to-y CLI > arguments. PDF's page rotation is screwing up the scale calculation. PDF specifies /Rotate 270. Attached patch fixes it by moving the scale calculation to after the rotation calculation. I realized that pdftoppm's behavior is different. Running "pdftoppm -png -scale-to-x 300 -scale-to-y 800 ..." on this PDF will make a 800x300 result because of internal rotation. Does anyone else consider that correct? I'd prefer it to make a 300x800 image regardless of rotation. (In reply to Jason Crain from comment #2) > I realized that pdftoppm's behavior is different. Running "pdftoppm -png > -scale-to-x 300 -scale-to-y 800 ..." on this PDF will make a 800x300 result > because of internal rotation. Does anyone else consider that correct? I'd > prefer it to make a 300x800 image regardless of rotation. I don't know, but I think it's important that tools having the same arguments are consistent to each other. So, I think we can file a new bug report to discuss this. Patch pushed. |
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.
Created attachment 122468 [details] ZIP archive containing good.pdf and bad.pdf I have encountered some strange PDF files which seem to cause pdftocairo and pdftoppm to scale incorrectly with the -scale-to-x and -scale-to-y CLI arguments. I've attached two examples, good.pdf and bad.pdf, both of which consist of a single 8.5x11" portrait page. Download each and run the following: pdftocairo -png -singlefile -f 1 -scale-to-x 1275 -scale-to-y 1650 bad.pdf bad pdftocairo -png -singlefile -f 1 -scale-to-x 1275 -scale-to-y 1650 good.pdf good file bad.png good.png Here's the output: bad.png: PNG image data, 986 x 2136, 8-bit/color RGB, non-interlaced good.png: PNG image data, 1275 x 1651, 8-bit/color RGB, non-interlaced Two things to notice: - bad.png ended up with a resolution of 986x2136, which makes no sense given the requested dimensions of 1275x1650. - good.png ended up as expected, with the exception of an extra row of pixels (1651 vs 1650) - I think this may be a different bug.