This issue started without any extra notice. Customer service notified us that the labels were not uploaded. Basically we receive the labels from our logistic partners, we print them out and apply them to the parcels we send out. And there is also a small step in the system where we concatenate the label batches to bigger files in order to make the printing easier for our collegues. Both the input and the output files are simple PDFs.
When we checked our logs we noticed that something had been changed with the original labels.
The error message is quite clean: the input PDF files had been changed. We could verify it easily:
We checked the link the error message mentioned… They have a commercial add-on to open PDF files higher than 1.4.
Fortunately I played with ghostscript a few days ago and remembered that it could manipulate PDF files efficiently. And Google gave us useful examples on stackoverflow.
We implemented the new code in less than half an hour. The main logic was very simple:
We gave it a try and it worked. We tried it with longer files and we noticed that a few labels had changed their orientation. 2-3 of 60 labels were landscape instead of portrait, though all the originals were portrait. And the problem appeared consistently with the same files.
We started to play with the switches… Ghostscript had much more options than we expected and its documentation is not really Google friend, but we found finally the AutoRotatePages flag.
Our first attempt was the
-dAutoRotatePages=/All setting, but this uses some kind of majority decision for rotating the pages…
We tried this with only one label which had been rotated unintentionally.
It did not work as we could expect.
It seemed that something like this had been enabled on page level.
At least with this given file ghostscript did the same rotation with or without the flag.
Fortunately our next attempt was successful.
Which worked properly for both the big batches and all the single files.
A 27 years old software saved our day.