Save ditamap as Book 11 with fm components

Report · Nov 26, 2013

Hello,

I have a ditamap that consists of files converted, using Mif2Go, to DITA 1.2 <concept> and <task> files. Each file is a heading from a single chapter in a manual.

The ditafm-output.ini has the following:

TemplateDir=$STRUCTDIR\xml\DITA_1.2\app\technicalContent\template
CompositeDocTemplate_1.2=ditabase.template.fm

I do not have each <concept> and <task> file wrapped in <dita>.

Questions:

Is there anyway to tell FM to use the respective template for each root-level element? I looked in the FM 11 ini Reference and it appears the answer to that is no.
If I do have to wrap the root elements in <dita>, is this considered a less than best practice?
If I do have to wrap in <dita>, does anybody know of any potential issues with a CMS or whatever?

FYI1: We need to go with DITA 1.2, because down the road we are going to use the learning modules.

FYI2: I will be using RobeHelp to to create Web Help from imported book files.

To Scott Prentice: Are you coming out with DITA-FMx for DITA 1.2 somewhere down the road?

Thanks,

Stan

Report · Nov 26, 2013

Hi Stan...

First .. I'm not at all knowlegable in the default FM11 method for generating a book from a DITA map. Since I use (and develop) DITA-FMx, I use that method which seems to provide much better results (yes, I am biased). To answer your questions ..

1) I don't know .. if that's what the docs imply, that's probably the way it is. Since you're generating chapter files (composites), you can only have one template applied to any given file, so that would seem to limit the templates to one per file, but in theory you should be able to have different templates applied to each chapter file (this is a feature that FMx offers).

2) Wrapping topics in <dita> is only needed for files that contain multiple topic types. It is not invalid to wrap a single topic in <dita>, but it's unnecessary. In general it's not a common practice, whether it's considered "less than best practice" .. probably by some.

3) Technically wrapping a topic in <dita> shouldn't cause problems for any CMS. If it does, that's a bug in the CMS .. but that said, I'm sure there are CMSes that won't like it.

Yes .. I am working on DITA-FMx 2.0 (which will support DITA 1.2), and hope to have something available in the "near" future. I do have a DITA 1.2 structure application that you can use with DITA-FMx 1.1. Note that this only supports the "models", it does not support the DITA 1.2 features (referencing features in particular). If you're interested in giving this a test drive, feel free to contact me off-list.

Cheers,

...scott

Scott Prentice

Leximation, Inc.

www.leximation.com

Report · Nov 26, 2013

Thanks Scott,

I have been using DITA-FMx for a few years. You have a reason to be biased, it's better.

I have made some progress. The ini file was set to generate a flat file. I set it to 0 to turn that off.

[BookWithFM-General]

GenerateFlatBook=0

Now, when I select File > Save Ditamap > Book 11.0 with fm components, I get a book with seperate and nested files, but they are all *.dita files. My guess is it's looking for a template called out in the ini file, and since it can't find it, it defualts to *.dita. If that is the case, I have yet to break the code, based on the poorly documented ini file. Why it can't use the template in the structapps.fm file is beyond me.

Speaking of DITA-FMx, I just got the notice the v1.1.17 is out. (I'm also running FM 7.2 & FM 9 on this machine.)

Thanks,

Stan

Report · Dec 30, 2013

Hello,

I resumed my effort to create any type of book from a ditamap. The ditamap has several task and concept dita files all nested at the chapter level. I have the following settings in the ditafm-output.ini file:

[General Options]

TemplateDir=$STRUCTDIR\xml\DITA_1.2\app\technicalContent\template

CompositeDocTemplate_1.2=ditabase.template.fm

[BookWithFM-General]

GenerateFlatBook=1

With GenerateFlatBook=1, I get a book with structured *.fm files, correctly nested. However, each file has no content, just the root dita element and nothing else.

With GenerateFlatBook=0, I get a book with unstructured *.fm files, correctly nested. Each file has content, and uses my unstructured template with paragraph and character tags from the structured template imported. What's up with that?

In each case, I get the following console error message:

Cannot Open G:\DATA\FM2DITA\Coversion_Test\template_test_01.dita#pi82LW1351424

Cannot Open G:\DATA\FM2DITA\Coversion_Test\template_test_02.dita#pi3589GH79323

Cannot Open G:\DATA\FM2DITA\Coversion_Test\template_test_03.dita#pi82J135SKS1424

Cannot Open G:\DATA\FM2DITA\Coversion_Test\template_test_04.dita#pi8GMS21351424

Cannot Open G:\DATA\FM2DITA\Coversion_Test\template_test_05.dita#pi8JS21351424343

Cannot Open G:\DATA\FM2DITA\Coversion_Test\template_test_06.dita#pi82TW13G51424

Cannot Open G:\DATA\FM2DITA\Coversion_Test\template_test_07.dita#pi821351424

Cannot Open G:\DATA\FM2DITA\Coversion_Test\template_test_08.dita#pi8RR21P351424

I have no idea why I get these error messages. The files are fine and will open outside if this conversion process.

I have seen Adobe's video's about out on how wonderful this feature is. One video that discusses the Save Ditamap as command does not even mention this critical but poorly documented ditafm-output.ini file.

I have even gone back to the out-of-the-box structured app and ditafm-output.ini. Still no luck.

I have spent way too many hours on this and have read everything I could find. I need to build book, if I can't do that, why do I need FM?

Stan

Report · Dec 30, 2013

HI Stan...

I can't help much with this, but I have an idea about the "Cannot Open" messages .. do the topicrefs in your map include the "#<topicid>" values? Some part of this book-build process is treating the entire @href value as the filename, rather than chopping it at the "#". The topicids shouldn't cause a problem, but they clearly are .. and they aren't likely needed since it'll probably resolve to the same thing either way. If you can locate the @href values that include these topicids, you might try removing the "#<topicid>" values and see if things work any better.

BTW .. stay tuned to the dita-fmx-users list .. expect an announcement soon. 🙂

Cheers and Happy New Year!

...scott

Report · Dec 31, 2013

Thanks Scott.

That worked. Now it's building the book. This is a significant bug. Is Adobe aware of this?

Stan

Report · Dec 31, 2013

Yeah .. definitely a significant bug. Hopefully Adobe is now aware of it.

Did you create the map in FM? It would be a worse bug if FM is creating a map with topicrefs that point to filename#topicid, but it can't work with those. This syntax is often created by other XML editors. It's really a bit redundant unless you're referncing a topic that's in a file that contains multiple topics (legal but not considered a best practice).

I'm glad that helped to get things working.

Cheers!

...scott

Report · Dec 31, 2013

Scott,

Mif2Go created the map. FM11 does not add the #<topicid>. I just double-checked.

Thanks again for your help!

Happy New Year!

Stan

Report · Dec 31, 2013

Scott,

FYI: I just added added a file to the map in Oxygen, It doesn't add #<topicid> either.

Stan

Report · Dec 31, 2013

Scott,

One more FYI. I opened the map and Oxgen and published to Webhelp. It work as it should. Oxygen has no problem with the #<topicid>.

Stan

Report · Dec 31, 2013

Yeah .. the #<topiid> is totally valid, and tools should support it fine (FMx does) .. it's just a bit of an edge case since it's really not needed in most situations, so was clearly not tested in FM11.

Nice.

...scott