1 2 Previous Next 17 Replies Latest reply on Jan 10, 2012 4:27 AM by paulspafford

    Merge Fields - format anomaly by a nit picker

    DaveRawcliffe

      To All,

       

      << TEXT>>

       

      I have a lot of layouts that display a concatenated Merge "text & number" Fields.

       

      I hope this is not just me and I may be of my rocker.

       

      But, It has been understood since pre .fp7.

      That the leading merge field "<" as set, controls the format of "TEXT" to last ">" be it Style, Size, Font, Color, etc..

      And That Any Item past the last ">" stands upon it's own entered format.

       

      This is all well and good & works in most all situations, However, try this 4 part string:

       

      Text <<TestField>>AlphaNumeric OtherText

       

      [1] "Text" - the word

      [2] <<TextField>> (Any Table Field)

      [3] AlphaNumeric (An immediately trailing character (no space) )

      [4] "OtherText" - the word

       

      Written Merge Display String

      Text <<TestField>>: OtherText

       

      The Merge Field [2] & the trailing AlphaNumeric [3] is set to BOLD or any Other Format.

       

      Expected result is:

      Text TestField: OtherText ( [2] & [3] are Bold )

       

      Actual result Is:

      Text TestField: OtherText ( Only [3] is Bold )

       

      The trailing [3] now controls [2]

       

      Please Note; that if there is a space between [2] and [3] the problem does not exist, but that is not grammatically correct.

       

      I know this is a Nit Pick, but when I write a text string I would hope it would show what I wrote.

       

      Hope this is clear & I have not missed something,

       

      Dave Rawcliffe

        • 1. Re: Merge Fields - format anomaly by a nit picker
          karendweaver

          Dave,

           

          You are correct about the leading <. You just need a trailing, final > that is also bold to "end" the special formatting.  This is not new behavior, all text following the initial formatted < keeps that format unless terminated.

           

          Hope that is clear

           

          Karen

           

          Sent from my iPad

          • 2. Re: Merge Fields - format anomaly by a nit picker

            You are correct, Dave.  We have always been able to format only the beginning chevron for the entire merge field.   I tested back through version 7 and they behave in the manner you describe.  It only happens if there is not a space immediately after the merge field.

             

            Karen said, "This is not new behavior, all text following the initial formatted < keeps that format unless terminated."

             

            Actually Karen, if you try it out you will see that the first chevron controls the merge field and text outside (before and after) the merge field is not affected; no need to 'terminate' the merge field format.  And if it were true that the specified format in the first chevron must be somehow terminated (how exactly?), then in this example, the bold would continue through the remaining text object and it does not; in fact, the bold disappears from the entire string.  It happens if we apply other formatting such as color. 

             

            What appears to work:  Apply the formatting as you expect but then select the first 'bolded' chevron and make the color different that solid black (select next color block down).  That forces it to hold the bold.

             

            Message was edited by: LaRetta ... better yet ... make the colon a slightly lighter black instead ... and the bold will hold

            1 of 1 people found this helpful
            • 3. Re: Merge Fields - format anomaly by a nit picker
              karendweaver

              Interesting - LaRetta I did try your suggestion and the bold does disappear after the first merge field - I did not need a space, nor did I need to apply a different color to the first chevron to get it to work properly.  So - maybe there is something else going on with Dave's text.

               

              My solution was a holdover from FileMaker 5 days when I had to apply multiple different formats in a paragraph including merge number fields with different formats for contract.  I have just always done it that way! Usually - I format the entire merge field the way I want it, but  use the method of formatting a smaller font inside the two chevrons so it will fit in the space better.  In that case - I DON'T want the small font formatting to go beyond the specific merge field.

               

               

              Karen Weaver

               

              karen@desertdogtechnology.com

              Desert Dog Technology, Inc.

              • 4. Re: Merge Fields - format anomaly by a nit picker

                I repeated the test several times before posting and I match exactly the results that Dave gets.  What platform and FM version/updater are you?  I am Windows XP Professional, SP3 using FMPA 11.0v3.  And the same results are reproduced back through my version 7.0v3.

                 

                Message was edited by: LaRetta

                • 5. Re: Merge Fields - format anomaly by a nit picker
                  karendweaver

                  I am FMPA 11.0v4, Mac OS 10.7.2 (Lion)

                   

                  Maybe it is a Windows font difference.

                   

                  I used the following  <<company_address>><<company_city>>

                   

                  And I got  P.O. Box 1234AnyCity

                   

                  Hope the formatting comes through…  Only the first chevron is bold, no other formatting was applied.  The address is bold, the city is not.

                   

                   

                   

                  Karen Weaver

                   

                  karen@desertdogtechnology.com

                  Desert Dog Technology, Inc.

                  • 6. Re: Merge Fields - format anomaly by a nit picker
                    DaveRawcliffe

                    Karen;

                     

                    I am using FMPA 11.0v4 - Mac 10.6.8

                     

                    The BOLD chevron format of "company_address" is cleared by the PLAIN chevron format of "company_city"

                     

                    I would add, that there needs to be a Plain "Text" element before the 1st formatted chevron i.e.;

                    Text <<TestField>>: OtherText = Text TestField: OtherText

                     

                    If the Plain "Text" is deleted it behaves as expected i.e.;

                    <<TestField>>: OtherText  = TestField: OtherText

                     

                     

                    Dave Rawcliffe

                    • 7. Re: Merge Fields - format anomaly by a nit picker
                      karendweaver

                      Well - my example test did NOT have a plain text element anywhere, nor any spaces and worked fine. 

                      Oh - looks like email strips the formatting from my response.  here it is again

                       

                       

                       

                      text<<company_address>><<company_city>>

                       

                      returns

                      textPO Box 123AnyCity

                       

                      and

                       

                      <<company_address>><<company_city>> with no leading text

                       

                      also returns


                      PO Box123AnyCity

                       

                       

                      interesting that we are getting different results.  Have you tried recreating this issue on a blank new layout?  Possible there is something corrupt somewhere??

                       

                      What font and font size are you using??

                       

                      Karen Weaver

                       


                      karen@desertdogtechnology.com

                      Desert Dog Technology, Inc.

                      • 8. Re: Merge Fields - format anomaly by a nit picker

                        It also bolds properly if you leave that beginning 'text' there, Dave, and instead put a space before the colon.  Again, there is no need to 'clear' a format in a text box.  The entire merge field (within a text box) is formatted by the beginning chevron and the formatting only applies to THAT merge field and not other merge fields fields within same text box.  

                         

                        As said, if you want both text before and anything immediately after, add any other formatting to the colon (change the color by even Lum +1 from the original color) and it will work as you wish.  Heck, instead of changing the color you can change the style = condense or even small caps and it also then forces the proper bolding. 

                         

                        Hi Karen, I too have changed all text except the first chevron to very small font (3 pt) to fit on buttons and such - since vs. 6.  I guess I had never had a situation that warranted text (without a space) immediately after a merge field ... which is the only time this issue appears to present itself.  It isn't just bold - all formatting appears to 'break' in this same way so it is not just bold and not platform- or version-specific. 

                         

                        It is a small bug which should be reported but it can be easily fixed as I've suggested.

                        • 9. Re: Merge Fields - format anomaly by a nit picker

                          Karen,

                           

                          Type this:


                          text <<companyName>>: ... produces no bold

                           

                          The bolded colon immediately after the merge field breaks the bold.  Another merge field immediately following does NOT break it and neither does a space immediately following the merge field.  It is only text formatted the exact same as the leading chevron which breaks it.  You can use color red instead of bold ... it is consistent in how it breaks. 

                          • 10. Re: Merge Fields - format anomaly by a nit picker
                            karendweaver

                            Well, this is truly fun and informative.  Are you saying your example above has a bolded colon with no space and that breaks the formatting??  I did not get those results

                             

                            if I format the first chevron AND the colon in bold with no space - I still get bold for both the company name AND the colon. 

                             

                            If I format the first chevron in bold and the colon in plain text with no space - I get no bold at all for either one.  Broken as you describe

                             

                            If I format the first chevron in bold and put a space before the colon, I get bold for the company name AND bold for the colon...

                             

                            same results for other formatting such as color..

                            • 11. Re: Merge Fields - format anomaly by a nit picker

                              Ah ha! Now we are getting somewhere, Karen, so it must be platform/version difference:

                               

                              if I format the first chevron AND the colon in bold with no space - I still get bold for both the company name AND the colon. 

                                   I do not.  I get same results as Dave - the colon stays bold but the merge field does not.

                               

                              If I format the first chevron in bold and the colon in plain text with no space - I get no bold at all for either one.  Broken as you describe

                                   This works for me ... the merge field bolds.

                               

                              If I format the first chevron in bold and put a space before the colon, I get bold for the company name AND bold for the colon...

                                   Well at least we match on this one, LOL.  Thank you for following up. 

                               

                              I also do not understand how removing text prior to the merge field will then make it work - I was able to replicate Dave's test here as well.  But then, I do not understand why this breaks to begin with. 

                              • 12. Re: Merge Fields - format anomaly by a nit picker
                                comment

                                Why is this so difficult?

                                • 13. Re: Merge Fields - format anomaly by a nit picker

                                  Hi Comment ! 

                                   

                                  If the 'correct' way is to always select the entire merge field and trailer and apply format to entire selection, that is fine in general principle but that is not real life.   If we bold a merge field by selecting the first *chevron and then a month later decide to bold the colon also, we should be able to select the colon and bold it and have the formatting on the merge field remain unchanged.  We should not have to reselect entire merge and Trailer and reformat them.  We do agree its wonky, right?

                                   

                                  * If I want to bold a merge field, I do not WANT to bold it all because many times that size increase jumps the text box to two lines or resizes improperly.  It is common practice to just format the first chevron.

                                   

                                  This is a great way to display the issue - thank you for stepping in with the file. 

                                   

                                  Do I see anything differently?  No, this is precisely the results I get.  Windows XP SP3, FMPA 11.0v3 

                                  • 14. Re: Merge Fields - format anomaly by a nit picker
                                    comment

                                    By "correct" I meant that this one displays as intended. However, the practice of formatting only the first < is not a documented feature, AFAIK. That's not to say it should behave the way it does here - only that even with this buglet it's a whole lot better than nothing.

                                    1 2 Previous Next