coloured text rendering

[AbdullahRusi]

as-Salamu alaykum wa rahmatuLLahi wa barakatuh.

Brother please consider implementing coloured rendering in widget like regular textview does when applying setText with formatted strings like this:

<item><![CDATA[<br>some <font color="#00ff00">couloured</font> text]]></item>
<item><![CDATA[<br><font color="#2693ff">another</font> one]]></item>

Due to lack of knowledge of android internals and java in general i've only done partial demo app modification. Now it's accepting formatted strings like above example.
Here is gist with patch and images https://gist.github.com/AbdullahRusi/0a55169396653a06db3452ba79c7f4dd
As seen on screenshots standart textview lacks of good font rendering/shaping engine.
It produce many artifacts(broken ligatures, marks not on right places).
Your excellent library does that part (shaping and rendering glyphs) very well (besides vertical line).
On desctop firefox browser is correctly rendering that formatted text. As i know it uses Harfbuzz or something, so it's good.

so it may become very useful for many Muslims and big sawab(ajr) for you inshaaLLah

[mta452]

وعلیکم السلام ورحمة اللہ وبرکاتہ

I considered adding support for spans while developing the library. But it is not as simple. There are some technical hurdles and some ground work needs to be done first. For example, android spans API is locked to platform paint class for customization. There is no way to inject Tehreer typefaces in it and even if there is, platform canvas cannot use it. So I need to find a suitable solution for this problem before implementation.

Until then, you can manually create Typesetter objects, extract ComposedLine from it, search glyph range for black/red text in GlyphRun, and draw the glyphs with Renderer class. You can explore the source code of TLabel class for reference.

[mta452]

I have added experimental support for ForegroundColorSpan in dev branch. But it is not as sophisticated as that of FireFox. Particularly, there is no way to recognize individual characters in a ligature. FireFox might be guessing character width by dividing the advance of whole ligature with the number of characters it contains.

Here is a screenshot of how it looks like with current implementation.

If you set colors on ligature boundaries, it might be worth seeing the results.

[AbdullahRusi]

ماشاء الله
جزاك الله خيراً
بارك الله فيكم
Its already much better than native android. Thank you.
Looking forward to use library in app and futher imrovement in shaa Allah

[AbdullahRusi]

السلام علیکم ورحمة الله وبرکاته
One thing seems wrong for me at the moment:
Vertical lines.

Thinking a bit about them found that it happen when using U+200C ZERO WIDTH NON-JOINER
with marks like theese commonly used in Quran Mushaf
U+06D6 ARABIC SMALL HIGH LIGATURE SAD WITH LAM WITH ALEF MAKSURA
U+06D7 ARABIC SMALL HIGH LIGATURE QAF WITH LAM WITH ALEF MAKSURA
U+06D8 ARABIC SMALL HIGH MEEM INITIAL FORM
U+06D9 ARABIC SMALL HIGH LAM ALEF
U+06DA ARABIC SMALL HIGH JEEM
Glyphs are drawn but they shouldn't

It seems to me this is more related to SheenFigure project may be it's better to open an issue there
To be more exact let's say:
glyphs like \u200C\u200D\u200E\u200F shouldn't be drawn

[mta452]

وعلیکم السلام ورحمة اللہ وبرکاتہ

You are right. The bug must be in SheenFigure. I'll definitely look into it.

[mta452]

The issue has been fixed in dev branch of sheen figure.

[AbdullahRusi]

بارك الله فيكم
ماشاء الله
Good job!
Still having issues with some fonts.
Here is patch for demo app.
errors_compared_with_stock.patch.zip

First comes stock android textview for comparison.
Take a look at second and third words in verse 2:7 and first two of verse 2:9.
Despite of overall awful rendering of stock android it does render theese bits correctly.
Of course this also depends on font itself - it's OT scripts implementation. Fonts have their flaws.
Seen this error with 2 fonts i have.

This tool is useful to analyze what glyphs string contains (page may be saved to work offline with chrome for example)
https://r12a.github.io/apps/conversion/

Thinking as a good goal and ultimate test for your library - correctly render Mushaf, at least without big errors like this when harakat stays almost in place where previous is sitting.

Quite sure it's all fonts fault need to investigate further...

[mta452]

I have investigated the issue and mark-to-mark positioning implementation turned out to be the culprit. It handled glyphs even when they belonged to different components of a ligature. And so harakats were placed on one another causing the glitch.

The open type spec does not say anything about this specific case. But from the behaviour of different browsers, it seems standard approach to suppress mark-to-mark positioning across different components of a ligature.

I have pushed the fix in dev branch of SheenFigure. Whether it breaks some other fonts is not sure yet.

[AbdullahRusi]

جزاك الله خيراً
بارك الله فيكم
Thank you for your effort and fast fix.
Two fonts become broken, others working fine at first glance.
See this patch
two_broken_fonts.zip

[mta452]

I have revised the logic of finding base glyph for mark attachments. It fixes glitches of "KFGQPC Uthmanic Script HAFS" as well as "Al Qalam Quran Majeed" font.

"_PDMS_Saleem_QuranFont" was breaking due to another reason. It uses anchor table format 3 whose support was not added in SF as it depends on device table. Since all anchor formats have common design units requirements, I have used same implementation for format 2 and 3. But the position of glyphs may be off by some units.

Let me know your findings on latest SF commit.

[AbdullahRusi]

جزاك الله خيراً
Those fonts now ok.
But positions of marks with one font i have are incorrect in some cases:
in verse 2:17 in words 1 and 6
in verse 2:22 in 5 and 16 words there is some glitch - glyph stays apart
stock textview does this correctly
and another bug is handling of br tags
See this patch
marks_moved.zip

[mta452]

Made mark to base attachment work with only first glyph of base in case of multiple substitution sequence. It fixes glitches of 'Traditional Arabic' font as well.

From the findings of reported scenarios, it seems that all mark to * attachments should be based on actual characters and not the glyph string as mentioned in open type specification. But more research is required to prove this possibility.

[AbdullahRusi]

جزاك الله خيراً
One glitch is gone but another one still there.
Glyph stays apart while it should be connected.
So this happens with 'Traditional Arabic' as well as with 'me_quran' font
See this patch
glyph_stays_apart_glitch.zip

[mta452]

Made Arabic engine explicitly set advance of all marks zero at the end of positioning. It fixes both test cases.

[mta452]

Support for many of android's spans has been added in version 2.1. Please see the release notes for details.