After cleaning up plenty of user errors I now have the final (?) task at hand: making the bookmark/navigation/ToC pane of the PDF look like the ToC that I specified in Flare. I took a look through the help file, but there it appears as that the focus is on how to make a printed ToC look right that gets printed in the front of the book.
Here is what my ToC in Flare looks like
Topic 1
Topic 2
Book A
___Topic 3
___Topic 4
Book B
___Topic 5
___Topic 6
When looking at the navigation pane in the PDF viewer it looks like this:
Topic 1
Topic 2
Book A
___Heading Level 2
___Heading Level 2
Topic 3
___Heading Level 2
___Heading Level 2
Topic 4
___Heading Level 2
___Heading Level 2
Book B
Topic 5
___Heading Level 2
Topic 6
___Heading Level 2
I do not mind the extra heading based links in the ToC, but I want the topics that are inside of books to be on the second level. I already checked the mc-heading-level property for the styles and those are correct. *sigh* WebHelp is so much easier......
In your PDF target, on the Advanced tab, have you selected the "Inject headings for unlinked books" option, assuming that your "book" TOC items are not linked to any topics? That would make a first level heading for the books, and then the topics within those books will all "nudge over" one heading level, per how they are organized in the TOC.
Nita
RETIRED, but still fond of all the Flare friends I've made. See you around now and then!
Making the print TOC (TOC proxy or PDF TOC) look the same as your Flare TOC isn't actually simple.
The print TOC(s) are based entirely on the styles you've set to have the mc-heading-level property; i.e. you can't actually base it on a Flare TOC file structure (which I think is crazy).
Anyway, to work it out; it'd be easier to know what styles you've set with mc-heading-level property, and also whether or not you're using Use TOC depth for heading levels in the target.
I do not use the ToC depth for heading levels because that switched the heading styles on me (by design). After turning that option off a lot of other issues such as heading styles not being correct and not getting the page break before.
I understand that the bookmark/navigation pane in the PDF is based on the mc-heading-level property, which I could change, but I find that to be unintuitive, complicated, cumbersome, and plain wrong. Flare has a nice ToC editor that makes pushing links around a breeze. Why would anyone want to fork around in the guts of the CSS for this? Based on the reply from support it is a common complaint and one that is scheduled to get fixed sooner rather than later.
For a printed table of contents the mc-heading-level property may come in handy and I see the connection between changing a style and the look of the output. In regards to pure navigation I don't see why the CSS should get involved. It doesn't in WebHelp or CHM, so why for PDF?
RamonS wrote:I understand that the bookmark/navigation pane in the PDF is based on the mc-heading-level property, which I could change, but I find that to be unintuitive, complicated, cumbersome, and plain wrong. Flare has a nice ToC editor that makes pushing links around a breeze. Why would anyone want to fork around in the guts of the CSS for this?
My thoughts exactly, I put in a request to improve this ages ago.
You go to the effort of creating a TOC for your project, then you can't use it whatsoever to generate the contents proxy or PDF contents.
I've no idea why your print TOCs have to be based on heading levels/CSS at all; that's how you'd do it in a print-only tool, because in those tools you don't have a TOC designer in the tool itself. In Flare, where you can design your TOC, it just makes no sense at all.
Maybe Blaze doesn't have a ToC designer? That is the only reason I can come up with why anyone at MadCap would go with this rather dumb way of implementation.
In my case, I quite like the mc-heading-level because the way I produce content for the web is different from how I produce content for print.
On the web, every topic title is at the same heading level, H1.
In print, some of my topics are unit titles, some are chapter titles, and some are just topic titles. I am able to use classes of H1 to style these differently, depending on their class. Then I use mc-heading-level to represent these differences in hierarchy so the PDF builds the TOC properly.
Now, I'm not saying that the style sheet is the best place to be setting this, but I do see a need to have the option there, and it is something that I use for almost every project I work on. I don't want it to just be based on the structure I create in the TOC editor, because that structure doesn't necessarily know how I want to describe each branch. Is a book a chapter, or is a book a unit? I need to be able to control that at some level.
Yeah, I understand that you need different visual styles for your section headings; I do too for chapter headings.
However, doesn't your TOC file mirror what you also want to display in the print TOC though? (just maybe with fewer levels)
What I don't get, is why any of this needs to be driven by styles when you have a TOC editor.
Even if you're only producing a print target, you still need to create a TOC file, to select and order the topics in your print target.
So, since you've already created your TOC, why can't you use it as basis for your contents page or PDF bookmarks?
You're talking about the styles for the generated TOC, right, not the corresponding headings in the topics themselves?
So with your method, how would you specify what a top level (TOC1) entry looks like as opposed to a second level (TOC2) or third level (TOC3), etc.? If I want my top levels to be flush to the left margin, font size 12pt, bold, with 6pt above and below, and I want second levels to be indented .5 inches, font size 10pt, 4pt above and below... Where would those settings be specified if you weren't using a stylesheet to control them?
Even with WebHelp output we complain because we don't have enough control over those styles except for the few options available in the skin. I think if we're going to have p.TOC1, p.TOC2, etc., then those should also be applicable to the TOC pane in the WebHelp output, in addition to the generated TOC in print output, so p.TOC1 in the default medium could be styled differently than p.TOC1 in the print medium, but both of them do the same thing -- control the appearance of the generated TOC.
Lisa Eagles may soar, but weasels aren't sucked into jet engines. Warning! Loose nut behind the keyboard.
I'm talking exclusively about the navigation aka bookmark pane in the PDF Viewer. I am not talking about the ToC that gets printed on paper between title page and first chapter. THAT ToC should be styleable to the n-th degree, but not have any impact on how the navigation pane works.
I attached a screen shot, all entries are on the same level and that is not how I made it to look like in the ToC editor. All I want is this bookmarks panel to follow the leveling and depth specified in the ToC editor and that regardless of what heading styles are used anywhere. As it is right now, can't do that in Flare. For example, all the Prerequisite topics for the different Windows versions should be one level under the main Prerequisites entry, just the way I set it up in the ToC editor.
You do not have the required permissions to view the files attached to this post.
LTinker68 wrote:You're talking about the styles for the generated TOC, right, not the corresponding headings in the topics themselves?
No, none of this is about formatting the appearance of the print TOC; it's about controlling what's included in the print TOC, and that the items in your print TOC are completely unrelated to your TOC file ; which makes no sense.
RamonS wrote:I'm talking exclusively about the navigation aka bookmark pane in the PDF Viewer. I am not talking about the ToC that gets printed on paper between title page and first chapter.
You can consider them as the same thing. The structure of the PDF bookmark pane and contents proxy (if you had one) are the same; they're generated in the same way (from mc-heading-level).
I think I found a solution to this. We also want to use our TOC as the way the PDF bookmark pane should look, but the way Flare generates bookmarks from the various headings complicated it for us. We created p.Subhead styles to prevent our subheadings from being added to the PDF bookmarks, but the subheading formatting was generated as designed not as the heading level structure.
This is what I came up with (after getting the idea from Kip in tech support). In my CSS, I created heading styles exactly the way I want them for online (non-print) use--I have h1, h2, h3, h4. Because we use only the h1 heading style to be the TOC entries, I named all the subheadings h2.NotInTOC, h3.NotInToc, h4.NotInToc.
Then I copied them and pasted them in the @media print section of the CSS file. There, I edited them for PDF output and added mc-heading-level: 0; to prevent the subheadings from showing up in the PDF bookmark pane.
Now I can build my Master TOC for online projects and use the same structure for my PDF TOC. When I generate the PDF, the bookmarks look exactly like my TOC and all my headings are resized according to their hierarchy levels.
Even though I have to retag all my subheadings--I'm so happy!
