page break?

[alaltenburg]

Is anyone else having issues with Flare 5 as far as the page breaking in PDF output?

I double checked to make sure the stylesheet was set for print medium and page break: avoid, and yet it is still page breaking.

example.png

Andrea

[forfear]

Is anyone else having issues with Flare 5 as far as the page breaking in PDF output?

I double checked to make sure the stylesheet was set for print medium and page break: avoid, and yet it is still page breaking.

example.png

Andrea

If you're referring to the caption breaking to the next page, have you tried

setting page break for inside the para (caption)
to avoid?

68 Capture.png

[RiverMonster]

Yes, I have the same issue and checked the same things. My figure captions are appearing on the page following the figure in many cases.

[forfear]

this is not a solution but in some instances it might work.

Try DIV (grouping the picture and figure caption tags together)
And in the style sheet set DIV's to avoid page-break inside.

See if that gives you better results.

Its not a 100% but sometimes it helps to give slightly better control over column/page breaks...haven't seen columns in user manuals in a while. but they look great!

[gwadmin]

I'm having this problem in PDF output now; not with images, but with a class of h1 -- page-break-before is set to always for print medium, but headings are still starting midway on the page.

[LTinker68]

I'm having this problem in PDF output now; not with images, but with a class of h1 -- page-break-before is set to always for print medium, but headings are still starting midway on the page.

That sounds like the margin-top or padding-top for that h1 class in the print output is set to a really large value.

[gwadmin]

my bad; TOC levels were bumping an h2.permissioned to an h3 where that subclass didn't exist; immediate fix would be to create an h3.permissioned that will take effect when bumped...

...which brings me to generic classes; I can manually go into the stylesheet and create .permissioned to (in theory) be applied to all heading levels, but not that a generic class would work if h1.permissioned needs color/size changed and h2.permissioned needs only color ... presuming it wouldn't and that I'd need to create h1.permissioned and h2.permissioned instead of just .permissioned.

I apologize if this is senseless babble...

[LTinker68]

...which brings me to generic classes; I can manually go into the stylesheet and create .permissioned to (in theory) be applied to all heading levels, but not that a generic class would work if h1.permissioned needs color/size changed and h2.permissioned needs only color ... presuming it wouldn't and that I'd need to create h1.permissioned and h2.permissioned instead of just .permissioned.

This is where the order of how things are listed in the stylesheet can play a part. Say you create a generic class of .permissioned that is set to a font size of 12pt and color blue. That size and color is fine for h3, h4, h5, etc., but you want h1 to be 14pt (and blue) and you want h2 to be 12pt and red. So I believe you would set up the stylesheet as follows:

Code: Select all

.permissioned {
   font-size: 12pt;
   color:#0000FF;
}
h1.permissioned {
   font-size: 14pt;
}
h2.permissions {
   color:#FF0000;
}

