Flare allows people to create content once, and then use it for multiple outputs, like websites (XHMTL), PDF files, Word documents, EPUB files (electronic books), or CHM help content. It is considered a form of content management. This means writers can use their content more than one time in more than one media format. Why would your developers care how many files are in the help?įor them, it's pretty easy - they just need to link to your main help file and include the cshid.The key concept behind MadCap Flare software is single-source publishing.
Then your output will not include any skin elements, it will only include what you have in your topic or master page. I would definitely suggest using two separate targets.įor your field-level help, create a HTML5 target, and set the Skin to (none). I've reported this too, and I'm pretty sure it hasn't been fixed (I wouldn't really bet on it being fixed either, as it's been broken since HTML5 first appeared, and would only be for tripane and not top nav skins). I could create a separate help target, skin, and TOC as suggested previously, but the development team is already complaining about how many files there are in the help, so I doubt two help systems will go down well. I just discovered that our UX team wants our page-level CSH help to be stripped of header and TOC. Have you heard anything back from Madcap on this HTML5 issue? I don't think there is a way I can check on the status of a bug submitted by somebody else. Rhetoric101 wrote:As far as shutting off the header in HTML5, I ran into a bug in Flare (#55794) where you can't have multiple skins for HTML5.
rhetoric101 Propeller Head Posts: 74 Joined: Mon 4:56 pm I suppose I could create an entirely separate project for my field-level Help that does not have a TOC, and it would not get polluted by my main Help topics. Maybe this is going to turn into a challenge to maintain, keeping both the alias file and the TOC in sync, but if I want to keep my main Help files out of the field-level help, I think I need to use the TOC. I might add that I like the idea of using a field-level TOC as another way to keep track of where the topics are embedded in the application. This gives you a build of field-level Help without the extra files from your main Help. If you have two targets, one for your main Help and one for field-level Help, you can avoid duplicating all your main Help topics over in the field-level structure by using Nita Beck's trick of inserting all your field-level topics in a field-level TOC and then selecting "Exclude content not linked directly or indirectly from the target" in the Advanced tab of the field-level target. The only way I've been able to get around that is to take Dave Lee's suggestion and make two targets (see "Field-Level Help Inserting Logo From Target Skin"), although I'm not sure if I could use the cool trick mentioned above about keeping breadcrumbs. Our main project is in HTML5, so I thought I could keep the field-level context sensitive help in HTML5, too, but Flare won't apply my field-level skin that dumps the header. As far as shutting off the header in HTML5, I ran into a bug in Flare (#55794) where you can't have multiple skins for HTML5.
0 kommentar(er)
