Thank you for your post.
I am unable to replicate the issue. This is what I have done:
1. In FileMaker Pro 14, I changed a field formatting from Arial Regular 12 point to Times Regular 12 point.
2. I moved the file to FileMaker Go 13.0v9, and made changes to the text.
3. I then moved the file to FileMaker Go 14.0.1 and made changes.
4. I moved the file back to FileMaker Pro 14, and all entries remain in Times Regular 12 point.
Does this occur with all text fields set for Times Regular? Do other fonts get changed to New York?
Thanks for looking at this. My situation may not have been clear. This is a hosted file on FMS 13. Due to our web site requirements I have not gotten our server up to 14 yet. This file is actually the same file that you have looked at for buttons not appearing in the top right corner of Go on an iPhone. The behavior seems to depend on the default field font. In each case the font is 12 pt regular. Changes that happen do not seem to depend on whether or not there is already content in the field. If the field contains asdf, and I change the default font to times in the layout in FMP, then go in using FM Go 14 add in ghjk, the entire content changes from Times to New York in FMP on commit, not just the added text. However the text in FM Go still looks like it is Times. This is an easy change to spot because New York 12 is much bigger than Times.
Oddly, once the text goes to New York, if the field default is changed, the content does not change to the new default. It has to be manually adjusted. So I am guessing that the text now has a font applied and as such does not change because the text font overrides the default. Is this a "font family" issue? The ones that change, change to similar serif and sans fonts as appropriate to the default. I am hoping you can duplicate this on a hosted file because our entire main database uses Times since it was a typical, common font for Apple. Changing would be difficult for us because our fields are sized to show exact numbers of characters that fit on end result documents which often use other fonts in their output.
I also tested the following fonts:
Geneva default turns into Helvetica
Helvetica default stays Helvetica
Times default turns into New York
Times New Roman default turns into New York
Arial default stays Arial
Palatino default stays Palatino
New York default stays New York
Andale Mono default changes to Helvetica
Oxford default changes to Helvetica - Oxford does not render on the iPad it shows as Helvetica on the iPad when text is entered in FMP and shows as Oxford in FMP. Once a change is made in FM Go the text changes to Helvetica in FMP also.
First, a few things. Geneva, Times, New York, Andale Mono and Oxford are not supported fonts under iOS 8.3, so it doesn't surprise me that Geneva, Andale Mono and Oxford default to Helvetica. Any change you make in those fields will render in Helvetica.
I don't know how you are seeing New York on your iOS device.
On my device, since Times does not exist, it displays as Times New Roman.
On my Mac, I do not have New York nor Oxford fonts installed, so I cannot determine how these would default under iOS 8.3.
I would assume the fonts would also change if you used FileMaker Go 13.0v9. True?
Thanks for the info. I understand that some fonts are not available in iOS and the fact that the device will default to something else to display the text.
This is of course the problem when databases age and available "standard" fonts change in an OS or Application. It is just that this has never happened before and Times is not exactly an obscure font.
No the change does not occur in FM Go 13.0v9. We have not run into this before in any version.
My concern is that regardless of what is displayed on the iOS device something about the actual font is being changed in the database content for some reason.
Additional testing, with all changes to text being made in FM Go 14, shows that if the computer being used to view the database in FMP, recent iMac OS 10.10.3 currently, has the New York font shut off in Font Book.app before opening FMP, nothing happens to the field content. But, if FMP is quit while showing no change, New York font is enabled, and FMP is restarted, the field content shows immediately as New York. Now I suppose we could blame FMP but a change had to happen in FM Go text entry to cause FMP to show a change since it is not changing the field content itself only displaying it in this test. I am not sure why with Times available on the FMP machine it should actually change and display as New York without a change to the coding of the data.
I would have trouble saying FMP is the problem since some of our users do not have the same fonts we do at work and when they work at home, with available font substitution taking place, the actual fonts still show as we wish at work.
Next up for me is to get our systems moved to FMS 14 and see if that changes anything but that is a much more difficult task for me now due to FileMaker tying up Apache and I want to do a clean install of both the OS and FMS and have to rewrite many Apache details to make our websites work.
Please let me know if you have any other ideas. Otherwise we will of course have to change the fonts we make available in our computers and databases. The workaround is that we have reverted to FM Go 13.0v9 because it does not cause this problem.
FileMaker Go 13 (and earlier) did not have the ability for rich text editing. FileMaker Go 13 would apply the installed fontID to the field, and then let FileMaker Pro display the text using that fontID. In FileMaker Go 14, rich text formatting was introduced that allows you to change fonts, styling, etc. So, using a font in FileMaker Pro that is not supported in iOS will perform font substitution. Editing the field will then apply that font substitution to the field.
For a list of supported fonts in iOS, see: http://iosfonts.com
Since you are using fonts that are not supported in iOS, I recommend reverting back to FileMaker Go 13.0v9.
That makes total sense now. Ok, that makes it simple we have to update the database. Thank you very much for finding and clearing up that detail for us.
And I now see formatting applied to sections of text that now remain displayed with that formatting while I have the cursor in the field and I am using FM GO to edit it. This improves one my solutions considerably. (The solution starts with text loaded in the field with a "fill in the blank" format. Tapping the field trips a script trigger that positions the cursor at the first blank. OnObjectKeystroke runs a script that keeps the cursor in the blank. The "next, previous" buttons that normally move the cursor to a different field move the cursor to a different blank...)