Testing SVG fonts

Dear SVG W3 members,

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
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>
 
It looks very promising according to the specifications, but I found
some problems with it:
 
1. First of all, only WebKit based browsers support partially the SVG
font specifications, like Chrome, Safari   
   and home made browsers built with WebKit
libraries.                                                           
                                                                                                                 

2. 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).                                    
   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.
   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
   You can see there that I am using a tiny horiz-adv-x value to make it
visible and you can select all text
   with a tiny narrow selection box.
 
3. Searching in SVG text is not implemented at all.
 
My question is whether these issues are known and whether is there a
realistic perspective that they will be
addressed both in the specifications and implementations.


Best regards,
Stan Jesmanowicz

-- 
__________________________________________________________

Stanislaw Jesmanowicz, mail: stan <at> decotype <dot> com
Amsterdam, The Netherlands,  mobile: +31 653380520