1021802 - Provide native support for Arabic text

Status: RESOLVED DUPLICATE of bug 571808

(Firefox :: Untriaged, defect)

Description

[Stan Jesmanowicz]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140510132300

Steps to reproduce:

I have already submitted this bug. It was immediately closed due to misjudgement as as seen as duplicated. Since I cannot reopen it, I do submit it again.
The answer was: "Firefox doesn't support altGlyph. All it is displaying is the ordinary font. You may have more luck using SVG in opentype"
But this is exatly the poiny. We have no "luck" with opentype.
Heir is the issue:




Actual results:

I am working on high quality Arabic web typography, using our own 'procedural font technology', to overcome limitations of conventional (like WOFF), static font technology.
For web rendering we chose SVG, which most of modern web browsers support quite nicely.
You can see a test of that on http://decotype.com/MARA
As well on: http://decotype.com/webQuran/
Since we are dealing with texts, it desirable to implement some kind of 'text selections' and 'text searching'.
I have tested the SVG font technique, specifically the altGlyph tag.
In this way we can define a unique SVG path for every glyph like:
 
<svg>
<defs>
<font id='xyz' ... >
<glyph id='g1' horiz-adv-x='10' d='M ...' />
<glyph id='g2' horiz-adv-x='20' d='M ...' />
...
</font>
<altGlyphDef id='a1'><glyphRef xlink:href='#g1'
xmlns:xlink='http://www.w3.org/1999/xlink'/></altGlyphDef>
<altGlyphDef id='a2'><glyphRef xlink:href='#g2'
xmlns:xlink='http://www.w3.org/1999/xlink'/></altGlyphDef>
...
</defs>
<g font-family='xyz'>
<text ... >
<altGlyph xlink:href='#a1'
xmlns:xlink='http://www.w3.org/1999/xlink'>ﻱ</altGlyph>
<altGlyph xlink:href='#a2'
xmlns:xlink='http://www.w3.org/1999/xlink'>ﺥ</altGlyph>
...
</text>
</g>
</svg>

An example of my test you can see on http://decotype.com/svgfont.html

The specific SVG file is on http://decotype.com/decotype_svgfont.svg

It looks like it that current SVG font implementations use only the glyph's horiz-adv-x tag to determine the width of the glyph and the position of next one.
I tried to manipulate the horiz-adv-x values in combination with shifting 'path' values in case of overlapping glyphs, but it returned erroneous visualization of the selections.

Moreover, since horiz-adv-x cannot be negative it is useless in case of glyphs that are behind (positioned upstream relative to their) predecessors.
Another thing is that if the horiz-adv-x value is 0 than the glyph doesn't render at all, as you can see in the example above.



Expected results:

Correct renering shoold look like: http://decotype.com/decotype_svgfont.png
Which Webkit browsers do OK.

In Arabic web typography glyphs may overlap each other and sometimes a next glyph can be positioned behind the previous one (this is the case for vowels and dots, but also between two main characters within a word across a letter group gap or even across a space character that separates words).

Comment 1

[Boris Zbarsky [:bzbarsky]]

Please stop repeatedly filing the same exact bug report.  Bug 571808 covers implementing altGlyph.