Thank you for your post.
I have sent your post and screen shot to our Development and Testing departments for review. When I receive any feedback, I will let you know.
1 of 1 people found this helpful
Thank you for your help.
I also raised this issue in a previous post in the Discussions forum where it was suggested to me that it would be helpful if I could prepare a test database and supply copies of the fonts in question.
I have now prepared that database for testing; it is attached to this post in a zip archive along with the fonts (except the font Cambria, which is proprietary and shipped with the Mac, so I cannot legally share it — I assume you will have it on your end). Aside from Cambria, some of the fonts are freeware that I have personally modified, using FontForge, to make (greater) use of “mark” and “mkmk” features. Others of the fonts are unmodified freeware. This is explained in the test database records. I add this remark to make sure it is clear that the problem cannot possibly have anything to do with my own modification of any specific fonts, since fonts I have not modified are also affected.
Each record in the test database contains a different “test” of the features of interest to me, including “mark”, “mkmk”, “calt” (contextual alternates), “kern” (horizontal kerning) and cursive attachment, for both Roman and Perso-Arabic script. (The issue could be replicated for other scripts, but these happen to be the ones of greatest relevance for my project so I included them).
As far as I can tell FM 15 does not support “mark”, “mkmk” or cursive attachment, but does support “calt”, “kern” (and also “liga”, which I did not test for: it is however clear that “liga” still works).
As I mentioned, in FM 13 all these features were supported.
In all the tests included in the test database I prepared, the display is entirely correct when the database is opened in FM 13.
FM 15 has therefore shown a significant decline in performance for graphical rendering, making it impossible for me to use FM 15 in my project.
Since I do not have FM 14, I do not know if the defect in question was introduced at that time or only at FM 15.
Please be so kind as to direct the attention of your Development and Testing departments to this post. Thank you!
Correction: I neglected to add one font, NotoNaskArabic-Regular, to the zip archive. I have attached it now to this post as well.
3 of 3 people found this helpful
Hi RolfNoyer! Thanks for this - I've had a first quick look, and as I suspected, the issue is also present in FileMaker Pro 14. Development and Testing should be able to get us some more details on what's going on under the hood.
Thanks, David. That’s very helpful.
I’m keeping my fingers crossed that the problem can be solved fairly soon.
I appreciate your help and encouragement.
A couple of quick tests indicate to me that we perhaps should take your fonts out of the equation to narrow down the underlying issue.
I believe there may be a general issue with rendering certain characters that consist of unicode combining marks in FileMaker 14/15, as compared to FileMaker 13 (which doesn't exclude additional issues related to your fonts).
Create a test database from scratch, with just a single calculation field (text result)
Char ( 77900108 )
This is the same as your test character:
uni006C LATIN SMALL LETTER L
uni030B COMBINING DOUBLE ACUTE ACCENT
This character seems to render correctly with any standard font in FileMaker 13, and incorrectly in any standard font in FileMaker 14.
So far, I tested Arial, Courier New, Helvetica, Tahoma, Times and Times New Roman.
Interestingly, (certain) other combined characters render correctly, e.g. Char ( 365903585 ) - a Thai letter with a diacritical mark.
Hopefully someone with a better understanding of Unicode can make sense of this...
It would be interesting to see this tested on 14.0.5 vs. 14.0.6
It is my understanding that the PDF rendering engine was swapped out as of FileMaker 14.0.6 and above.
There might have been some changes in the font rendering engine that were implemented as part of that move.
Please note that this is pure speculation on my part and that I am not in a good position to test as my FileMaker Pro Advanced 14 is already at 14.0.6
Hope that helps.
Our Testing department was able to replicate the issue with FileMaker Pro 14 and FileMaker Pro 15. Our Testing department could not replicate the issue with the Middle East and India version of FileMaker Pro 15 (available through WinSoft). All information has been send to Development for further review.
It is interesting that the versions differ.
Why the version marketed in the United States (and Europe apparently as well) has a new and serious defect in graphical rendering that is absent in the version marketed in south Asia and the middle East is beyond my comprehension, but I hope the problem will be resolved quickly.
1 of 1 people found this helpful
The Winsoft editions of FileMaker add a lot of extra language-related features (some have RTL, e.g.) - I'd really like to see more of those features integrated inte the standard releases.
Antother interesting observation: Char ( 779000108 ) renders fine in FileMaker Go 15.0.2.