We use Patternstream to generate database sourced documents via Framemaker. When we moved our Framemaker setup from Windows XP to Windows Server 2008 (along with upgrading from Frame 7 to Frame 12, and from Patternstream 2.3 to 3.0) a strange thing started happening. Where our templates specified Futura Std Medium fonts, Futura Standard Book was somehow being used as a substitution. This only happened with the output of the Patternstream automation, which doesn't (in our case) do any font manipulation. I.e., once the document is produced via Patternstream it is easy to replace the errant Futura Book occurrences with Futura Std Medium manually in Frame, so it's not like the fonts are somehow unavailable on the machine. Any thoughts on where to begin?
Thanks in advance!
First, I'm kind of amazed that you would use Windows Server to put FM12 on - I didn't think that was a supported o/s. I hope you're not running multi sessions of FM12 on that server because I suspect that violates the licensing terms (there's a specific FM Server product for running automatic sessions).
I'm not clear where you think the font problem is happening because I don't understand your workflow (not being a Patternstream client). Maybe you can explain that - also not clear if you are using Structured or Unstructured FM.
Thanks Jeff. We do have multiple session going with FM 12, but on the same box we have a copy of FMPS 12 sitting idle for the exclusive purpose of being in compliance from a licensing perspective. We found that FMPS 12 didn't come close to meeting our requirements from a functionality (or reliability) perspective. Your point regarding the OS is well taken, although I would like to assume that if the OS was a problem that it would have been caught in the install process. Other than potentially the issue at hand, we've had no apparent OS issues to date.
Here's our process in a nutshell. We have a .bat file that polls a Sybase database for waiting jobs (reports) and fires up Framemaker (unstructured) via an executable that loads the patternstream plugin at startup if a job is pending. Patternstream knows what templates are associated with what reports and cranks through various elements of publishing logic (not to explicitly include fonts - those are designated in the Frame template) driven mostly by parameters in the database associated with the specific report. In the end either a .fm or .pdf file are produced, depending on what was specified in the patternstream script for that report.
We can see that templates are not being ignored since everything but the font designation in question is being honored in the output.
So again, fonts are specified exclusively in the Frame templates being used and aren't (intentionally) touched by any part of our automation process.
Believe it or not, the predecessor to this process (where there were no font issues) ran on Windows 98. I'm thinking a good exercise might be to run the whole thing on Windows 7 or 10 environment, but I'm hoping for a silver bullet in the meantime given that constructing such an environment would be a pretty brutal process (albeit maybe necessary in the end.)
Thanks in advance for any ideas!
I'm assuming that you've checked all of the existing templates in the current version of FM that you're using? Templates from FM7 versions are quite old and probably pre-date the avaiability of OTF fonts. FM may be trying to make a best match on some older fonts.
I had a similar issue using Miramo, when I updated from a version 6 FM configuration to a more contemporary version. FM was making some odd substitutions. Careful analysis of the MIF file, along with using Silicon Prairie's Paragraph and Character Tools helped track down all instances of the substitutions. Once the templates were properly updated, the process ran smoothly again.
That sounds promising, I'll check it out. I don't think any particular care was taken when the templates were updated to FM12. I'll report back - thanks!