Best/Normal practice for PDF outputs

[StraygoatWriting]

I'm working on PDF outputs for the first time since 2010. Back then, to make high quality PDFs, we used to create two versions of each heading - one with a forced page break before, one without. We'd do the same for several other styles too. The idea being that you'd let Flare generate the PDF as best as possible, then go through, identify any sections that would be better with breaks and then go back and change the style. As far as I can tell, that's still probably the best way of going about it - there's still some human interaction required.

Is that the way other people work? Or do you just accept some compromises with page breaks in Flare?

[Msquared]

I've had no problems with leaving Flare to decide where to put the page breaks in PDFs. I do have "page-break-after: avoid" set for my heading styles.

But, and this is a big but - I do see problems if the content has drop-down headings and bodies. I do this in places because I single source PDF and WebHelp. The content in the drop-down bodies (usually paragraph text) seems to stick together more closely than the heading sticks to the first paragraph of the body. So sometimes you get stray headings at the bottom of the page. I also used to get whole chunks of text moving to a new page when there was plenty of room for a few more paragraphs on the old page - that seems to happen only rarely now - I'm not quite sure what I changed.

I've tried setting "page-break-after: avoid !important;" but Flare ignores the directive and still prefers to keep the drop-down body together where possible.

I have raised a bug against this. I think it's a shame, as being able to single source good-quality WebHelp with drop-downs and PDFs from the same content would be lovely!

[StraygoatWriting]

I'm mostly against drop-downs as a feature to be honest. I don't like 'hidden' content and avoid it where possible. However, I appreciate it can be useful in certain situations. The problem you describe with it sounds pretty poor - it sounds as if you need to use conditions to hide the drop down in PDF and to add the drop-down text as normal text with a PDF only condition. Hardly an elegant solution.

[ChoccieMuffin]

StrayGoatWriting, I try to get my styles as tight as possible so that the attempt Flare makes is reasonable, and most of the time it's perfectly ok for what I want. This includes setting some generic .PageBreakBefore and .KeepWithNext classes that I use when I have to with , after looking at the output. This is preferable to having to create H1.PageBreakBefore, H2.PageBreakBefore etc and keeps your stylesheet smaller. For example, the paragraph that introduces a screenshot I format as p.KeepWithNext so that I don't end up with an orphaned screenshot at the top of a page. If I have a H2, followed by a p.KeepWithNext, followed with a p.Image, the H2 gets pulled onto the next page if it has page-break-after set to avoid.

When necessary, if I still don't like the final outcome, I apply .PageBreakBefore to the heading that isn't quite in the right place. But I do this very sparingly.

[StraygoatWriting]

Thanks. For me, the headings are not so much of an issue as they are easier to manage. It is more the breaks between normal paragraphs. I know I can use widow/orphan to sort some of this out, but sometimes it just looks better with the content moved forward or back to another page. For those, I guess the multiple p.styles is the best way to handle it?

[ChoccieMuffin]

No, I disagree. Don't go making a specific p.KeepWithNext, just create your generic .KeepWithNext which you can then apply to whatever kind of tag needs it. (For example, if you don't have any kind of page-break-before , page-break-after or page-break-inside setting defined for lists and list items, you can apply these as you need them) This means you don't have to define several new styles such as li.KeepWithNext, p.KeepWithNext, etc.

The generics I have (and use as sparingly as I can get away with) are shown below. If your basic stylesheet doesn't have any styles that these generics overturn, then obviously you don't need to define the overturners, for example .AllowBreakInside could be applied to something like a ul or ol if you have defined the defaults for lists as "page-break-inside:avoid", but if none of your styles have "page-break-inside:avoid" as part of the definition then you will have no use for this generic.

Code: Select all

	.KeepWithNext
	{
		page-break-after: avoid;
		page-break-before: auto;
		page-break-inside: auto;
		column-break-after: auto;
	}

	.KeepWithPrevious
	{
		page-break-inside: auto;
		column-break-after: auto;
		page-break-after: auto;
		page-break-before: avoid;
	}

	.KeepTogether
	{
		page-break-inside: avoid;
		page-break-before: auto;
		page-break-after: auto;
		column-break-after: avoid;
	}

	.PageBreakBefore
	{
		page-break-before: always;
		column-break-after: auto;
		page-break-after: auto;
		page-break-inside: auto;
	}

	.AllowBreakInside
	{
		page-break-inside: auto;
		page-break-before: auto;
		page-break-after: auto;
		column-break-after: auto;
	}

[StraygoatWriting]

Sorry, that was my mistake. I would only do it as you have described too - with no specific class defined. Thanks for pointing it out though, as others might not be aware of that.