Page gets resized instead of cropped

[ksetlak]

Describe the bug

When attempting to crop a page, it gets resized instead.

To Reproduce

Steps to reproduce the behavior:

1. Open a PDF file
2. Select a page
3. Open the "Page Format" dialog
4. Set one of the text fields for cropping to some value, e.g. 60
5. Confirm, exiting the dialog.

Expected behavior

The page gets cropped by specified amount.

Actual behavior

Page appears to be small - it is resized or the view is zoomed out, but likely the former. It is not cropped.

Input files

test.pdf attached.

Screenshots

I can provide a video if needed.

System and Versions

• pdfarranger 1.7.1 (.msi package)
• pikepdf version - not sure, but whatever is packaged with above ^
• OS = Windows 10

Additional info

I also noticed that I cannot resize the page - when attempting to change the value in the text field for scale factor, it gets reset to 0 at first opportunity. Pressing The "+" button next to this field does nothing.

[kbengs]

Hm.. I am not able to reproduce that. Could you add a screenshot of how it looks after? For example one page where left is cropped by 60%, one with right cropped by 60% etc.

Do you see the same issue with the latest build found here:
https://github.com/pdfarranger/pdfarranger/actions/runs/1351929092

[ksetlak]

Yes, the issue also occurs on the most recent development build.

Before:

After cropping from left (50%)

After cropping from right (60%)

[kbengs]

Okay. It's a bit hard to figure out what is happening. If you are able to help you could:
(this need to be done with the build found in the link above)

1. Download the source code on github main page
2. Copy pdfarranger.py from the downloaded zip to:
   C:\Users\USER\AppData\Local\Programs\pdfarranger\lib\pdfarranger
   (replace USER with username)
3. Add the following 4 lines after the imports on line 33 in pdfarranger.py
   sys.stdout = open('C:\\temp\pdfarranger_stdout.txt', 'w')
   sys.stderr = open('C:\\temp\pdfarranger_stderr.txt', 'w')
   sys.stdout.write('stdout test\n')
   sys.stderr.write('stderr test\n')
4. Create c:\temp if it does not exist
5. Open PDF Arranger and try to crop as before
6. Close the app and see if something is written into the two files

[ksetlak]

I've done what you asked for, but the issue suddenly stopped reproducing on my machine. I guess we can close it... Of course if it ever happens for me again, I'll know how to capture logs and I'll try to do this, then reopen the bug, but for now I don't think it's likely we will be able to observe it again...

