RemoveWhiteSpace moves the field content around, but doesn't set the section to be "inlined" - meaning the rest of the system will assume the section still matches the original library resource definition. So when your page overflows, not being inlined means the system loads the section from the original cached resource and then simply propagates the field data into the existing (and original) field definitions on that overflow section. That is why the attributes don't carry forward. If your section has been inlined on the first page, the system would have copied that section instead of loading the original section again.
The only work-around that comes to mind would be to introduce a text area onto the section with an embedded field. Assuming that you have a field that you know will always be mapped on that section, you could try putting that field into a small text area as an embedded field instead. That way, the mapping of that field would cause the section to become inlined. That should cause the overflow to copy the section forward as it appears on the first page.
Of course, I should mentions that this depends upon you having mapped the data on this page before the overflow pages are created. If the pages are created before you get around to mapping these fields, then you would still have the original problem as it would be too late. Remember that field data propagation only moves the content forward and NOT all of the other attributes you may have defined on the first instance of that field.
Thanks for the answer, the problem is that there is no set field that will be populated. I thought of a way to limit the whitespace inbetween fields by using a DAL script to concatinate the values from the XML and put it into a multiline text field but the problem still persists. I need the last line to be colored and I can't embed a multiline textfield with another field that is colored into a text area or table.
Now the approach that I have is to make a section with two fields. One is the Multiline text Field and the other a simple text field that will print the text in red. The problem is that I cannot position them properly since if the Multiline Text grows or shrinks the field below it does not move and I need them to appear as a or text line.
Another approach I've tried is to make the a section that only contains the multi-line field and have another section beneath it with a position relative to the previous section but the section containing the multiline does not change its height and thus leads to text overlapping or it having huge spaces. Is there a way to make the section's dimensions exactly the same as the multiline field's even if grows (I tried having the grow and shrink check box ticked and unticked to no avail, same goes for the can size checkbox)
Any advice will be welcome. Thanks!
Okay, there are several things in your reply that I think can be commented upon.
First, I believe you can set the color of the text where an embedded field is within a text area to be different than the other text. In fact, depending upon your version, the embedded location may inherit the attributes of the original field anyway. I suppose color would be one of those things.
Next, a text area that grows will generally push any object below it. The only reason it would not is A) If the text area was not set to can grow; or B) the object is not directly below some portion of the bottom of the text area. So when you say the field outside the text area did not push, I would assume it is because you did not have the can grow option turned on.
Yes, you can set the size of a section so the text area is at the bottom. Then the section needs to be Can Size or you need the form option Can Grow - Depending upon your version.
Also depending upon your version, there is another text area option that you might want to consider. You add your embedded fields to the text area as normal, but then see the option: Suppress Variable Lines.
This is a feature specific to address line compression type behavior. This is a little different in that you will see the blank lines between the data on the view, because the fields are there for entry. However, when you print, the blank variable lines will be compressed out. So if you are not doing entry, this would still work for you as you are only concerned with the final print.
I'm not sure what version introduced that feature. It is definitely in 12.2 though.
Thanks for your reply. The thing is the data is from 13 XML tags of at least 50 characters each. I'm using a multiline field and a DAL script to retrieve the concatinated values because I need to format each value from the XML tag in a new line without leaving spaces in between. I tried having a section rule REMOVEWHITESPACE on them but it leaves a huge gap in the bottom of the section and the BOLDFACE line gets neglected since it's a field property and those do not carry over if you use REMOVEWHITESPACE.
I also tried to use a single field but it does not allow for the newline function NL() thus I can only get the first XML tag using a normal Field.
If you have a better way in mind, I would really appreciate it. Thanks a lot!
There are two parts to having something print in color. First, you must have set the object attribute (check box) that says "Print in color". Click on the ellipse button next to the color in the properties and you will see the check box on the dialog that appears. The second part is that your PRTTYPE definition must specify the "SendColor" INI option. Some print types will default this to Yes, but since it is an INI option, there's no reason to take the chance. Make sure that you have the option defined in the PRTTYPE:xxx your batch is using. Example:
As for pushing, a Text area / MLT field will push objects as long as these 3 items are true:
A) The text area / MLT defines the "Can Grow and Shrink" attribute;
B) the object you expect to push is on the same section; and
C) some coordinate of the item you intend to push is directly under the text area in question.
If the item you are trying to push is on a different section below the section containing the text area, then pushing requires:
A) That the section is set to Can Grow (set at the form level) or Can Size (and attribute check box that can be set within the section properties - I believe introduced around version 12.1); and
B) that the succeeding section uses some origin definition that would make that section position "relative" to the one that is changing size.
If the item you want to push overlaps the text area / MLT, then you can get some different behaviors depending upon where the overlap is defined and whether the text area has to "shrink" before it has to grow. So if you have a scenario where the text area is not pushing text or fields directly below it, I would double check that you have the Can Grow and Shrink attribute checked on the text area. That is the most likely reason why it would not.