nowrap in 2-column index for PDF target

This forum is for all Flare related Tips and Tricks.
Have a tip or trick you use while working in Flare? Share it here.
Post Reply
mattbnh
Sr. Propeller Head
Posts: 110
Joined: Tue Feb 26, 2008 12:17 pm
Location: Home: NH --- Compensated Servitude: MA
Contact:

nowrap in 2-column index for PDF target

Post by mattbnh »

This is probably too picayune to help many people, but the solution was tricky enough to find that I am posting it, just in case it helps or inspires someone to solve a glitch that is nagging them.

I post this not as if I was an authority on anything. If I am wrong or slightly misguided, I expect harsh and swift correction.

Our PDFs have a two column index.
The problem I was seeing was that long index entries would would not wrap to a second line, but would bump into the page number.
In a test I created a really long index entry (almost as long as some of the sentences I write here), and in the PDF it actual went off the right side of the page across the second column. Ouch.

Short answer: for p.index1, the Block property white-space is set to nowrap by default. Change that to normal and your really long index entries wraparound like good boys and girls.

Long answer
I did not see a css property that obviously dealt with this, nor a column property, nor a direct reference in the help. I could not find anything in the forums.

So I went to the list of css properties for p.index1 and started poking around.
I expanded Box and didn't see an obvious property for this. So I looked at Block and the fact that the property white-space had a set value caught my eye. The definition is "A value that indicates whether lines are automatically broken inside the object"
This looked like it was at least worth a shot. Setting it to default kept the nowrap value, so I tried normal, saved the css, built a sample project with a nasty long index entry, and it wrapped fairly well.

I did not try the rest of the available values, because most of them were beyond my ken, and the problem seemed solved.

I do not know why the Flare default value for p.Index1-x Block white-space is set to nowrap.

This property is a standard part of CSS, and my guess is that this setting just doesn't play nice with output to PDF in this kind of usage. I won't even try to parse through what http://www.w3.org/TR/CSS21/text.html has to say about it.

My neo-luddite intellect just does not grasp the worth of having a stylesheet send my carefully crafted sentences (or index entries) out the airlock on the right side of the page into the ether.

For me, nowrap more closely approximates my mp3 playlist rather than anything i would publish.

Anyway, I hope this helps someone.
LTinker68
Master Propellus Maximus
Posts: 7247
Joined: Thu Feb 16, 2006 9:38 pm

Re: nowrap in 2-column index for PDF target

Post by LTinker68 »

I had the same problem, and in fact found several other problems with index entries, both when in column format and without. I sent screenshots and such to MadCap. Unfortunately, there are other issues that I can't figure out the workaround for. For instance, the index entries and its page numbers may be split between columns and/or pages if there are several page numbers listed for the index entry. And in some cases, if there were multiple pages listed, the last page number and its preceding comma would be on a line by itself, instead of the comma being at the end of the previous line. Also, with multiple page numbers and/or long index entries, there may only be one or two leaders between the index entry and the first page number, even though there's obviously room for half a dozen more leaders.

Lastly, and this is really annoying... I have my chapter titles at a large font with a 1.5" margin or something like that between the title and the content. So my topic file has the chapter title ("Index") and the indexProxy. If my page layout for the index has the First page in a column format, then I have "Index", a 1.5" break, and then the index entries, but the second column starts way up at the top of the page instead of having that same 1.5" gap at the top. I ended up having the First page in the index page layout not have a column format, but all other pages in the layout having the columns.
Image

Lisa
Eagles may soar, but weasels aren't sucked into jet engines.
Warning! Loose nut behind the keyboard.
mattbnh
Sr. Propeller Head
Posts: 110
Joined: Tue Feb 26, 2008 12:17 pm
Location: Home: NH --- Compensated Servitude: MA
Contact:

Re: nowrap in 2-column index for PDF target

Post by mattbnh »

I hope I can help. Here is the way I handled something similar.

What I did with an Index.flpgl file was to add a separate body frame to the First page layout, and placed it above the fray - so that it was separate from the main body frame where the index proxy lives. It took a bunch of tinkering (some of which I did today when I realized either I didn't do something before, or 4.1 changed the rules a smidgin) but I got a result that works for our books.

I have attached a snapshot of the important part of the Index.flpgl,
index-flpgl.png
the index.htm
index-htm.png
and a capture of the result in PDF
index-pdf.png
The trickiest part is in placing the extra body frame in the flpgl file and getting it to be the top frame and point to the rest of the body. I had to resize the body frame to that little square up on the right, then make a new body frame that flowed from it, and was the right page size for the first page and had 2 columns. Trying to add the small frame to a regular page and make it first was not appreciated by the page layout editor.

The other thing that messed me up some was ending up with a blank p in front of the index proxy. I spent a lot of time zeroing out top margins and padding and other stuff before realizing that somehow a spare para has snuck into the index.htm.

I hope someone finds this useful.
You do not have the required permissions to view the files attached to this post.
LTinker68
Master Propellus Maximus
Posts: 7247
Joined: Thu Feb 16, 2006 9:38 pm

Re: nowrap in 2-column index for PDF target

Post by LTinker68 »

Thanks, Matt.

The problem with two body frames is that it screws up some other things. I know for sure that if you try to generate Word output using that layout then it'll generate a warning saying that there are two body frames so only one will be used. Of course, I could always do a separate page layout for the index for Word output, since that output is just for review purposes and not the final version released to the customer.

Someone else had a problem with double body frames. It had something to do with the bookmarks pane in PDF output and entries being duplicated due to the second body frame. Although the workaround for that is to hide the bookmarks pane from within Adobe Acrobat and resaving the output.
Image

Lisa
Eagles may soar, but weasels aren't sucked into jet engines.
Warning! Loose nut behind the keyboard.
mattbnh
Sr. Propeller Head
Posts: 110
Joined: Tue Feb 26, 2008 12:17 pm
Location: Home: NH --- Compensated Servitude: MA
Contact:

Re: nowrap in 2-column index for PDF target

Post by mattbnh »

I had not considered Word output, just focused on straight to PDF. Interesting that the two frames may be at the root of the extra bookmarks (which I get). Fortunately we have Acrobat Pro because (in part) we have always had to add security to our PDFs and that was the only way, so I can just nuke the extra bookmarks.

I suppose another way would be to make it a decoration frame and have the Index heading be static on the page layout. But then you would not get an Index toc or bookmark entry unless you pulled something else tricky. But if that layout were used for the Word output for reviewing, and you used the other layout to get the toc and bookmark, that might work.
Post Reply