Conflict: mc-heading-level vs. Use TOC depth
Conflict: mc-heading-level vs. Use TOC depth
I’m having a problem with formatting my headings. I have two goals: (a) remove some headings from the printed TOC and (b) have *all* headings inherit their heading level from their TOC placement (even if they’re not actually visible in the printed TOC).
Within each topic my main header is an <h1> and I use <h2> and <h3> for lower-level headings. I have a class called NotInContents that sets the mc-heading-level to 0. To remove a topic from the TOC, I add class=â€NotInContents†to the h2 or h3 tag. That works as expected.
.NotInContents
{
mc-heading-level: 0;
}
However, for any header with a class="NotInContents", Flare no longer adjusts the h1-h3 heading level when generating the PDF file. This seems like a silly limitation but I can't think of a workaround. Any ideas? I'm using Flare 6.1.0.
Within each topic my main header is an <h1> and I use <h2> and <h3> for lower-level headings. I have a class called NotInContents that sets the mc-heading-level to 0. To remove a topic from the TOC, I add class=â€NotInContents†to the h2 or h3 tag. That works as expected.
.NotInContents
{
mc-heading-level: 0;
}
However, for any header with a class="NotInContents", Flare no longer adjusts the h1-h3 heading level when generating the PDF file. This seems like a silly limitation but I can't think of a workaround. Any ideas? I'm using Flare 6.1.0.
-
- Sr. Propeller Head
- Posts: 168
- Joined: Thu Jan 31, 2008 12:21 pm
- Location: Durham, NC
Re: Conflict: mc-heading-level vs. Use TOC depth
The headings you don't want in the TOC--are they shown in the body of the printed document? That is, are you just excluding them from the TOC or from the whole printed doc?
If you're excluding them altogether, you can use a condition to exclude those headings from the print version while letting Flare format the rest per the TOC placement.
If you're excluding them altogether, you can use a condition to exclude those headings from the print version while letting Flare format the rest per the TOC placement.
Re: Conflict: mc-heading-level vs. Use TOC depth
The headings are shown in the body of the document. Condition tags won't work for this.
Any other ideas?
Any other ideas?
Re: Conflict: mc-heading-level vs. Use TOC depth
Unfortunately, it won't work the way you want it to.
The Use TOC depth setting will modify styles according to their mc-heading-level property; so if that is set to 0, then the style won't be modified.
Are you trying to produce a print TOC that only includes the topic h1 headings, and none of the topic sub-headings? (i.e. so your print TOC will look the same as your TOC file)
The Use TOC depth setting will modify styles according to their mc-heading-level property; so if that is set to 0, then the style won't be modified.
Are you trying to produce a print TOC that only includes the topic h1 headings, and none of the topic sub-headings? (i.e. so your print TOC will look the same as your TOC file)
Re: Conflict: mc-heading-level vs. Use TOC depth
Maybe it's just my DITA experience talking, but I think it would help to understand why you don't want these particular headings in the TOC, when you want other h2s and h3s in the TOC. If these headings all have something in common, then maybe you should define another style for them, one that is excluded from the TOC.
Re: Conflict: mc-heading-level vs. Use TOC depth
Dave: Ideally, I'd be able to pick and choose which headings go in. I can't easily narrow it down to H2 and up, although that is my fall-back plan. It's random stuff, like I don't want the "Parameters" headings included because there are so many of them, etc. In that vein, I have a secondary issue where I'm setting the MadCap|tocProxy mc-toc-depth to 2, but it still shows h3/h4 headings. I'll start a new thread for that problem if I go that way.
Whunter: If I create p.H2, p.H3 headings and use those to exclude them from the TOC, then they still won't get adjusted to the appropriate level during the "Use TOC depth" step. So I'm no better off than I am now. (Actually, I'm just assuming it's not smart enough to adjust p.H# settings--I haven't actually tried it.)
Whunter: If I create p.H2, p.H3 headings and use those to exclude them from the TOC, then they still won't get adjusted to the appropriate level during the "Use TOC depth" step. So I'm no better off than I am now. (Actually, I'm just assuming it's not smart enough to adjust p.H# settings--I haven't actually tried it.)
Re: Conflict: mc-heading-level vs. Use TOC depth
That's true. But sometimes I find that if I more closely examine why I want to do something, I come up with an alternative. Like, if the reason why I don't want these headings in the TOC is because they are headings for examples, then maybe I should just come up with an alternate way to style examples that can be the same anywhere, so that the TOC heading adjustment doesn't matter.
And then again, sometimes not. Just a suggestion.
And then again, sometimes not. Just a suggestion.
Re: Conflict: mc-heading-level vs. Use TOC depth
The mc-toc-depth property is only used for mini-TOCs; it has no effect on your print TOC proxy.MattAbar wrote:In that vein, I have a secondary issue where I'm setting the MadCap|tocProxy mc-toc-depth to 2, but it still shows h3/h4 headings. I'll start a new thread for that problem if I go that way.
The headings in the print TOC proxy are controlled by the mc-heading-level property; e.g. to only show h1/h2, then set it to 0 for h3 upwards.
Re: Conflict: mc-heading-level vs. Use TOC depth
Well that explains it, thanks. MadCap shouldn't be listing the property in the CSS editor if it doesn't do anything--I wasted several hours trying to figure out why it wasn't working. How do I submit a bug?Dave Lee wrote:The mc-toc-depth property is only used for mini-TOCs; it has no effect on your print TOC proxy.
I don't think I'm asking a lot to both (a) exclude things from the table of contents and (b) automatically adjust heading levels. It's silly that using one feature should prevent me from using another. This makes it impossible to single-source my help without a major change to the way I write topics. Very disappointing--I was doing this in RoboHelp without problems.
Re: Conflict: mc-heading-level vs. Use TOC depth
I'd suggest putting in a feature request.MattAbar wrote:Well that explains it--thanks. They shouldn't be listing the property in the CSS editor if it doesn't do anything. I wasted several hours trying to figure out what was going on. Does MadCap respond to feature requests? If so, what's the process?Dave Lee wrote:The mc-toc-depth property is only used for mini-TOCs; it has no effect on your print TOC proxy.
I don't think I'm asking a lot to both (a) exclude things from the table of contents and (b) automatically adjust heading levels. This is very disappointing.
https://www.madcapsoftware.com/bugs/submit.aspx
I've ranted several times about how poor and convoluted the process is for producing a print TOC; why it has to be based on styles is beyond me, when it could be based and controlled by the TOC file structure you create in the editor.
Re: Conflict: mc-heading-level vs. Use TOC depth
Well, I've just found this post after a gap of several years. It's saved me an hour or two of frustration, so thanks guys.
But now it's time for my rants.
But now it's time for my rants.
- Why doesn't mc-toc-depth work for TOCs in the same way as it works for mini-TOCs?
- If it doesn't work, why does the stylesheet editor in Flare 11 describe this property as "Specifies the depth for a printed Mini-TOC and TOC"?
- If it really doesn't work, why should I be forced to make the bookmark depth the same for the "printed" TOC and the navigable bookmarks in the PDF, which only need to be expanded as far as the user wants or needs to, so can be as high level or deep as required?
Marjorie
My goal in life is to be as good a person as my dogs already think I am.
My goal in life is to be as good a person as my dogs already think I am.