(btw. - for Windows paths don't forget to do something about \ escape char behavior like doubling the backslashes or prepending the string with an "r" before the quote marks)

[ksetlak]

For the record - I just got a reproduction of this error and both "log" files only contain stdout test and stderr test lines, respectively. No more error messages logged.

[kbengs]

If you want to dig more into this you can:

1. copy croputils.py into C:\Users\USER\AppData\Local\Programs\pdfarranger\lib\pdfarranger
2. add print('s', s) to line 68 in croputils.py (so that is prints the result of s = locale.format_string("%.8g", self.get_adjustment().get_value()))
3. try to reproduce the issue.
4. Close application and see what is in pdfarranger_stdout.txt

[ksetlak]

Hmmm...

stdout test
s 0
s 0
s 0
s 0
s 0
s 0
s 0
s 0

Does this tell you anything?

[kbengs]

I think locale.format fails and therefore it try to set scale factor to 0%

Here would be some more ideas.

@@ -54,6 +54,7 @@ class _LinkedSpinButton(Gtk.SpinButton):
 
     def __init__(self, minval, maxval, step, page=None):
         Gtk.SpinButton.__init__(self)
+        self.set_numeric(True)  # 1
         self.set_digits(20)
         self.set_width_chars(9)
         self.connect("output", self.__output)
@@ -63,7 +64,11 @@ class _LinkedSpinButton(Gtk.SpinButton):
 
     def __output(self, _user_data):
         """ output signal handler to remove unneeded 0 """
-        s = locale.format("%.8g", self.get_adjustment().get_value())
+        s = locale.format_string("%.8g", self.get_adjustment().get_value())  # 2
+        print('a', self.get_adjustment().get_value())  # 4
+        print('s', s, len(s))
+        print(locale.getlocale())
+        print('')
         self.get_buffer().set_text(s, len(s))
         return True

Does this fix the problem? If not you could also try to comment out the self.connect line

[dreua]

I also noticed that I cannot resize the page - when attempting to change the value in the text field for scale factor, it gets reset to 0 at first opportunity. Pressing The "+" button next to this field does nothing.

Does this mean the scale factor is pre-filled with 0 and you can't change it? Then that's our bug. If I manually set the field to 0 my results match yours. The field should be pre-filled with 100 and adjustable between 0.5 and 20000.
Can you toggle the radio button to width / height? Does it change the behavior of the input field?

[ksetlak]

I'll have to allocate some time to this and sit down to really gather some more particular info. I think this bug deserves a reopen. One thing I noticed about this is that it seems to occur only if I open a PDF from the "Open with..." option in Windows 10 context menu in its file manager. It seems to work fine when opening the app first and then using the built-in file opening dialog.

I'll check the code snippet from @kbengs and try to find an answer to questions asked by @dreua when I have some time to look at this properly.

[ksetlak]

Hm, interesting. This time again only opening the PDF through the "Open with..." path causes problems (by which I mean that when running the program itself, it runs fine), but this time it's not cropping that works weird - it's this error:

[ksetlak]

Tried on a different Windows machine and got this:
pdfarranger_stderr.txt

[jeromerobert]

For the Open With issue, qpdf cannot be loaded.

• you mixed multiple version of PdfArranger with incompatible libraries
• OR an other program (not related to PdfArranger) installed some mingw64 dll to c:\windows\system32 and they are conflicting with the one packaged with PDF Arranger
• OR an other program (not related to PdfArranger) added it's library folder to the global %PATH% environment variable.
  Note that those 3 reasons are quite similar. You can try to play with Dependency Walker to find why qpdf cannot be loaded.

For the pdfarranger_stderr.txt issue:

• You are using a old pdfarranger.py with a new pdfarranger.ui. self.progress_bar has been removed in 06e0377 (after 1.7.1 and before 1.8.0). You can check that your pdfarranger.ui does not contains any progressbar. Did you manually mixed 2 versions of PDF Arranger ?
• Following issues are have the same root cause: a old pdfarranger.py not compatible with other PDF Arranger files.

[ksetlak]

OK, so in first case I messed stuff up. I tried to get pdfarranger run from and IDE so that I can hook it up to a debugger and take a closer look at what is happening inside - trying to figure out what I have to do to make it run in Windows using system environment I made a spaghetti out of my environment, so I think it's best to not pay attention to that case...

Second case: Yup! My bad! Here's stdout after cleaning it up:
pdfarranger_stdout.txt

[ksetlak]

For contrast, a log for the exact same actions, but on a PDF opened using the in-app "Open file" dialog:
pdfarranger_stdout.txt

[jeromerobert]

Could you:

• Get https://docs.microsoft.com/en-us/sysinternals/downloads/listdlls
• Start PDF Arranger with Open with then listdlls64.exe -u pdfarranger.exe > dllopenwith.txt
• Start PDF Arranger normally then listdlls64.exe -u pdfarranger.exe > dllopenfile.txt
• Find the differences between both (eventually past both here)

[ksetlak]

Unfortunately, the files are the same:

InputObject       SideIndicator
-----------       -------------
.\dllopenfile.txt =>
.\dllopenwith.txt <=

dllopenwith.txt
dllopenfile.txt

[jeromerobert]

Unfortunately, the files are the same:

No, libffi-7.dll is missing in dllopenwith.txt, that's suspect. Could you redo the same without the -u flag ?

[ksetlak]

Sorry for my ultra sluggish response! Here it goes:
dllopenwith.txt
dllopenfile.txt
Looks like the problem may be caused by pdfarranger using a version of libffi-7.dll installed with mitmproxy.

[ksetlak]

Uninstalling mitmproxy caused the issue to stop occurring. Is there any elegant way to shield pdfarranger from loading dlls in such a "random" way in certain scenarios?

[dreua]

That would be great, a lot of windows issues here seem to be related to loading of the wrong libraries.

[jeromerobert]

Well observed !

I just checked that mitmproxy add it's bin directory to the %PATH% global variable. There is nothing reasonable we can do for that. You should be able to make mitmproxy and PDF Arranger work well together by cleaning your environment variables after installing mitmproxy.

If I wanted to mess around I would suggest to add PDF Arranger to the global %PATH% and copy it's libraries to c:\windows\system32 so we would have a chance to break mitmproxy and Tesseract 😈.