Here in the UK, we've just been upgraded to XMF v6.13.0.1 which now works with Monterey with no immediately apparent issues so far.

I now just need to persuade the higher-ups that I REALLY need a Mac Studio to be able to perform my day to day duties at optimum efficiency!

Not sure if it's true wherever in the world you might be based, but here in the UK, most of the 'Blood Sausage' types I have every worked with have all tended to end up as department managers!

I've just installed Monterey on a Mac we are no longer using and can confirm that the XMF client bounces once in the dock and then just lies down and sulks (ie, it definitely doesn't work!). 

I have also added the following additional information to the case:

QuoteThanks for investigating crash report and getting back to me.

As there doesn't appear to be a clear solution or culprit to what is going wrong I guess I will just have to live with the issue.

Out of interest, I attempted to re-install Acrobat Pro XI so that I could then try Pitstop 2019 with it to see if the issue still occurred with that setup but unfortunately the Acrobat installer didn't appear to install correctly.

I have checked the install on a colleague's Mac and he is running the same version of XMF  with Acrobat Pro XI and Pitstop 2018 and he doesn't have the same issue. He is, however, running Mac OS Mojave (10.14) whereas I and my colleague who is also affected are running Mac OS Catalina (10.15).

Could that additional information shed any light on where the issue may lie?

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:

QuoteWe 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).

Many thanks.

Many thanks.

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 👍

Looks like I'll hold off updating for a while then!

Thanks for all the replies - I'd like to add though that for those holding off updating to High Sierra we had no issues with XMF compatibility here but, as ever, YMMV!

Has anybody been bold and update their macOS to Mojave?

Heard from Fuji UK that they are currently testing XMF with Mojave and not to update just yet while they evaluate.

Think we had this warning a couple of years ago with XMF and Sierra but I went ahead anyway and updated with no issues.

Not sure whether to carpe diem it and go nuts or try to exercise a little bit of patience

Thanks for all the replies guys.

As mentioned earlier, I often impose jobs like these using a portrait page orientation and then cheat by rotating the landscape pages anti-clockwise by 90º (with the exception of the back cover page).

Guess I'll have to chalk this one up to one of XMF's more 'unique' features and just continue cheating it!

Quote from: Tracy on August 24, 2018, 08:21:13 AMDouble click on the pages in the Reading Order and you will see the rotation buttons
you can rotate individuals pages there before the impo

Thanks Tracy but ideally I'd like to rotate the imposition rather than the pages.

Finicky I know, but that's just how I roll

Thanks Joe.

I know you can (or at least could) easily do it in Signastation, but XMF seems to link rotation changes made to the front to the reverse unfortunately.

I've been using it for three years know and still get annoyed with these frustrating quirks the software has!

Hi all,

I'm trying to impose an A4 landscape job, wiro-bound on the long edge with a head to foot imposition to avoid having to faff and rotate pages either in XMF or in Acrobat.

XMF doesn't seem to want to allow me to do this and whenever I rotate a page in the imposition the reverse page also rotates in turn.

Does anybody know a way to get the pages to rotate independently of each other?

Thanks in advance guys!