We generate several PDFs from each FM document. Webmasters have asked us to start adding the PDF filename into the File Information field.
We custom-name each PDF as we create it. We have too much volume to manually add the filename to the PDF at each printing.
I can't find a way to configure the FM document so it generates specific file information for each condition-setting version.
What automation tool(s) are likely to help?
Can't help, I'm afraid, with automatically populating the file info fields of a .pdf – but I have to wonder why your webmasters want you to duplicate the filename!
Re-reading, I wish I could go back to edit. I tried to keep my question short and oversimplified.
The PDFs I create are named "doc#-revision.pdf" (unique filename for tracking).
The webmasters post PDFs named "doc#-productname" (unchanging filename for easier website updates).
They said they can save my PDF according to what's in the PDF "document title" field.
PROBLEM: As far as I can tell, FM only maintains one text string for the File Info field for any particular book. I would need a way to generate that field differently for each conditional-text version in the book.
We don't have FrameScript, but I'm willing to consider it if it's known to work.
Would it be a simpler solution if you rename your FrameMaker file to match the required final name pattern? Or maybe with a combination of it like "doc#-productname-revision"? For handover to the webmaster you can then just delete the "-revision" part in the filename (and for many files there are good file renaming tools with pattern matching for s few bugs, that could automate this step.
We might be able to use Bob's idea of extra copies of the
.book files. I'll have to talk about it with the other writers. It would certainly work to insert the file
info into otherwise-exact copies of the .book file. There'd be overhead remembering to generate
each brand from its specific .book, to redo any book-level changes to all
variants, and figure out how to organize those variants in the archive for next
In answer to Stefan's questions--
The webmasters originally did ask us to hand over
documents in their pattern -- but their naming conventions changed more than
once and was extra work. We are trying
to touch each PDf only once, and so we release them with their unique,
predictable filename in an archive where everyone else picks them up when
needed. (Including the webmasters.) Unfortunately,
the webmasters support quite a few other divisions, so stripping the revision
level wasn't as straightforward as they would have liked. Rev -C got conflated with a -C Canadian
version, for example.
I'm going to leave this an active question until Monday
though, in case someone comes up with an idea with less overhead.
(Sorry for the weird formatting -- I'm not sure where those extra line breaks came from!)
unexamined thought … if you cheerfully multiply folders, you could store each set of .pdf in a separate folder, such as output_July2019 and output_August2019, without having to adjust/manage new filenames. I do something close to this with WebHelp, where the similar requirement for successful co-operation is to keep the names of the deliverables unchanged from release to release.
Interesting idea but it goes onto a simple SharePoint library so our PDFs will stick with manual# & revision as the filename.
And honestly, we have so many docs active that I shudder at adding folder levels.
Aargh … you didn't mention SharePoint before! we don't have any requirements for retrieving earlier document versions, so we usually keep to short filenames (no version/date information) and no folders; where things like certification docs do require versioning, we use a hand-rolled docVersion field rather than SP's flawed automatic version info. For the helps I illustrated, should anyone want to put them in SP, we'd probably make a .zip.
As for generating the folder, that's just a matter of specifying a new output folder at generation. Your post makes me think I have it relatively easy ;-} Good luck!
If the documents are FM books, you can have a separate parent .book file for each instance, with its own metadata.
If they are single .fm file documents, I'm wondering if .book parents could be created for them anyway.