For the time being, I'll assume that everything I'm unhappy with is my fault :-} but when I start from a FrameMaker book and generate Responsive HTML5 there are quite a few things that have me raising my eyebrows in surprise. Can someone recommend an online walkthrough/tutorial/introduction?
There's a number of older posts on the TCS integration out there on the Adobe TCS blog and with Matt Sullivan's TechCommTools blog. Have you not done this (FM to RH) in the past? Are you linking or importing your FM content? Have you tried publishing directly out of FM?
I've always wondered, which color swatch is Fiery, anyway...
Getting back to your post, though, what's your need for using RoboHelp in publishing your Fm content?
I do my online pub of Fm books via Fm directly. I don't know of any specific advantages to running it through Rh, unless you're combining the Fm content to existing Rh content.
Of course, if you're porting the content and no longer plan on editing in Fm, that would change the story, but in that case, it's only a one-off, and likely faster to just grind through the oddities than to address the inconsistencies that crop up with any conversion*
*By inconsistencies, I mean ad hoc formatting, such as "faking" a heading or numbered list without applying a style,
@Matt - the only reason I've heard of not going direct from FM is the new frameless skin that the New UI sports in its grab-bag of layouts that FM doesn't have (yet).
Which skin is that? Since my dev is usually just customization of the Charcoal, I hadn't noticed any in the current release of Rh that were not in Fm.
@Jeff – no, never tried this before; as to linking vs importing I don't actually know; yes, I'm trying to compare HTML5 from FM with HTML5 from RH … so generally coming up with too many questions at once :-}
Setup for direct Fm output v. importing/linking to Rh is about the same.
HTML from Fm and Rh are about the same
Time to update imported/linked projects in Rh is a deal breaker for me.
@Matt – the Fiery Pantone handle is so old all I can remember is there to be used some ?output component? called a Fiery :-}
As for why I'm asking about RH, a while back "my" developers and I replaced 300+ .pdf pages of documentation for a humongously complicated system/interface with WebHelp from DITA [but not FM] source: everyone's very happy with it, even to the extent where other developer teams are asking if they can have something similar. The latest request is for hardware documentation, where they've seen a layout with a graphic (or even a small animation) left and simple instructions right; so Responsive would be nice. I've more or less caught up with the idea that HTML5 could be a replacement for WebHelp, so I've been looking at both FM2019 and RH.
I think the interfaces of both RH and RH Classic would quickly drive me to drink and despair, so I'll take your advice and concentrate on FM. And start asking more precise questions.
Wow, I'd forgotten all about Fiery!! That was a software RIP (raster image processor) if I remember correctly from my prepress days.
Given the DITA component, I'd almost certainly go with direct from Fm output, unless Rh ever evolves to edit and produce (not just accept) DITA content.
What was the DITA solution for producing content?
Your situation sounds much like when I used to get contracted to install structured Fm for aerospace so they could have a reliable, cost-effective output solution for their ArborText systems. Crazy to imagine, but it was cheaper than developing and maintaining the structures needed to produce PDF from ArborText.
> I'd almost certainly go with direct from FM output
Ah. I've been (happily) writing DITA for a few years now, and every now and then I'll take another look at FM: most recently earlier this year, when I finally managed to get FM2019 installed and running. Simply put, FM doesn't like my valid DITA files and I don't like FM's default .pdf output :-} not keen on the FM-for-DITA user experience, either … so while the last two points are relatively subjective, taking the three together I'll be sticking with XML Mind for the foreseeable future: nimble and discreetly powerful.
In the meantime, I'll carry on experimenting with non-structured FM and HTML5 output; so you'll be seeing questions from me in the FM forum.