Unrecoverable error: rangecheck in .putdeviceprops

[MaxMatti]

I am having the following problem:

$ ./pdfScale.sh -s 0.9 infile.pdf outfile.pdf Unrecoverable error: rangecheck in .putdeviceprops $ ./pdfScale.sh -v -s 0.9 infile.pdf outfile.pdf
pdfScale.sh v1.0.11 - Verbose execution Checking dependencies Scale factor: 0.9 Input file: infile.pdf Output file: outfile.pdf Width: 0 postscript-points Height: 0 postscript-points Translation X: 0 Translation Y: 0 Unrecoverable error: rangecheck in .putdeviceprops

I have no clue what's causing this or why. The input is a DIN-A4 PDF-File with 105 pages produced by pdfnup.

[tavinus]

humm.. can you annex that PDF so I can test it? Also, what system are you running this? Do you have the same problem with any file or just this one?

Width: 0 postscript-points
Height: 0 postscript-points
Translation X: 0
Translation Y: 0

These should not be Zero, something is going wrong there!

Also, what do you get if you try this: cat infile.pdf | grep -a '/MediaBox'

I should probably put a test for 0 points Width or Height, but yeah, it is failing to detect the original page size.

Sorry for the late answer...

[MaxMatti]

I have an older Linux Mint (17.1) with a kernel version 3.13 on an x86_64bit desktop pc. The cat/grep command returns no output. I can't publish the original PDF here but I will try to find something that I can publish where I have the problem.

[MaxMatti]

Ok, both files have been created with pdfnup, for the attached file I just removed all pages except for two before running pdfnup. Output this time:

$ pdftk file.pdf cat 3-4 output /tmp/input.pdf
$ pdfnup /tmp/input.pdf 
          ----
  pdfjam: This is pdfjam version 2.08.
  pdfjam: Reading any site-wide or user-specific defaults...
          (none found)
  pdfjam: Effective call for this run of pdfjam:
          /usr/bin/pdfjam --suffix nup --nup '2x1' --landscape -- /tmp/input.pdf - 
  pdfjam: Calling pdflatex...
  pdfjam: Finished.  Output was to '/home/user/input-nup.pdf'.
$ ./pdfScale.sh -v -s 0.9 input-nup.pdf out.pdf 
pdfScale.sh v1.0.11 - Verbose execution
Checking dependencies
  Scale factor: 0.9
    Input file: input-nup.pdf
   Output file: out.pdf
         Width: 0 postscript-points
        Height: 0 postscript-points
 Translation X: 0
 Translation Y: 0
Unrecoverable error: rangecheck in .putdeviceprops

input-nup.pdf out.pdf input.pdf

[tavinus]

Ok, thanks for the info and for the files.

If the cat + grep command does not work, nothing else will work, since we won't have a valid paper size to base the resizing on.

The file input.pdf works fine here (it finds de MediaBox definition, and also resizes):

$ cat input.pdf | grep -a '/MediaBox'
/MediaBox [0 0 595.32 841.92]
/MediaBox [0 0 595.32 841.92]

$ ./pdfScale.sh -v -s 0.9 input.pdf 
pdfScale.sh v1.0.11 - Verbose execution
Checking dependencies
  Scale factor: 0.9
    Input file: input.pdf
   Output file: input.SCALED.pdf
         Width: 595 postscript-points
        Height: 842 postscript-points
 Translation X: 33.055225
 Translation Y: 46.777310

File: input.SCALED.pdf

The file input-nup.pdf though has no MediaBox definition. So this one fails when greping for the page size. I have found a /BBox [0 0 595.32 841.92] on that file. That is an A4 size in postscript points. Honestly, I am not sure why you don't have a Mediabox on your pdf, but I am just now creating a version that will try to use /BBox if /Mediabox is not available and then abort execution if none of them is available.

I will post it soon. Cheers! Gus

[tavinus]

Please try to use the new version on your problematic files and let me know. ~~pdfScale v1.1.3 EDIT: Get this one instead, better parsing:~~ pdfScale v1.2.1 Yes, I did it again, newer version with -i for imagemagick + bugfixes: pdfScale v1.2.10

It scaled fine, but seems a bit off-center for me (on the 2-up resized). The positioning is determined by the translation factors and they should always center the resized pdf, based on the scale factor and page size.

Still not sure what pdfnup does to the pdf and why it leaves no MediaBox declaration. The slightly off-centered positions may have something to do with margins (for the main or each n-up page).

input-nup.SCALED.pdf

PS: Other thing I can do is to have a branch that uses identify from imagemagik to get the sizes. It gives the same size on this case though, so there would be no real benefit and you would need another dependency.

PS2: I could also have a parameter to force pagesize and even translation, but then again you would have to give the page size and/or translation values yourself. I thought that maybe an option to add or subtract from the translation factor could be interesting. (Eg. increase left translation by 5 postscript points).

EDIT157 (LOL): The translation is pretty simple:

XTRANS=$(echo "scale=6; 0.5*(1.0-$SCALE)/$SCALE*$PGWIDTH" | "$BCBIN")
YTRANS=$(echo "scale=6; 0.5*(1.0-$SCALE)/$SCALE*$PGHEIGHT" | "$BCBIN")

