MadCap Software Forums

Hi guys,

I'm a writer for a boat manufacturer. I produce a set of manuals that are generated from a single TOC with multiple conditions. Currently my only output is to PDF which is configured to be a balance between number of printed pages (currently around 300) and readability. Manuals are printed on a plastic paper for durability at sea, as well as supplied on a memory stick for viewing on computer. I recently discovered that I can upload the PDF manual to the boat's chartplotter(s), making for easy access and reference direct from all helm positions.

However, the current format for print doesn't work well on screen. The print fonts are too small and the layout doesn't scale well on the screens which can vary from 10" to 24". With electronic delivery having no page count restriction I'm free to change the formatting to optimise the online experience. However, Flare ties page layouts to the TOC and I can't see a way to output to a different set of page layouts without duplicating the TOC, and in so doing increase difficulties in maintenance and keeping the copies in sync. Currently the only way I see to manage a dual PDF output is to script a solution that before each build copies the TOC, changes page layout references in the TOC entries and builds the document. All of which I'm comfortable doing as I already script a lot of manual construction from multiple sources. Is there an easier way to do this in Flare that I'm blind to?

For example, my print version uses a landscape 3 col format. My online version I'd keep in landscape but switch to bigger fonts (easy with a stylesheet media) and two columns, with a static menu bar down the left side for easy navigation on the screen.

Any ideas?

Cheers,

Rob

If you can define a single page layout for each output, you can define the page layouts in the targets and avoid specifying them in the TOC entirely.
If you need different page layouts for different sections of the document, maybe you can just duplicate those entries, and use conditions to put the right things in each output.
It's also possible each print target's TOC can be a shell that just includes the entries where page layouts change, and the other entries are imported by referencing other "real" TOCs which will be the ones you normally modify while changing content. This may be more fiddly (as you will have separate TOCs for each section that needs different page layouts - hopefully not too many!) but address the maintenance and in-sync issues.

devjoe wrote:If you can define a single page layout for each output, you can define the page layouts in the targets and avoid specifying them in the TOC entirely.
If you need different page layouts for different sections of the document, maybe you can just duplicate those entries, and use conditions to put the right things in each output.
It's also possible each print target's TOC can be a shell that just includes the entries where page layouts change, and the other entries are imported by referencing other "real" TOCs which will be the ones you normally modify while changing content. This may be more fiddly (as you will have separate TOCs for each section that needs different page layouts - hopefully not too many!) but address the maintenance and in-sync issues.

Thanks for the ideas. I had wondered if there was a way of importing the TOC and adjusting it. Sadly I've multiple page layouts throughout the book which in retrospect may have been a short term and painful solution to undo. Though I'm prepared to tackle it if there are neater solutions for what I'm trying to do. My current system definitely tries too much to control appearance through layouts making it less flexible for multi-platform delivery. As it stands making a script to change paths for layouts in the TOC and resaving it as a new one seems the simplest way without reformatting and styling the whole document. I'll have a play with trying to embed some of the features of my layouts into the content to reduce the quantity of layouts I'm using.

Cheers,
Rob

I've run into a similar issue when building the same manuals for four different companies, each of whom want their own special layouts (*sighs deeply*). However, there is a way around it. You need to have one page layout per output type, which you can assign to the target for that output. When you assign page layout/chapter breaks in the TOC, leave the Page Layout set to default and choose the page type you want. This essentially allows the target to choose which page layout it will use for the output rather than the TOC.

The caveats: each page layout needs to have exactly the same page types, and no more than one of each - because when you don't select a page layout, you just get the basic list (e.g. normal, title etc).
And you need to be prepared to have the page layout breaks fall at the same topics for each output - because there's only the one TOC determining where the breaks will be.

This might not work for you, but it's usually fine for me unless Marketing gets too fancy with their document designs.

doloremipsum wrote: The caveats: each page layout needs to have exactly the same page types, and no more than one of each - because when you don't select a page layout, you just get the basic list (e.g. normal, title etc).
And you need to be prepared to have the page layout breaks fall at the same topics for each output - because there's only the one TOC determining where the breaks will be.
This might not work for you, but it's usually fine for me unless Marketing gets too fancy with their document designs.

Sighs... yep, you've got my problem nailed. Well partly marketing and partly my own grand designs. I have multiple page layouts, several for each section of the document. I originally had a single page layout and thought I could get by with specific page definitions for each configuration of it (1 col, 2 cols, 3 cols, etc), but it grew more complicated to do that than have a single layout per option.

Does the on-boat one have to be a PDF? Or could it be a type of output that gets its layout from a master page, which can be applied via the topic properties?

No, all has to be PDF. At least for now. I don't have access to upload an HTML-type output to the chartplotter. They're accepting only PDFs currently.

Cheers,
Rob