PDF XChange Forum

Hello,
when we are opening a file from our internal Content-Manager this URL has a bunch of parameters. When we try "send by Email" of the PDF from PDFXChange Editor the following temporary file is created:

pdfx-{9A7FD14A-3A1D-4085-AC9C3F4BC826580B}\A1001001A29J29B45959D19641.pdf order=retrieve&item-id=A1001001A29J29B45959D19641&version=1&collection=CBR.CLLCT001&libname=cmtst&update-date=2019-10-29+13%3A59%3A49.344247000&token=ADGA.pdf

After that, the email creation fails.

When we try to rename the file from Windows Explorer, we get an error message that the file is too long.

Could you change the temporary file names to something shorter? I strongly suspect that the extremely long file names break the creation of the email.

Regards,
Andreas

Hello Ankeilha,

Just to verify, are you running the current latest version (8.0.333.0) of our software when encountering this issue?

Kind regards,

Hello Daniel,

yes, I am using version 8.0.333.0. The behaviour is the same for the standalone PdfXChange-Editor and for our embedded PdfXChange-Editor (using the SDK).

Kind regards,
AnKeilha

Thank you for clarifying.

You had originally posted in the End user forums, so I have moved this topic to the relevant SDK forum for you, so that our development team might see it and be able to offer some guidance.

Kind regards,

Just to clarify: I see the same behaviour no matter what I use (ordinary PdfXChange-Editor or the embedded PdfXChange-Editor using the SDK). That is why I originally posted this in the end user forum.

Hello AnKeilha,

A ticket in our internal problem reporting system was created:


#4981: Editor SDK: Temporary Files for PDFs from URL are extremely long when using "send by Email"

Please refer to this ticket number when you are asking about the status of the problem.


Regards.

Is there any news on this issue?

Hello AnKeilha,

Just checked in with the dev, who is responsible for this issue - he said that he did not manage to look at it yet.

Cheers,
Alex

Hello,
I just checked the latest version ("10.4.2, build 390, Portable") and the version we use ("10.1.1, build 381") and the problem seems to be fixed now.

Best regards,
Andreas