Export Change Bars (and other formats) in Structured Framemaker to XML

[bdpopp]

Anyone know if there is a way to export Change Bars and other unstructured styling to XML via processing instructions? I've set OutputAllTextWithPIs in my Application, and I see track changes annotations, but no change bar PI's. Seems like this would be essential to roundtripping, but I haven't found any way to do it. Any help is greatly appreciated!

-bpopp

[ScottPrentice · Accepted solution]

It depends on how the change bar format was applied. If via character tags, it won't export as a PI. If you use conditional tagging, and define the styling as change bar, it will. But .. PIs are best to avoid in XML .. it'll just cause bloat. Also conditional tagging PIs in FM can cause problems down the road so it's best to avoid (IMHO).

A better approach is to use attributes on elements, then have the change bars applied as formatting via EDD context rules. In DITA, there's the status attribute, which can be used for this purpose.

Remember that in XML, you want to eliminate "formatting", but rather store information as metadata (attributes) that can be applied in various ways through a publishing process (structure applications, etc.)

Cheers,

...scott

[bdpopp]

Thanks Scott. That's bad news. I understand the warnings, but I'm essentially trying to use FO to render a legacy book that has had changes extensively styled with change bars and paragraph styling. They do also set an attribute, but it would be impossible to replicate the look of the original book with this since the writer has styled individually modified words and sentences in order to show specifically what changed in a large block of text. Using the attribute, the resulting change bars would end up spanning multiple pages when only a few words might have been changed. Elements could be used to wrap the specific changes, but this would be complicated since these changes often span multiple paragraphs or even sections. Many XML editors (including FM) get around this complexity by using PI's to markup changes that may not end up being syntactically valid. Right or wrong, I don't really understand why Adobe wouldn't at least allow for something similar w/ character tags.

Regardless, I very much appreciate the information.

Brian

[ScottPrentice]

Hi Brian...

Yeah .. if you need to mark up the XML below the element level then you will need to use PIs. That is what FM (and other XML editors) use for change tracking. FM's change tracking is really just hijacked conditional tagging, and conditions are the only thing that'll round-trip as PIs. Your best bet is to create a script (ExtendScript should work) to map your character tags to conditions.

I'm confused though .. do you already have XML, or are you converting from unstructured FM to XML? If the latter, you could map the content tagged with character styles that mark changes to a special element that you then swap with PIs at some point in the conversion process. Or is it that you've got structured "binary" FM files that you're exporting to XML? And why are you using FO to render the book when you've already got the content in a tool that will produce far better output (and much easier) than FO?

You don't need to answer these questions, if you're set on your process .. just wondering!

Cheers,

...scott

[bdpopp]

Yeah, so we have structured Framemaker that we output to XML and process using XSL in order to create a couple different primarily HTML-based deliverables. As you guessed, we still currently generate the PDF using Framemaker, but I want to get away from that. I would humbly disagree with your opinion that FM is better and easier than FO. For simple books that is probably true, but our books are complex and we have to use a handful of API's in order to generate many of the FM TOC's and indexes. These compiled API's are fragile and difficult to change. Our book building process is a beast. We've  converted some of our books out of FM to DITA and that has drastically reduced our book-building overhead (to essentially nothing), but the conversion has been a fairly slow and tedious exercise. Eventually I want to get everything out of FM (commence banning in 3..2..1../grin), but as a short term step I was hoping to continue using FM for authoring, but migrate all of our publishing to XSL/FO.

I'm not at all set on the process, and do value the feedback. I do like your idea about programatically converting the character styles to conditions. I've done this kind of thing with the SDK in the past, but haven't looked at ExtendScript yet. I'll give it a shot. Thanks again for the help.

-bpopp

[ScottPrentice]

I hear what you're saying, and as long as you've got someone in-house to maintain the FO development, that can be a viable option .. but if you have to outsource that development it can cost a fortune and you'll often end up settling for less than desirable output. I'm in the camp that understands the potential move from FM to something else for authoring, but think it's still the best option for PDF publishing. That does mean that you'll need a bit of automation help in the book-build process, but a lot of that already exists (for DITA). I think that you're aware of the tool I develop called DITA-FMx. It's set up to allow "one-click" publishing from a DITA map to a FM book which is PDF-ready. That includes creation of all of the necessary generated lists, pagination, etc. I've got a number of publishing plugins that perform various book-build processing like adding mini-tocs to chapters and adding icons for notes. Once it's set up it pretty much "just works".

Of course, there are always reasons that this just won't work, and the only "right" path is the one that works for you. It sounds like you've done a lot of work on this, but I wanted to point out that there are options from what you get in default FM.

If you're going to explore ExtendScript, grab the samples from West Street Consulting ..

     http://www.weststreetconsulting.com/WSC_ExtendScriptSamples.htm

Great stuff!

Cheers,

...scott

[bdpopp]

Thanks Scott. I very much appreciate the feedback and the sample scripts will be very helpful. I completely agree, that in the end, Framemaker is a more capable PDF publishing tool. My thinking, and maybe this is flawed, is that it would be easier/cheaper to find someone that knows an open standard like XSL/FO vs. the Adobe SDK. And for two equally skilled developers, FO *should* go faster for most simple modifications. Most importantly, though, is that it will be more portable and will be easier to incorporate in a pipeline.

I don't know if you remember, but you helped me with some API work a (long) while back. Your Ask Scott service was very helpful and got me through several pinches with the SDK. We are still using that API today to build one of our books.

-bpopp

[ScottPrentice]

Hi Brian...

No, your thinking is solid, "in theory," and as long as you have an in-house FO developer, and don't require frequent modifications to the layout (and don't have lots of tables .. FO is weak on table support), it *should* be an easier path. Definitely faster and easier to hook into a scripted pipeline. The main difference being that once set up, any tweaks to the FO system will always require a developer, while tweaks to the FM system can be done by most anyone familiar with FM templates.

However, a wise person once said .. "XSL-FO is the most expensive "free" technology out there." See people lured in because of it being open source, but then ending up spending more time and money on it than if they had gone with the proprietary FM path.

Yes .. I do recall helping you out in the past .. glad that work is still in use!

Cheers,

...scott