coloured text rendering about tehreer-android HOT 15 CLOSED

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

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.

from tehreer-android.

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.

from tehreer-android.

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

from tehreer-android.

السلام علیکم ورحمة الله وبرکاته
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

from tehreer-android.

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

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

from tehreer-android.

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

from tehreer-android.

بارك الله فيكم
ماشاء الله
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...

from tehreer-android.

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.

from tehreer-android.

جزاك الله خيراً
بارك الله فيكم
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

from tehreer-android.

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.

from tehreer-android.

جزاك الله خيراً
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

from tehreer-android.

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.

from tehreer-android.

جزاك الله خيراً
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

from tehreer-android.

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

from tehreer-android.

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

from tehreer-android.