I have a registered event extendscript that is normally triggered upon opening a MIF file. The script automatically saves the MIF file in a certain location, closes the MIF and opens the FM file.
Surprisingly, when publishing HTML5, the script is triggered, both when the publisher tries to retrieve the styles used in the book files and when running the conversion to HTML5. There is no way to stop script execution/publisher except for killing Framemaker.
Does Framemaker save files as MIF when trying to map FM styles to HTML and when converting to HTML5? Sounds like a bug to me.
Thanks for your input in advance!
It could well be part of the transform to HTML5 - saving as MIF would allow both structured and unstructured FM files to use the same process for conversion. I would not consider this to be a bug. It might be required to adapt your script in a way that would avoid the automatic execution of your code - prevent it from doing stuff when the MIF file that is opened is in a certain location (output folder, temp folder) or the reverse - only execute when opening a file that is in a certain directory or its subdirectories.
In general, event scripts should be cautious about just going ahead and doing their stuff - build in a lot of precaution to determine whether the event should really happen or not.
Thank you for your prompt response!
Somehow, I felt you would respond to this question. Telepathy? 🙂
So you claim that structured files are saved as MIF before turning them into HTML?
In my case, these are unstructured files. I wouldn't want to restrict the script so that MIF files stored in a certain location will be ignored when opened.
Now I realize why it takes ages for Framemaker to map styles in a (large) book each time the publisher's Style Mapping dialog is opened and why it takes ages for Framemaker to create HTML output from this book. The situation is no better in FM19, despite Adobe's claim that the application has been revamped and optimized.
I would do the following: add an alert to your event script showing which file is being opened (causing your event handler to be called). Make it an Alert( ) to allow canceling the action. Then publish something - one chapter to start with - from your unstructured FM to HTML5 and see which file is being opened. This will likely be in a temp directory that is determined by either the standard settings of FM or in the target output folder. If there is any string in that path that can safely be recognized as being opened by FM when creating HTML5, that substring can be used to recognize when your event handler should NOT perform the usual action.
Let me know if this works out for you.
An alternative approach is to create a small script to kick off the Publish process. The script could unregister your event, Publish and then turn the event back on.