Is there a Condition or Calculation that will replace a Field font with a different font when the text is bold? The font we use is not a family and therefore text is replaced with a default system font when printing rather than printing in bold.
Conditional formatting with a formula of:
PatternCount( GetAsCSS( self ) ; "<strong>" ) + PatternCount( GetAsCSS( self ) ; ": bold;" ) > 0
Essentially, transform your contents into raw HTML, then check for the ways that bold text is formatted in HTML. If either of those ways exists, then the condition is true and you can apply the conditional style.
Of course, if your text content contains either of those tags as well, it will match. So there is a bit of a caveat if someone pastes raw HTML into your field.
You can probably account for that with:
PatternCount( GetAsCSS( self ) ; "<strong>" ) + PatternCount( GetAsCSS( self ) ; ": bold;" ) > 0 ) andPatternCount( self ; "<strong>" ) + PatternCount( self ; ": bold;" ) = 0 )
PatternCount( GetAsCSS( self ) ; "<strong>" ) + PatternCount( GetAsCSS( self ) ; ": bold;" ) > 0 ) and
PatternCount( self ; "<strong>" ) + PatternCount( self ; ": bold;" ) = 0 )
Making sure that the regular content as-is does not contain those strings.
I'm not sure that will give me the result I need. If the font is Arial and it's made bold how can I get it to change to Times New Roman for example?
Look at the various Text Formatting Functions available inside FM, in particular TextFont ( ) and TextStyleAdd ( )—and remember you may have to nest one function inside another in order to achieve the effect you want.
If I understand correctly you want the font of a field changed if it is bold and only when printing.
Several ways to do this. One is and I guess you have a print layout, is place two fields and use the "hide object when" condition to either show one field formatted as Times New Roman and the other as Arial. You can use Mike's formula to check if field is bold. This only works if the whole field is bold, which I pressume is your question.
Ah yes! That should work.
I thought that would work but there is still a problem.
The main layout used for data entry has a portal displaying line entries with the field set to Arial (Regular). The print layout has the field set to Gravur Condensed Light. If the entered text is made Bold it will default to Arial (Bold) in the print layout. I’ve tried to “hide object when” but it still displays the text in Arial Bold even when the field is set to Gravur Condensed CE (this is the bold version of the font).
It seems there is a more fundamental problem of the field recognising Arial Bold and displaying as anything else in another layout. I have just changed the field font to Gill Sans and it preforms as it should. Maybe this is a bug?
The layout styling definition will only apply if the text in the field is in 'default' state. That is, the text in the field cannot have any user-defined styling on it. You can achieve this default state by using the TextFormatRemove (Self) function as an auto-enter calculation on the field definition. But, then the user won't be able to set the text to Bold. FileMaker is attempting to respect whatever the user has defined for the text font styling, and won't override it.
This is where you need to start thinking about separating the Display part of your project from the Data part. As you are finding, things get quite tricky when you combine the two parts into one definition. So...are the users needing to make only certain words bolded? Or the whole field?
If they are only changing the entire field bold/not-bold, then I might suggest a checkbox/flag that they would toggle. So instead of actually making the font bold themselves, they would press a button or check a box for 'Bold Text'. This would cause a new layout object to show up that is formatted with Bold font. However, this would not be the data entry field - it would be a separate layout field-object (and it would need to be set to NOT allow entry in Browse mode). This field would have the TextFormatRemove() function on it that I mentioned, as part of an auto-enter calculation in the database field definition. This checkbox also makes determining whether or not the field is bolded easier. Then in your print layout, if that checkbox = bold is True, then you would show another field that is formatted in the other bold font; if it's false, show a non-bold version of the field.
Further to all that justinc has written, I would just add a couple of points:
1. It sounds like you may be better to forget about trying to set formatting at the field level with auto enter calcs and so forth. You can apply local formatting in two ways, either (1) select a field in Layout mode and set text formatting options using the Inspector—those settings will apply to all the text in the field, but only to that particular field instance; or (2) in Browse mode, select text within the field in question (some or all of it—) and apply formatting to the selected text—that formatting will apply only to the text thus selected, and only within that single record.
2. If you still want to set formatting by calculation, then you might be best to create calculation fields that hold the formatted versions of what your base text field contains—perhaps one field for your report layout, another for your portal, etc.
Formula for conditional formatting
//not browse(0) nor find(1) modeGet(WindowMode)>1and//adding bold style have no difference (so the bold style need to be applied on whole field data)GetAsCSS(Self)=GetAsCSS(TextStyleAdd(Self;Bold))
//not browse(0) nor find(1) mode
//adding bold style have no difference (so the bold style need to be applied on whole field data)
change font in "More formatting..." button.
Tested on Windows7/FM15
Add: I forgot that the field have data without font, keep styles using
If the same record does work with Gill Sans and not Gravur Condensed CE it seems inconsistent... ( and thus a bug ), also don't forget sometimes you need to do an object refresh for the hide object to work ( or trigger )
Reluctantly, I’ve changed my data entry layout font to Gravur to overcome the issue. It’s very fine and not easy on the eye so I’ve used Arial up till now. I spoke to the Font designers and it’s a known issue for them.
Retrieving data ...