10 Replies Latest reply on Feb 16, 2017 5:09 AM by llamaassemblies

    "Grouping" Printed Objects to Retain Symmetry?

    llamaassemblies

      So I have fallen into yet another pitfall in a situation heavily related to my previous question. Basically I have a list that auto-resizes on print/pdf view. All body items start at a certain large height and can scale to a relatively small size. This part works well. However, when I start adding more text so that one of the fields resizes, it does not resize any of the other fields. It does respect the ordering of the list, meaning the next line will start at the normal height, but this means there is a noticeable gap with the other fields since they have a border. Is it possible to somehow group together fields you wish to resize when printing?

        • 1. Re: "Grouping" Printed Objects to Retain Symmetry?
          mikebeargie

          not really. A lot of people will use webviewers with HTML tables holding the content that do a better job adjusting to variable heights of multiple "columns". But that technique doesn't translate well all the time to printed layouts.

          • 2. Re: "Grouping" Printed Objects to Retain Symmetry?
            philmodjunk

            If the issue is the field borders, you can put a horizontal line below the sliding fields and set it to also side/resize. Since it's a single object, it will be consistent as it will slide up no more than the tallest field allows.

             

            Vertical borders are more of a nuisance. I usually avoid using them in such a layout, but it is possible to put in a line that starts in the body and that crosses the bottom border of the body layout part by a few pixels in order to get continuous side borders--haven't tried this in a few versions so test and see if it still works in your version of FileMaker.

            1 of 1 people found this helpful
            • 3. Re: "Grouping" Printed Objects to Retain Symmetry?
              llamaassemblies

              This definitely looks nice if the goal is to have the border around the list. The problem I am having is that it needs to be like a table, with visible rows and columns, to deviate the different sections. Thus having only one bottom row makes the list a bit problematic as it becomes difficult to determine which data belongs with which record. It also seems like this design requires the bottom row to be at the extreme bottom of the body or the vertical lines extend further. The problem with the extreme bottom is that it clips the line, using the exact same thickness I can definitely see it thinner at the bottom than elsewhere. As I have a Trailing Grand Summary beneath the body that is intended to line up with the last row of the "table", this means there is a pretty visible gap even when I cannot get closer to the body on the Trailing Grand Summary side.

               

              I am also not sure how reliable the lines are. It seems they get oddly offset to the left or right. Trying to compensate for the offset results it in moving away in the opposite extreme, meaning it pretty much appears to line up anywhere that isn't directly under the header lines.

              • 4. Re: "Grouping" Printed Objects to Retain Symmetry?
                philmodjunk

                It would not be "one bottom row", but a line between each row of sliding fields. I assumed a list view layout with one row of sliding fields to a record. That may not be what you have, but the method still works. "white space" actually works pretty well to separate columns of data in my experience.

                 

                The problem with the extreme bottom is that it clips the line, using the exact same thickness I can definitely see it thinner at the bottom than elsewhere.

                why not use the inspector to move the line up one point at a time until the thickness is the same as elsewhere on your layout?

                I am also not sure how reliable the lines are. It seems they get oddly offset to the left or right. Trying to compensate for the offset results it in moving away in the opposite extreme, meaning it pretty much appears to line up anywhere that isn't directly under the header lines.

                That's very strange and shouldn't happen. Perhaps you have some auto-size anchors specified that are other than "top" and "left"?

                • 5. Re: "Grouping" Printed Objects to Retain Symmetry?
                  llamaassemblies

                  It would not be "one bottom row", but a line between each row of sliding fields. I assumed a list view layout with one row of sliding fields to a record. That may not be what you have, but the method still works. "white space" actually works pretty well to separate columns of data in my experience.

                   

                  My mistake, I had the line moved into the Trailing Grand Summary, which led to the situation I described. Moving it up a pixel would result in it entering the body.

                   

                  why not use the inspector to move the line up one point at a time until the thickness is the same as elsewhere on your layout?

                   

                  Which is why moving it up one pixel was noticeable. It seems that there needs to be a visible vertical line trail for this to function properly (I have it at the minimum which is extending into the Trailing Grand Summary, which is still visible), which looks less clean than a neatly designed table. I can probably take it as a limitation of design, but it would definitely be nice if the lines met up. It also was why I felt I couldn't move it up a pixel previously.

                   

                  That's very strange and shouldn't happen. Perhaps you have some auto-size anchors specified that are other than "top" and "left"?

                   

                  I definitely agree this is strange, I have used lines in the past on non-lists without problems, but it seems this grid design doesn't want to line up as nicely. Everything is anchored to the top and left.

                   

                  The problem is at its most apparent by the Trailing Grand Summary. Putting the line in the body seems to have fixed the gap, but as stated the Trailing Grand Summary uses a design very similar in appearance to the lines, meaning the same thickness and style. Regardless, looking at the PDF I can easily see that the grid is slightly too much to the left. Taking the body and moving it a pixel over, it is slightly too much to the right. There doesn't seem to be a happy medium.

                   

                  I should mention that the layout view for this seems just as odd. However, while the print preview results in the lines being all aligned in one direction, the layout has them either both inside the table or outside the table based on if I move one of the lines over or not.

                  • 6. Re: "Grouping" Printed Objects to Retain Symmetry?
                    philmodjunk

                    Can you post a pair of screen shots to show what you describe?

                    • 8. Re: "Grouping" Printed Objects to Retain Symmetry?
                      llamaassemblies

                      The upper image shows what happens in a normal browse mode. There is a subtle misalignment where the two lines are spaced outside of the lines above. The lower image, a PDF view of the layout, though shows both to be more shifted to the left.

                      • 9. Re: "Grouping" Printed Objects to Retain Symmetry?
                        user19752

                        It looks your field width of $110.00 is a bit narrow than $770.00, not only shifted to left.

                         

                        I think there was a bug report of the shifting body on print, but I can't find it. Which version do you use?

                        1 of 1 people found this helpful
                        • 10. Re: "Grouping" Printed Objects to Retain Symmetry?
                          llamaassemblies

                          The fields themselves have the same width of 77 pt. The problem is that the line either is a slight instep in or too far extended, pressing the right key once on the keyboard makes it jump to another extreme. The only problem is that they line up perfectly in layout mode.

                           

                          I use the latest version, 15.0.3 Advanced.