Word output - Table of Contents

[Techno]

Have spent an age in Flare 10's Help - Help, please.

Page numbers in my generated TOC in Word, are in inch or so left of the right margin.

Where exactly in Flare do I control this? I've looked at p.TOC1, etc., in the Master Stylesheet I am using, but if the setting to re-position these page numbers in Print output is there, I'm not seeing an obvious term.

Any help would be very much appreciated.

[Nita Beck]

My answer won't make you happy, I'm sure. I too have never been able to find what is controlling the right margin on the TOC in Word. I'll use exactly the same stylesheet for PDF output and Word output, and the TOC will be perfect in PDF but have that darned wide right margin in the Word doc. Because I use Word only for review drafts, I've left bad-enough alone as it wasn't worth my effort to troubleshoot.

Anyone else ever lick this particular issue who can help George out?

[Techno]

Many thanks, Nita. I cannot believe this could be a bug after all this time. I have quite a few Projects which I also wish Word files created from.

If needs be, I'll have to use a support ticket, but now it seems I'm not alone. I also have an issue with language where Flare seems to think that two lines in a bulleted list are Spanish.

[dorcutt]

Okay, so it's been a while since I dealt with this, so I may be a little off. The short answer is I think this is controlled by the "mc-leader-offset" attribute of the p.TOC1, p.TOC2 styles etc. I found a value of -45pt worked pretty well for me. The issue is that this attribute is also used by the PDF output, so you can't just change the attribute in the print medium of your stylesheet.

I solved this issue by creating a separate Word stylesheet. I avoided (most of) the nightmare of maintaining a separate stylesheet by importing my normal one FIRST in the stylesheet. In this stylesheet, I only list the changes that I want to apply specifically to Word output; everything else is inherited from the imported stylesheet as usual. Because items that appear later in a CSS stylesheet have precedent over items that appeared earlier, everything works smoothly.

To solve this issue, create a new stylesheet (maybe named "WordStyles.css" or something so it's clear) and link the Word output target to this stylesheet instead of the normal one.

Use the code below as a starting point:

Code: Select all

/*
IF NEEDED, REPLACE 'styles.css' WITH THE RELATIVE PATH TO YOUR MAIN STYLESHEET 

Importing the main stylesheet automatically ensures that the main stylesheet's styling is used in all cases except where the styling
is specifically overwritten in this stylesheet. This reduces maintenance greatly.
*/

@import url('styles.css');

	p.TOC1
	{
        /*Controls how far to the right the TOC page numbering should appear*/
		mc-leader-offset: -60pt;
	}

        p.TOC2
	{
		mc-leader-offset: -45pt;
	}

	p.TOC3
	{
		mc-leader-offset: -45pt;
	}

	p.TOC4
	{
		mc-leader-offset: -45pt;
	}

	p.TOC5
	{
		mc-leader-offset: -45pt;
	}

This can be used to tweak a number of other irritating style issues that occur exclusively with Word output without messing up your PDF output. Feel free to play around.

Best of all, you only need to remember that you have a second stylehseet at all if you are changing something that you specifically overwrote in the Word stylesheet. For instance, if you increased the left margin of your TOC, you would need to remember to also tweak the mc-leader-offset in your Word stylesheet to compensate. However, if you change the colors of your H1s or something, this will automatically happen in your Word output also, even though you are technically using a separate stylesheet now.

Hope this helps.

[devans]

I also have this problem but thought it was just me and that I hadn't searched hard enough for an answer!

[dorcutt]

Yeah, this is definitely a bug I think. The PDF and Word TOCs should match. What I'm suggesting is just a workaround.

Not sure if it's ever been reported. If someone is particularly annoyed at this and feeling enterprising, feel free to submit it by all means.

[doc_guy]

Can confirm in 2019 R2 it is STILL an issue. Thanks for the suggestion.