Closed Bug 1021858 Opened 10 years ago Closed 10 years ago

Provide native support for Arabic text - make altGlyph work

Categories

(Core :: Layout: Text and Fonts, defect)

29 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 571808

People

(Reporter: stan, Unassigned)

Details

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 do submit the bug again, because the answer was: Firefox doesn't support altGlyph. This is the point - a bug.
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>




Actual results:

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).
Bug 571808 is the bug about making altGlyph work... as you already knew from bug 1021752, I thought.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
On behalf of the Sultanate of Oman we urgently request to reconsider Mozilla’s support for SVG fonts and please reopen the bug. 

The issue here is that OpenType cannot resolve the following issue:
we render Arabic text in non conventional way - each character is a composition of number of curves, which can differ depending of context and style. And that CANNOT be done with OpenType fonts.
For that we have chosen the SVG Web technology.
And we need support for a font just for text selections and searching.

The background is an ambitious cultural project to reconnect the Arabic world with their script culture. This requires the use of advanced computer typography, which rules out the use of any form of OpenType. The present treatment of Arabic on the web is alarmingly and regressively substandard to the extent that the Omani Government decided to join the Unicode Consortium as the 10th full member last year.
That can't be done with SVG fonts. OpenType is far more powerful than SVG fonts which are really a toy font type having no support for complex scripting.
It is done with SVG fonts. See on http://decotype.com/svgfont.html
Only Mozilla doesn't implement SVG specs.
On webkit browsers it works almost fine - at least it renders.
Anything you can do with SVG fonts you can do with SVG in OpenType instead:  http://robert.ocallahan.org/2013/08/svg-in-opentype-progress-update.html
(In reply to Stan Jesmanowicz from comment #2)
> On behalf of the Sultanate of Oman we urgently request to reconsider
> Mozilla’s support for SVG fonts and please reopen the bug. 
> 
> The issue here is that OpenType cannot resolve the following issue:
> we render Arabic text in non conventional way - each character is a
> composition of number of curves, which can differ depending of context and
> style. And that CANNOT be done with OpenType fonts.

OpenType allows a character to be decomposed into multiple parts for rendering, and allows different shapes and positioning to be chosen depending on context. The example shown in http://decotype.com/svgfont.html could certainly be implemented as an OpenType font.
Could you please advise me how.
You need to log in before you can comment on or make changes to this bug.