Bug report: 2 problems with RTL text in verse-on-image

Scripture App Builder
#1

I love the verse-on-image feature! It could really earn the app great exposure. But for RTL text, we have two weird things that happen:

  1. If there are quote marks involved in the verse (as is not uncommon on the verses one wants to put on an image), we’ll end up with a weird pair of quote marks hanging at the end, like this:
    image

  2. If the verse begins with “މާތްﷲ” (as several verses in GEN 1 do), the “ﷲ” incorrectly gets put first (on the right), like this:
    image
    No amount of inserting RLM characters seems to help.

Thanks so much!

1 Like
#2

@mcquayi, can you note this as a bug report? Thanks!

#3

Does the same problem occur in Word for example? Try pasting it into Word and experimenting with different fonts.
We had a different problem with للە in our Kurdish app. The translators did not use that word but it would magically appear in words that contained the letters ل ل ە. Words like قوللو (qulle, means tower) or کوللە (kulle, means locust). (yes, JtB would eat Allah and honey).
With experimenting I discovered that it was simply a matter of font. Some fonts turn that 3 letter combination into the name Allah, some fonts don’t. In the same way that different fonts handle the lam-alif (لا) combination differently. Even in the above sentence with the 2 examples, at least on my browser, 1 of the words does it and one doesn’t.
So my suggestion is to try a different font.
I hope that helps.

#4

Thanks for the idea, Craig.

I’ve tested it, and with all fonts the behaviour is the same.

Note that this is not للە (U+0644 U+0644 U+06d5) but ﷲ (U+fdf2). It works fine in all other contexts. Only the verse-on-image feature has this problem. If a space is inserted between the Thaana letters and U+fdf2, even verse-on-text will render in the proper order (but of course, then there’s a space there).

1 Like
#5

I have added this as a bug.

Can you give me the text to test with and also the Unicode codepoints. Remember you are dealing with non-literate-RTL people here.

I assume that the above ﷲ (U+fdf2) space testing was done with ZWS, thin and hair spaces too?

#6

For bug #2, use this text:
\p \v 1 މާތްﷲ އެންމެ

image
image404×907 9.9 KB

For bug #1 with the quote marks, how about I add you to the GitHub project, so you always have access to the current form of this RTL project? What’s your GitHub username?

You can test it out in any verse involving quote marks, such as PRO 4:24 above.

(Note: The project has added a space before Allah, as a workaround to bug #2.)

#7

@mcquayi, do you have a github account that I can share the project to?

#8

@mcquayi, I see that bug #2 has been fixed. Thank you guys!

We’re still very eager to see a fix for bug #1, as this is a rather glaring, high-frequency problem. It seems that SAB is trying to be helpful, trying to patch things up for verses that contain an open quote without a close quote, by suffixing a close quote at the end of the verse, and likewise for verses that contain a close quote without an open quote, by prefixing the verse with an open quote. That makes sense, and indeed, it would be helpful if it worked as intended. As it is, it’s much worse than doing nothing.

The problem is that in RTL text, quotes are opened with right quotes (U+201D or U+2019) and closed with left quotes (U+201C or U+2018). So before deciding which end of the verse to append the missing quote mark to, SAB needs to check if the project is RTL, and if so, append to the opposite end.

Handy places to test this in the project I shared with you are LUK 4:18 (open without close), LUK 4:19 (close without open) and LUK 4:23 (mid-verse open without close).

Really looking forward to a fix for this soon!! Thanks so much!

#9

Is bug #1 on both Android and iOS?

#10

Yes, both Android and iOS have this bug

#11

There is a separate bug that is unique to iOS, and I’ve just emailed @david_moore1 about this. Here’s what I wrote:

Quote marks should always be “glued” to the adjacent text, never separated by wrapping the line. The scripture text in the Android app obeys this rule, but in the iOS app, it does not. Here’s an example of a closing (that is, left) quote that got wrapped to the next line:

unnamed (3)
unnamed (3)576×1024 268 KB

Similarly, here’s an example of an open (that is, right) quote left hanging when the adjacent text was wrapped to the next line.

unnamed (4)
unnamed (4)1284×2778 270 KB

I’m wondering if there’s some LTR logic in there that assumes it’s OK to wrap after a right quote and before a left quote. Of course, that’s backwards for RTL projects.

#12

Dan your pictures are not showing. Can you reinsert them?

#13

@mcquayi, done. (For some reason, the images in that post were visible to me in Chrome on Win10, but not in Chrome on Android.)

#14

@mcquayi , can we expect a fix for this in the next release?