preahkumpii

There is no such link on my screen. And I did create the thread.

Would love to, but I see no way to do that on my end.

This problem appears to have been fixed in the latest update to AD/AP (1.7.2). Thanks!

This problem appears to have been fixed in the latest update to AD/AP (1.7.2). Thanks!

See this thread for context. I'm using AD 1.7.1 from the Mac App Store on a MBP. Though rendering in AD/AP for Khmer script is complete and correct, it has a bug, which requires a difficult and sometimes debilitating workaround to use Khmer effectively. Because I need Khmer script to work out-of-the-box, I have invested a significant amount of time to provide as much information as is possible to repeat it and identify it, in hopes it will be fixed in the short term. This bug did not exist previously. Before, most Khmer fonts would be rendered correctly and normally. I am unsure when this problem appeared. See attached image. By default, Khmer text is rendered incorrectly in AD/AP. But for some reason, adding extra characters on the end of a string of text mysteriously makes AD render the Khmer script correctly, but only when you add enough characters. It begins correctly rendering counting backward a certain number of characters. And as you add more random characters on the end, more of the original string begins to render correctly. At a minimum, this demonstrates that AD/AP can render Khmer text correctly. Therefore, this seems like it might be a bug. Furthermore, in apparently any block of Khmer text, if I add enough random characters after the block (with no LF/CR; that is, directly connected to the block), all of the block of Khmer text will eventually render correctly. The more characters in the block of text, the more random characters at the end that are needed. Random characters on the end that cause this behavior must be Khmer characters. Latin characters do not work. Alternatively, I can add nothing but spaces—like 20 or 30 spaces—and as long as a single Khmer character follows, the rendering is correct in the block of text. At whatever point a carriage return is found, the process must be repeated for the new string to render that paragraph correctly. Lastly, in a Khmer string, if any of the random characters added to the end of the text have any kind of different style applied to them, the rendering in the text string is broken again, just as if no extra characters were added at all. Thank you for your time to solve this problem. Let me know if you have any questions that I can help with. I have also attached the font I was using in this example. Its behavior is exactly the same as many other fonts. Kh Baphnom iChannli Version 2.30 January 18, 2017.ttf

Update on Khmer script rendering here: https://forum.affinity.serif.com/index.php?/topic/87950-support-for-khmer-script-still-terrible/&do=findComment&comment=497286

See attached image. For some reason, adding extra characters on the end of a string of text mysteriously makes AD render the Khmer script correctly, but only when you add enough characters. It begins correctly rendering counting back a certain number of characters. And as you add more random characters on the end, more of the target string begins to render correctly. At a minimum, this demonstrates that AD/AP can render Khmer text correctly. Therefore, this seems like it might be a bug. EDIT: Furthermore, in apparently any block of Khmer text, if I add enough random characters (or spaces) after the block (with no LF/CR; that is, directly connected to the block), all the of the block of Khmer text will render correctly. The more characters in the block of text, the more random characters at the end that are needed. Random characters on the end that cause this behavior must be Khmer characters. Latin characters do not work. I can add nothing but spaces—like 20 or 30 spaces—and as long as a single Khmer character follows, the rendering is correct in the block of text. At whatever point a carriage return is found, the process must be repeated for the new string to render that paragraph correctly.

Oops. Spoke too soon. Certain configurations/spellings in Khmer still do not render correctly.

A fix is there and working in AD and AP 1.7. Adam

After playing around with AD and AP, a fix has been implemented for this problem, albeit somewhat obscure. First, standard ligatures must be turned on for Khmer text, and Typography Script must be set to "Khmer" in the Character panel, as below: : Thank you for this fix. All is well in the Khmer typography world now. Adam

I do appreciate it, @stokerg. Adam

This is the second time I am writing about terrible support for Khmer fonts in the Affinity suite. The first time I wrote, I provided sample fonts and images to show how the fonts are supposed to be rendered. AD and AP still do not have it corrected. I have up to this point been a fanboy for Affinity products, telling lots of people about Affinity. Yet the over the course of many and major updates, this problem, which is a show-stopper for my using Affinity, has not been corrected. And I know others in this forum have requested this problem be fixed as well. As a Khmer speaker, I am still willing to provide any support or files needed to facilitate fixing these bugs. Here is my previous topic that I posted in the forum. It was nicely marked (pre-1.7), and yet 1.7 has not fixed the issue. Thanks. Adam EDIT: I am working in MacOS Mojave.

I was curious if this problem has been identified and corrected in the up-and-coming versions of AP/AD. Also, I found out more information about this font rendering issue. I tried out some tests with these fonts in a web environment with various browsers. I discovered that on MacOS every browser (Chrome, Opera, and Firefox) renders the text with these fonts correctly—except Safari. I'm not sure what this means exactly. Maybe Safari is using the same rendering engine as the OS, and the other browsers are not. For me, this is a big problem with MacOS in general because I use Khmer script so frequently. I do appreciate the work you guys put into making this better.

Thank you for your work on it.

The English equivalent is "Jesus." https://translate.google.com/#auto/km/Jesus Adam