Bug 94655 - Scale-to arguments not working in some cases
Summary: Scale-to arguments not working in some cases
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: utils (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-21 22:10 UTC by Stephen E.
Modified: 2016-04-02 10:37 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
ZIP archive containing good.pdf and bad.pdf (1.37 KB, text/plain)
2016-03-21 22:10 UTC, Stephen E.
Details
Calculate rotation before scaling (1.28 KB, patch)
2016-03-29 02:39 UTC, Jason Crain
Details | Splinter Review

Description Stephen E. 2016-03-21 22:10:45 UTC
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.
Comment 1 Jason Crain 2016-03-29 02:39:35 UTC
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.
Comment 2 Jason Crain 2016-03-29 03:08:07 UTC
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.
Comment 3 Carlos Garcia Campos 2016-04-02 10:30:37 UTC
(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.
Comment 4 Carlos Garcia Campos 2016-04-02 10:37:09 UTC
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.