Copy link to clipboard
Copied
I'm using good OLD dzbatcher to automate FrameMaker book builds. Part of the build requires that I save a FrameMaker 8 FM file to MIF 7.0.
FrameMaker 8 provides two save-as MIF options: MIF 8.0 and MIF 7.0, where MIF 8.0 is the default.
Does anyone know how to make MIF 7.0 the save-as default? Failing that, how to remove the MIF 8.0 save-as option which I don't need).
Copy link to clipboard
Copied
I can't help you with your question, I'm afraid, but I am curious. Why do you want to save to MIF 7 if you're using FM 8? As I recall, one of the things that was new in FM 8 was the addition of unicode support, and I think you lose that if you save backwards.
Copy link to clipboard
Copied
Welcome to the rabbit hole......
Without going into brain-tumor-inducing detail, I'll just say that we have a very old propriety documentation build and delivery system. The XML generated from FM 8 and later versions contains a "bug" that Adobe refuses to address. The last "clean" XML produced by a version of FrameMaker was FM 7.
So we have to downgrade to FM 7 in order to produce usable XML. However, MIF 8.0 contains unicode characters that don't translate well in FM 7 and the resulting XML.
Copy link to clipboard
Copied
Hi gordonf44886270 ,
The XML generated from FM 8 and later versions contains a "bug" that Adobe refuses to address. The last "clean" XML produced by a version of FrameMaker was FM 7.
That's a surprising statement in many ways, but especially considering the large number of companies worldwide working very successfully with FrameMaker and XML.
Could you please let me know which bug that could be? I would love to look at it and check if it is actually still present in one of the newer versions. Also, I'd like to know who at Adobe has told you that we would "refuse" to address this bug, whatever this bug might be.
Kind regards,
Stefan Gentz
Worldwide Technical Communication Evangelist
Connect with us:
Facebook | Twitter | LinkedIn | YouTube | Our Blog | Adobe TCS User Forum
Copy link to clipboard
Copied
Hi Stefan,
Thanks for your interest. I wish I could provide more detail, but the whole system was designed and setup by my predecessor. My job is to maintain the system until I can get a more reasonable webworks-based solution in place. However, from what I understand, the XML from FM 8 introduces a font problem in our code samples. I guess I could run some experimental builds to provided more color if there was a chance we could get someone at Adobe to address the issue. Is there?
I'm certain there are a number of ways to approach the problem, such as post-processing the XML output from FM 8, but my plan is to move on to another doc build solution and put the whole mess in the rearview.
Copy link to clipboard
Copied
Ok, I did some tests and this is what I see:
Here's a screen shot of some code sample text from the FM 8 GUI. Note the hard returns (Shft-Return) at the end of each line:
XML generated from code sample in FM 8:
<Code>
<A ID="pgfId-1079399"></A>
(: Add new forests to the configuration :)let $config := admin:forest-create( $config, "SampleDB-Forest", xdmp:host(), ( ))</Code>
XML generated from code sample in FM 7:
<Code>
<A ID="pgfId-1079399"></A>
(: Add new forests to the configuration
let $config := admin:forest-create(
$config,
"SampleDB-Forest",
xdmp:host(), (
))</Code>
<Code>
Note that the hard returns (Shft-Return) are gone in the FM 8 XML output.
Copy link to clipboard
Copied
Not sure we can use your cut n' paste of the xml, as the colon/closed paren gets parsed as a smiley!!
Can you resubmit a screen shot as you did with the FM8 GUI?
However, even without seeing the actual difference in code, I'm confident that the cause lies in your structapps file, and in the definition of your structured application. The structured application tells Fm what to do with specific things, and likely the Fm 8 structured application was not ever configured to do so.
As Stefan mentioned above, many very large organizations, including tech companies like Palo Alto Networks use Fm to work with XML. They wouldn't do that if Fm was incapable of producing XML to represent code.
Also, given the HUGE improvements in structured authoring (not to mention PDF creation and 64-bit processing) since the 2001-2004 versions of FrameMaker, I'd strongly recommend moving to Fm 2019.
Copy link to clipboard
Copied
Here's the screenshot:
We are using FM in unstructured mode.
We use MIF to "downgrade" from FM 8 to FM 7, which then produces the above XML.
Copy link to clipboard
Copied
Okay, problem understood 🙂
It's not a bug in FM 8 or higher. It's just that FM8 and higher do proper whitespace handling according to the XML specification, which FM7 did not to full extend. Or, the bug is there in FM7 and lower and not in FM8 and higher 😉
That said, just add the xml:space attribute to your code element in the document (XML) and give it the value "preserve":
From:
<Code>
To:
<Code xml:space="preserve">
That will solve the problem and is actually the correct way to do it in the XML world 🙂
Cheers!
Copy link to clipboard
Copied
Hi Stefan,
Sorry for not responding earlier, but ya know....
Unfortunately, the <Code xml:space="preserve"> workaround doesn't work. After the file is saved to XML, all of the line returns are gone.
Copy link to clipboard
Copied
I'm so sorry. It sounds like one of Patrick McManus's sequential vortexes.
Good luck. Wish I could help, but the people here are great.
Copy link to clipboard
Copied
Your question is about MIF standards, but your problem seems to be with XML export.
Is there a reason you're using MIF to somehow produce your XML?