You move half of what you "gained". So with a scale of 0.9, you have 10% of "new free space" and then you move 5% (half) from the top-left. Not really many other ways to do that. And really not sure why the n-up pdfs are slightly off the mark. Any other file seems to center fine.

Hopefully the final EDIT: I made a bunch of tests on many different PDFs generated on different ways and with different page orientations. Honestly, your n-up file seems to be centered ok now. you can also test both with and without imagemagick with the new -i parameter. Let me know so we can close this please.

[MaxMatti]

Okok calm down I just got up and read this. I will try that now.

[tavinus]

Just get the latest master or tag and try ;)
I went a long way talking too much.
I try not to do that, but well... I fail... LOL

[MaxMatti]

Looks good to me at first glance. However in case you want it to be very exact: Try scaling the output of pdfnup with -s 0.5. It's a little bit off center. It seems to me as if it's always a little bit off center but too little to notice unless using a way to small parameter. Doesn't bother me, just wanted to mention that.

I was just referring to the final edit where you said "Let me know so we can close this please." because in my head it sounded like you have waited a few days already.

[MaxMatti]

Oh and with the -i parameter it works just fine. No offset there.

[MaxMatti]

Now I want to know: Should I always use -i or just when it's offcenter without -i? And if I should always use it why make it a parameter and not include it or put the parameter the other way around (so it's enabled by default)?

[tavinus]

Humm... the really weird thing is that the sizes rendered with and without imagemagick are the same. I mean, try posting the verbose output both with and without the -i parameter here.
I prefer not to use -i by default because it creates a new dependency, but yeah, you may always use that if you have imagemagick available.

[tavinus]

Ok, not quite... the values are inverted in your file when not using identify:

$ ./pdfScale.sh -v -s 0.5 ../input-nup.pdf
pdfScale.sh v1.2.10 - Verbose execution
Checking for ghostscript and bcmath
  Scale factor: 0.5
    Input file: ../input-nup.pdf
   Output file: ../input-nup.SCALED.pdf
         Width: 595 postscript-points
        Height: 842 postscript-points
 Translation X: 297.500000
 Translation Y: 421.000000

$ ./pdfScale.sh -i -v -s 0.5 ../input-nup.pdf
pdfScale.sh v1.2.10 - Verbose execution
Checking for ghostscript and bcmath
Checking for imagemagick's identify
  Scale factor: 0.5
    Input file: ../input-nup.pdf
   Output file: ../input-nup.SCALED.pdf
         Width: 842 postscript-points
        Height: 595 postscript-points
 Translation X: 421.000000
 Translation Y: 297.500000

I wonder how I can check this.

[tavinus]

The BBox is really set like that, not sure now.

/BBox [0 0 595.32 841.92]

I couldn't find a way to determine if it is landscape either. Can you please create a n-up file that is not landscape so I can check its BBox declaration?

[tavinus]

Aright dude... v1.3.5 is out. You made me think that I should be able to get the page size using ghostscript. I then found a solution but it involved an external PostScript file. I then embedded that file into my script and it is now working fine.

People can still use the older cat + grep method with the -c parameter.

This version should not require the -i or -c parameters to work correctly though. If anything, you will still have problems when using the -c option. I myself have use cases for -c, so I kept it.

I will try to simplify the PostScript tool later. The advantage is that it should always work and there is no extra dependency.

[tavinus]

Please let me know if the new version works well for you. Cheers!

PS:

I was just referring to the final edit where you said "Let me know so we can close this please." because in my head it sounded like you have waited a few days already.

Nothing like that, just wanted some feedback :)

[MaxMatti]

Ok, but I don't have the time right now (big test tomorrow), so I will try that in >36h. Sorry for the delay.

[tavinus]

No worries

[tavinus]

Please do not use version 1.3.x that are before 1.3.5. The input file name was hard-coded there. Fixed now. Cheers!

[tavinus]

ok... I was studying Postscript and trying to make something myself but that is not going too well. Also, I am not sure about the license of the embedded script so I removed it.

What I did now, is to create an adaptive method for page sizing. It will try cat+grep, mdls, pdfinfo, identify, then fail. This way should be fine on most systems and people can always force a method with the -m parameter.

Honestly, I never had a file without a /MediaBox until yours showed up. So that method works most of the time. Still, people can now choose to install other tools and use them automagically or in forced mode, which also solves any future problem.

Your n-up file for example, failed for me on cat+grep but then went fine on mdls and pdfinfo (automatically). Basically, if there is no /MediaBox declaration on the PDF, the cat+grep method will fail, on which case you will need to have one of the other external options for the script to run. Having a single one of them available is enough. This run example is even on the README.md now.

It also should never fail on MacOS anymore, since mdls is always there. It would fail if there is no ghostscript, but that is another problem.

Pdfinfo seems to be mostly present on Linux as well. It is either shipped by default, or I use other stuff that requires it. I mean, I tested 5 different servers with different old and new distros and they all had it available.

In any case, people can just install whatever they want to use now and the script will pick it automatically if needed.

You can get the new version here v1.4.9

EDIT: The above version marks the Adaptive Mode implementation, but such an old version should not be used. PdfScale is in active development and the master branch is always recommended.