10
Replies
Hi Scott,
I'll hit your points paragraph-by-paragraph and in order.
I must say that I'm really not all that versed in the options for publishing from FM using default FM-DITA, since my focus is on DITA-FMx .. but I'd expect that this should work. The main problem that I'm aware of is that you get nested FM files instead of one FM file per "chapter". I suppose that could have something to do with the titles all being at the same level, since the EDD on;y knows about the titles in each file .. ??
Indeed, our department uses "vanilla" FrameMaker 10 structured applications. For those reading this thread in the future, what I mean is we use FrameMaker's DITA 1.2 implementation straight out-of-the-box without any modifications. Scott, in FrameMaker 10, there are theoretically more methods for creating a DITA-sourced FrameMaker book file than in previous versions of FrameMaker.
One way is to save the DITA map (whether the map is "plain" or a specialized version like Bookmap is irrelevant) as a "Book with FM Components" using File > Save As > Book 10.0 with fm components. This method saves out copies of all the DITA files in the DITA map (either .xml or .dita extensions) to FM binary files (.fm) and retains the hierarchical structure of the topics by placing them in a .book. Just of note: this method adds those new .fm files to your hard disk; the DITA source content is not overwritten, just saved out in a different format. Ultimately, you've created a genuine .book file and automatically populated it with new FrameMaker files. On the surface, this may sound like a good thing. But if your "big map" contains "smaller" maps (those we consider chapters), each of those becomes an independent .book file as well, and all of its topics are saved out to .fm copies. What you get is hundreds of FrameMaker files, and dozens of .books; this is by virtue because we use distinct, modular topic files and not composite ditabase files. This can't be the the recommended workflow, can it? Even when I do it this way, I still experience slight issues with nesting titles. I have to manually nudge files in the book because, for whatever reason, Also, I understand this was the only way in FrameMaker 9 to accomplish the PDF workflow (correct me if I'm wrong). This is likely the method you're accustomed to seeing, Scott.
In FrameMaker 10, their is another method: you can add DITA files or DITA maps to a .book file. You can feasibly make your books with unstructured or structured front matter (non-DITA), place some chapter'esque DITA maps in the middle, maybe throw in some straight-up .xml or .dita files here and there, and conclude with unstructured back matter. The workflow should feel natural; the book doesn't care what's inside. This is the way I want to do things. And, to an extent, it works as advertised. For example, when you update your book, it successfully navigates/scans all the topic files inside each DITA map just fine. FrameMaker recognizes that I'm interested in what the DITA maps contain, rather than the DITA maps themselves—a good thing.
Under this method, I can still perform all the necessary operations like numbering and pagination just fine. I can even create an index and table of contents that picks up all the pieces it needs. However, the symptom to my <title> elements not nesting issue can be seen super-clearly when you look at the generated ToC (a regular .fm file). All of those topics, which were picked up just fine, are all flat. Meaning, all of the entries are given the FrameMaker paragraph style of title.0TOC if I build my ToC from paragraph styles (title.0TOC, title1.TOC, and so on). If I build the ToC from DITA elements, I experience the same thing except all of the entries are title(LevelTop)TOC instead of title(LevelTop)TOC, title(Level1)TOC, title(Level2)TOC, etc. But remember, this is a symptom of the problem—not the problem. Somewhere in FrameMaker (under my workflow), it doesn't realize that (in a DITA map) if Topic A is a parent topic and I add Topic B as a child topic, that I want to Topic B (the child topic) to have a second-level heading. Everything remains a top level heading if I'm working in a book file with DITA source content.
If I try printing a book file containing DITA maps, all the titles have top-level headings. The kicker is, if I stay in a rigid DITA map—away from most of the hybrid-ness of FrameMaker book files—and print directly from a DITA map, things work well and the topics nest as you'd expect! But I can't have that; we absolutely need to generate a table of contents and index...and to do that, I need the hybrid FrameMaker book workflow.
One, clarification .. you say you have .. "chapters in submaps (one per)" .. does that mean one DITA file per submap? Are you using nested topics or separate topic files arranged into a "chapter" using topicrefs in your submap? If you were using nested topics (in one file), then I'd be very surprised if the titles don't get formatted properly. You could try that, but it's really a bit of a hack, since it's best to have separate topic files.
Each submap is a chapter. So, one chapter per submap. To further clarify, we have one "big map" per manual, and this big map represents a logical book. Inside the "book" are submaps, and each submap represents a chapter in our book. Clear as mud, yes? 
We are not nesting topics (tasks, concepts, references) inside a composite file known as a ditabase structure. Instead, we have separate topic files (tasks, concepts, references) arranged into a "chapter" using topicrefs in a submap. So we're following best practices, as it were. As a weird hunch, I have a striking suspicion that FrameMaker 10 might play nicer with composite (ditabase) files, but that workflow is just an awful way to kill some benefits of DITA. But moving on...
I believe you contacted me about DITA-FMx 2.0 (support for DITA 1.2) .. so I'm assuming you're using DITA 1.2? Are you really using DITA 1.2 features or have you just been using the DITA 1.2 apps in FM10? If you're not using the 1.2 features, you could use DITA-FMx, and you'd have great control over the formatting in your books. (Just an idea.)
Yes I did. We are using FrameMaker's DITA 1.2 structured applications. The only DITA 1.2 features we're currently, absolutely using (meaning, they exist today in our written XML) are the niceties actually pushed onto us by virtue of using FrameMaker's applications. For example, FrameMaker's structured applications will create <navtitle> elements for topicrefs. I believe in DITA 1.1 a <topichead> element was required, and inside that <topichead> the @navtitle attribute had to be set to accomplish the same thing. Those are the kinds of things we'd have to revisit/fix if we downgraded to DITA 1.1. However, much more importantly, we plan to extensively and thoroughly use the Learning modules provided in DITA 1.2. We're not at the point where we can create content with the Learning modules (and nothing is written yet), but it is of absolute importance that we have those modules when the time comes. And if we can figure out my little mess here, we'd be able to move forward and focus on the Learning modules. For that reason, we're going to begin toying with the Learning modules shortly after we can produce print documentation—and this issue of ours is holding back a lot of potential development time with them.
Hopefully someone with more experience with using default FM-DITA to build books can comment on your situation .. I do think it should work though.
I sincerely wish there was Adobe documentation for this exact purpose. Unfortunately, they have nothing sufficient for FrameMaker 10 at this time (and I doubt it's being created).
So what now? Any advice, Scott? Anyone else? Bueller? Bueller?
-Sean
Message was edited by: NetInstSean "Typo! Where's the spell-check button anyways? 🙂 Oh there it is! Got it."
AdChoices