We seem to be having some major issues laying out a new document set in v.12v3.  I'm not sure if there has been some change between pre 12 versions and 12 that is making this relatively simple task so painful.

 

In this document set there are a series of leading subsummary parts, a body part, a trailing subsummary part, and finally a trailing grand summary part.  We need vertical lines that cross the subsummary parts and the body part to essentailly separate colomuns visually.

 

The body part (and the vertical line) need to slide up based on field contents.

 

We can't seem to get predictable results for this.  Does this function differently in v12?  Suggestions?

 

Thanks in adavance.

I'm not certain about this, but it seems to me that if, for example, you have a 4" vertical line inside a part, then the part would never shrink to less than 4" in height. Objects will slide up, but I don't believe an object such as a line will shrink with a part.

The vertical lines can not exceed the hight of the part and will not shrink or slide . Why not use the field boarders?

 

AFAIK, there hasn't been any changes in this between the two versions. Creating lines that appear to run top to bottom through all of the parts like you mentioned  requires some tedious work to be sure that they align properly and doesn't cross the different parts boundries.

 

I usually use the field boards.

 

HTH

Lee

Hi Lee (or should I say Haillee?)

 

The only issue with using borders is the cosmetic one - where one of the fields has many lines but the other fields don't. Because the vertical lines only extend when there is text, the page has unsightly gaps in it where the vertical lines stop where an adjacent field has many lines.

 

Or am I missing something?

 

I know that vertical line shrinking worked perfectly in 11, since the report I am modifying now to use borders is because the vertical lines don't shrink - I just upgraded from 11 to 12.

Well this is easy to show – both that lines DO slide and also that lines break in version 12 as Dubl says. Changes in 12 can alter element sizes including (but not limited to) part height and line height, most from the px to pt switch.

 

To have lines reduce, they must be below the prior part and extend into the next part and be set to slide up and reduce enclosing part (please see attached VerticalLines1.fp7). The lines slide perfectly. This is new file created for this test but it will break (will not slide) if converted to 12.  Note the increase in the Header height but the lines and fields did not move. In this example, if you select the line block and move it down by 1 to 28 and increase the line block's height to 85 from 84, it will slide perfectly in 12 as well.

 

I have included fp7 and fmp12 formats showing the issue.  The only remedy is to increase the height of your lines (and possibly move them down a pt).

There is also difference which effects reports which is the behaviour of objects touching the header.  I have not had the chance to work through all the potential issues with conversions to 12 since most of my work has been staying in 11 or rewrites in 12.

VerticalLines 1.zip

Folks,

 

Thanks for all your replies.

 

I wonder how many other issues there are, where complicated work-arounds are posted or compromises are made aesthetically.

 

When all for the sake of a couple of px, it all works like it is supposed to!

 

Thanks LaRetta - you've done it again!!

 

ps: (do you guys have the McCain ads - Ah McCain, you've done it again!?)

The only issue with using borders is the cosmetic one - where one of the fields has many lines but the other fields don't.

 

You could duplicate the field with the most lines, assign a border to it, set the font color to white and use it elsewhere. A horrible hack, but it does work (except with certain printers that draw white characters).