If my memory of how this works is correct (I just realized I've never tried this with generic classes), the .permissioned generic class will work anywhere you use it, unless it's used with an h1 tag or an h2 tag, in which case h1 inherits the color but specifies a different font size and h2 inherits the font size but changes the color. And it works that way because h1.permissioned and h2.permissioned are listed after .permissioned in the stylesheet. But like I said, I've never tried that type of override with generic classes, only custom classes of specific tags.

[gwadmin]

Thanks! Still tweaking, but on the whole it works beautifully!

[bonnie]

I have a class of p.Notes -- page-break-before set to always for my printOnly medium, which I use instead of the print medium for my PDF target. But the page-break-before property is not being applied. The paragraph behaves as if no page-break property were specified.

I've double and triple checked that this property IS set in the printOnly medium, and also that the Stylesheet Medium is set to printOnly for the target.

Has anyone else found a problem like this?

Thanks,
Bonnie

[LTinker68]

Do you also have orphan or widow values set for that class or for the main <p> tag? I'm not convinced the orphan/widow controls work in Flare, but they might take precedence over page-break settings and screw them up. If you set widow/orphan values on the main <p> tag, then make sure you set them to a value of 0 for the p.Notes class so that it doesn't inherit those values from the main <p> tag.

[bonnie]

Lisa,
Thanks for your response.
I finally figured out that I was modifying the wrong style sheet. I just now realized that the style sheet associated with the primary target determines what you see in the XML Editor. I was not working with the primary target, and didn't realize that when I edited the paragraph tags, I was not editing the style sheet associated with the target I was building. So I learned a valuable lesson today.
Thanks again for your reply.
Bonnie

[jgoldstein]

This seems to be an appropriate place to ask yet another page break question.

I'm sure I'm missing something obvious, but I can't for the life of me see it.

I want to print a PDF version of my help system (for review purposes). I'm not fussy about the formatting other than having each help topic start on a new page in the PDF output. My <h1> style is set to break in all mediums. I have a Draft target set up that I use to build the PDF file. But, I don't get any page breaks where I expect them (start of each topic).

Any suggestions about where I should look?

Thanks in advance,

[LTinker68]

Do you have more than one stylesheet in your project? If so, is your draft target pointing to the correct stylesheet, and set to use the print medium? And just to confirm, you set the page-break-before property on the h1 tag to "always"?

[jgoldstein]

I have only one stylesheet. The Draft target is pointing to the correct stylesheet. The medium is set to print. And I set the page-break-before property on the h1 tag to always.

I just tried changing all my heading styles to (<h1> - <h3>) to break. That worked for about 20 pages in the PDF output. Then, the page breaks stop working. Then I changed the <h3> back to not breaking and about 10 of the pages broke in the correct place (at the H1 level, even though h2 is still set to break). After that, no more page breaks at heading levels.

I'm gobsmacked. Or blind. Or something.

I have another project, print only - different stylesheet. And the headings break exactly where they're supposed to break.

The help system is quite basic...the fanciest thing I have are auto-expanding text boxes in about half the topics.

I have a ticket submitted with Support but haven't heard a peep from them yet.

thanks,

[LTinker68]

There are two possibilities that come to mind.

First, there could be some inline styles in your topics that are overriding the stylesheet values. Open some of the topics that aren't breaking in the Internal Text Editor and see if there are any inline styles on the h1 tags. If there are, remove them.

Second, you could have conflicts in the stylesheet. I don't think it's as likely to happen with the heading tags as with the list tags, but open the stylesheet file in the Internal Text Editor. Scroll through and make sure all of the h1 styles are grouped together. For the most part, all of the h1 styles should be together, but if you (or someone else) has manually modified the stylesheet, there could be complex selectors or even a second set of h1 styles that you're not aware of. For instance, your base h1 tag could have a page-break-before set to "always", but you could have a complex selector that specifies the behavior of the h1 tag in certain conditions and it could have page-break-before set to "avoid". If those conditions are met, then the complex selector controls the h1 tag. If the conditions aren't met, then the base h1 tag is used.

Note that you'll see all the print-related styles inside an @media print section, but the default styles could be listed before and after that print section, depending on the order in which you modified the styles in the stylesheet. So make sure you don't pull any of the print styles outside of that print media section, but within that section, make sure there aren't any complex selectors or multiple h1 style groups.

[jgoldstein]

Eureka!

Thanks, Lisa.

Turns out the <hr> following the <h1> was the culprit.

I'll go off to check the settings for the <hr> tag now.

Oy. Never occurred to me that a style following the <h1> would be an issue.

[jgoldstein]

Turns out the real culprit was the Generated TOC setting in the Target. I deselected the Use TOC depth for heading levels option and got the expected results.

I guess I really didn't understand what that setting was all about...

[LTinker68]

What it means is if you have that option enabled, then Flare goes through your topics and changes the heading tags in your topic files depending on what level in the TOC that topic is inserted. So say you have five topics (Topic 1 through Topic 5) and you put h1 tags at the top of all five topics. In the TOC structure, though, you have it set up like the following:

Code: Select all

Topic 1 (Book)
   - Topic 2
   - Topic 3
Topic 4
Topic 5

If you have "Use TOC depth for heading levels" enabled, then in the final output (not in the authoring environment), the h1 tag in Topics 2 and 3 will be changed to h2 tags because those two topics are children of Topic 1. Topics 4 and 5 will retain their h1 headings. So Topics 2 and 3 will not have a page break before them unless your h2 tag has the page-break-before set to always.

If you have "Use TOC depth for heading levels" disabled, then the heading tags stay as whatever tag you specified in the topic file itself.

The basic idea of that field in the target is you can have it disabled for online output (all h1 tags stay as h1) and have it enabled for print output (children tags are subordinate levels to parent tags).

[jgoldstein]

Thanks for the explanation. It's a lot clearer now. I suspect this will be useful feature when I reuse content from my help system to another project (different heading hierarchy).

Greatly appreciate the technical details!