Closed Bug 1021752 Opened 10 years ago Closed 10 years ago

Layout

Categories

(Core :: SVG, 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 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).
Firefox doesn't support altGlyph. All it is displaying is the ordinary font.

You may have more luck using SVG in opentype: http://robert.ocallahan.org/2013/08/svg-in-opentype-progress-update.html
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.