Forum > Fujifilm XMF

'Open preflight report with document' in XMF crashing Acrobat + Pitstop

(1/2) > >>

ksm1701:
Hi all - hope somebody can help with this as it's driving me mad!

After preflighting in XMF I like to see what errors have been picked up so right click on the PDF and then select 'Open preflight report with document' which then opens the preflight report with the document PDF in the background.

When I click on any of the small magnifying glass icons to the left of text on p1 of the preflight report, historically it would then automatically switch to the affected area on the document PDF. Now, however, it just causes Acrobat (and Pitstop) to crash immediately.

Weirdly, if I open the preflight report first and then the document PDF separately clicking on the magnifying glass icon will open the affected area I want to view on the document PDF.

Annoyingly this seems to ring a bell with me that it also happened years ago but I can't for the life of me recall how (or if) I managed to fix it!

I'm currently running XMF version 6.10.1 and up to date versions of both Acrobat Pro DC and Pitstop Pro 2020.

Fingers crossed somebody may have experienced a similar issue.

Thanks in advance for any help offered guys 👍

abc:
Answered this on the Printplanet version of the question.

ksm1701:
Many thanks.

abc:
Let me know if it gets resolved please.

ksm1701:
Hi Andrew,

Not resolved unfortunately as there doesn't appear to be a clear fix, but here's the reply I received from support for reference:


--- Quote ---We investigated the crash report.
When clicking the magnifying glass, PitStop starts looking for the document that matches the report.

First it checks all open documents. This doesn't return a result, probably because:
a timing issue causes Acrobat and/or PitStop to think the document is not open yet; or
(more likely) the file path stored internally in the report doesn't match with the open document (perhaps because of how Fuji XMF works with files).
Next it checks whether it can open a file at a path relative to the report.
If nothing is found yet, it checks whether it can open a file at the path stored internally in the report. This is the same path as in step 1, but now it's being used to try to open a file rather than check whether the file is already open.
As a final step we ask the user to point to where the file is. Evidently we never get to this step.
So the crash is in steps 2 or 3. These two steps are indistinguishable in the crash log. Both these steps try to open a file at some path, and the crash log indicates that this fails. The crash log does not indicate why it fails, just that it does. One possibility is that Acrobat says this file is already open - although then it should have been found in step 1. Another possibility is a file system problem - e.g. no permissions on the path. These are just guesses at this point.

"permissions or access issue"

I agree, this is a definite possibility. If in step 2 or 3 PitStop doesn't have read access on the path it's trying to open, this could indeed cause a crash. The two paths being checked are both stored inside the report; one is a relative path the other is absolute. I believe there recently was another support case where we showed how to find the path using Browser.

My guess is that this different way of opening the document causes step 1 to succeed: the already open document is recognised as the correct one.

However, the relevant code has not changed between PitStop Pro 2019 and 2020. On the one hand this means it's not something we broke, on the other it also means the problem is already present in 2019 (so downgrading just PitStop won't help).
--- End quote ---

Many thanks.

Navigation

[0] Message Index

[#] Next page

Go to full version