pdf_split creates file names with excessive length about qpdf HOT 10 CLOSED

Submitted qpdf 1.3.3 to cran.

from qpdf.

Can you send a pr?

from qpdf.

I think that you are asking for a pull request, which I understand to mean a proposed correction to the code. However, I am not a C++ programmer and could not find the part of the code that creates the filename. I am sorry, but I cannot help with fixing the code.

BTW, Above I proposed computing the exact size needed for the index numbers in the file name. I realized later that a simpler solution might be to always use a 9 digit number. That would accommodate up to 1 billion pages and so would be very unlikely to cause problems for anyone.

from qpdf.

I am not a C++ programmer either, but I'd also appreciate if this could be fixed.
The described behaviour stems from this line:

(If I had to fix it, I'd #include <math.h> in bindings.cpp and use floor/log from that file. But I perhaps Rcpp offers something better here?)

from qpdf.

Yet another non-C++ programmer but one of my scripts also just choked on the same problem.

The description from Enrico @enricoschumann looks very useful for me but I also don't know enough C++ to turn this into a fix in the code (and ultimately into a PR).

Jeroen @jeroen, is this something you might be able to have a look again in the not so distant future?

from qpdf.

Can you please include example code? It seems to work as intended for me, the filename is postfixed with a number, but not excessive.

> pdf_file
[1] "/var/folders/gz/rwkfg8wx1wqgcr0ccpz42dyc0000gn/T//RtmpZvEBI7/output.pdf"
> pdf_length(pdf_file)
[1] 3
> pdf_split(pdf_file)
[1] "/private/var/folders/gz/rwkfg8wx1wqgcr0ccpz42dyc0000gn/T/RtmpZvEBI7/output_001.pdf"
[2] "/private/var/folders/gz/rwkfg8wx1wqgcr0ccpz42dyc0000gn/T/RtmpZvEBI7/output_002.pdf"
[3] "/private/var/folders/gz/rwkfg8wx1wqgcr0ccpz42dyc0000gn/T/RtmpZvEBI7/output_003.pdf"

from qpdf.

Ah I found the issue. It is fixed now, you can install the new version from https://ropensci.r-universe.dev/qpdf. I'll try to release to CRAN soon.

FWIW, if you had included a reprex code it would have been much easier for me to fix this sooner.

from qpdf.

Fantastic, Jeroen, thanks for resolving this issue - and apologies for not posting a reproducible example.

BTW: I think this also resolves the issue that had prompted PR #6 which can be closed now IMO. Your solution is nicer.

from qpdf.

Fantastic, thanks, already live.

from qpdf.

great, many thanks!

from qpdf.