Perhaps someone else knows of a trick, but I doubt it.
Filemaker treats your merge text object as a single, indivisible object, to get column breaks like you are looking for, you'd need to export the data into an application that has more sophisticated publishing capabilities.
There is one trick I know off to achieve this, but requires setting a custom page setup to the size of one of the columns, so around 6 cm by 28 cm and using a script to preview the records, so displaying a single column going on for as many pages as needed.
You also require a separate table with a single container field in it and you loop through each page of the report, copying the layout in Preview, this will give you a snapshot of the print area, an pasting into a new record in the container table.
Then when you reach the last page you go over to the container table and set the container to be the same size, again as one of the original columns and set the layout to be 3 columns and preview, this will do the trick but can be tricky to do and requires teh user of Copy and Paste.
Not sure of your level of scripting so if you would like I can put together a demo file and post an example of a script for you to download and take apart to build it yourself if you want to go down this route.
That would be great, Orlando. I've done some scripting before, and if you could post a demo file/script I think I could figure it out. THANKS!
Ok here is the script I have come up with and I have also posted a demo for you to download:
First the page setup, not sure if you will need to setup a custom page setup or if FileMaker will remember the page size, but try it as it is first and if it look very wrong then have a go at creating a custom page setup and resetting the first Page Setup step to use that page, the measurements need to be 6.5 cm by 26 cm for this demo.
Teh script looks like this:
Set Error Capture [ On ]
Go to Layout [ “list” (list) ]
Print Setup [ Orientation: Portrait; Paper size: 2.56" x 10.24" ] [ Restore; No dialog ]
Enter Preview Mode
Copy [ ]
New Window [ ]
Go to Layout [ “Containers” (CONTAINERS) ]
Enter Browse Mode
Paste [ Containers::container ]
Close Window [ Current Window ]
Go to Record/Request/Page [ Next ; Exit after last ]
# Now go to the Containers layout and preview the final report
Go to Layout [ “Containers” (Containers) ]
Print Setup [ Orientation: Portrait; Paper size: 8.26" x 11.69" ] [ Restore; No dialog ]
Enter Preview Mode
I have a table called Container with a single field in it called container, and the final report layout is setup with that field and the layout settings are set to 3 columns as your original report.
The demo can be downloaded here.
Let me know if anything does not make sense or if it is not working the way you expected it to.
I hope this helps
Orlando, you are a genius!!! That did the trick. I do have a question about the print setup settings. I imported my data and made the font of the list and container fields smaller, so that it would be the same as the format of my data. However, when I ran the script, the text was cut off in some places.
I fiddled with the print setup settings and the size of the list and container fields, and the result was even more messed up. Could you please explain how the sizes relate to each other? I am using letter size paper (8.5 x 11); if I want to have 1 inch headers and footers, how should I set the sizes of the fields and custom print setup?
Ah that seems to be one little issue I cant work around, is it just cutting off one line, or more? I think it may be the one line is half over the page boundary and there seems to be the text, on what is effectively the gray dashed line in preview, gets cut.
Try adding an additional return in the text field to nudge it down slightly, not ideal but all I can think of right now.
Let me know if this works.
OK, I don't have a solution, but I've figured out why the text keeps splitting. There is a tiny gap in between each record. Even if it is only 1 pixel, it throws off the text's alignment with the page setup. So if there are 3 records on a page, it pushes the text down by 2 pixels, while the page setup keeps printing from the same spot. The more records you add, the more the text gets pushed down.
See the little bugger here:
Does anyone know how to get rid of the space? I've tried both regular and merge fields, and the bottom of the body is pushed up against the field as far as it can go. ARGH!!!! Foiled by one pixel!
I could nudge down the text manually, but then the formatting wouldn't be consistent. And adding new records would throw it off again. I guess I should look into exporting to a publishing program as suggested earlier... :(
Still, Orlando had a great idea, and I learned a lot of new stuff. THanks!
Could you post a copy of the database I sent with a sample of your data so I can see if I can solve it.
If you don't want to post your data online let me know and I will send you a private message with my email on.
I have downloaded the file and the issues is as I expected, the page cutoff is over the text, and the top half seems to disappear adn the bottom half shows at the top of the next page.
I have got another idea that is a bit far out there but might do the trick, I am going to try some experimenting this evening and hopefully have an answer soon.
I hope this is not mega urgent.
A solution to this problem would be far-out! I'm preparing a proposal and may still get the gig if I can get past this issue. Thanks so much, Orlando!
I think I have it! I used a trick I worked out in the past to resize text to fit onto labels. Down load and run a test and see how it fairs. It is a bit sluggish because it runs through refreshing the windows but the end result is what your after.
Just to give you a brief description on what it does, it creates one long list of all the records and sets that to a variable, then goes over to the Output table, where there is a single text field, set up in the same way as the Container field and layout in my original method.
A script then loops through placing each word into the field and testing the size of the field boundaries using a function GetLayoutObjectAttribute. It keeps adding a word from the beginning until the boundaries size changes, then takes a step back and that is the most text you can fin into that column.
Note for if you integrate into your own system, the Output::Display field on the layout needs to have an object name for the function to test the boundary size, in this case I have called it "text"
Then creates a new record in the Output table and starts again from where the text ended.
I am sure there will be a few anomalies crop up as you use this on more and more data, but testing on the data you provided it seems to do the trick.
Download it and have a go and let me know if it works.
Hats off to your creativity!
"it creates one long list of all the records and sets that to a variable, then goes over to the Output table, where there is a single text field, set up in the same way as the Container field and layout in my original method.
A script then loops through placing each word into the field and testing the size of the field boundaries using a function GetLayoutObjectAttribute. It keeps adding a word from the beginning until the boundaries size changes, then takes a step back and that is the most text you can fin into that column."
Just a thought, since you're adding text one word at a time to your output field anyway, you might not need to make "one long list of all the records". You might be able to loop through your records while adding text to your output one word at a time. That might simplify the process a bit.
I decided to create one long list, and store it in a variable, to simplify at least one part of the process, but will give it a try and see if it makes a difference.