From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Tue Mar 20 2007 - 06:06:06 CST
It looks like your glyph metrics for diacritics were computed for
left-to-right rendering, so that diacritics must not be reordered.
What RtoL languages are reordering are complete grapheme clusters. A base
character with its diacritics must remain as a single group, and you just
need to reorder the complete clusters without changing their individual
internal encoding order.
But really, this way of rendering Arabic diacritics (or Hebrew) will produce
poor output, given that Arabic base letters have very variable width, and
the exact form and position of diacritics are normally changing depending on
the base character. So true Arabic fonts are actually using composition
rules where pairs of glyph ids are replaced by a single other glyph id whose
drawing code is fitted to produce the expected design (i.e. with correct
centering of Arabic points). You can’t do that simply with a simple fixed
value for the left side bearing
In fact this is not a problem specific to Arabic or Hebrew, but this also
happens with the Latin script, compare how accents are positioned over I or
over O… (The problem seems simpler with Latin, only because the most common
pairs of letter+accent are also encoded separately as compatibility
characters with either canonical or ompatibility equivalence, but this is
not true for all possible combinations of a Latin letter + diacritic.
Note also that Arabic base letters also have contextual forms that you MUST
support (not rendering the contextual forms will result into a rendered text
that will be difficult or nearly impossible to read for most Arabic readers,
or would be thought really offensive or at least as unacceptable
orthography, as if you were sending a Latin-written text using only capital
letters, it will look like if one was reading old Roman sculture texts in
Latin language, i.e. a foreign language or an offensive way to denature the
Arabic script; remember that Arabic writers proud of their script and have a
long history of excellent typography and artistic calligraphy); one simple
way to support them is, in your renderer, to replace the default letter
codes by their compatibility letter forms for each case (most Arabic letters
that have multiple contextual forms are also encoded with compatibility
codes corresponding to their position).
_____
De : unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org] De la
part de Lokesh Joshi
Envoyé : mardi 20 mars 2007 11:37
À : unicode@unicode.org
Objet : Help Regarding RtoL alnguage rendering
Hi All,
We are developing a fast rendering engine for games for RtoL languages.
Need help from from anyone :) regardng the way we shld render the arabic
and in general form RtoL text. Here i am trying to first explain the common
terms i will use to describe the problem.
PenX: This i mean the horizontal coordinate position from where i am before
rendering the character
LSB: Left Side Bearing: Can be -ve or +ve and depicts how much delta i shld
move before rendering the character from PenX
AW: AdvanceWidth: Shows how much in pixels i shld move after rendering the
current character.
Width: Actual width of the glyph
Height : Actual height of the glyph
Now suppose we have a RtoL input whose memory order is AB, and then its
reordered for visual order as BA
There are two cases where i have the confusion, both are bit related but for
clarity i wish to explain them in two.
1. Please assume that A is a consonant: U+0627 and B is a diacritic as:
U+064b
A has follwoing metrics
Width: 6
AW: 8
LSB: 0
B has the following metrics, since its a diacritic, it need to come over A.
WIdth: 2
AW: 0
LSB: -2
Now if this has been latin, i wud have assumed the following way
Set PenX =0, render the Glyph A at position at a distance equal to LSB of
A, and then move PenX by AW of A,
Then do the same for B and in such a way B will be rendered at a distance of
2 towards left from the right hand corner of A, and thats i believe is
perfect for Latin.
For Arabic, suppose i reorder first and then render from left to right only,
then first i will render B, which will be 2 pixels away from the the current
PenX which will be ZERO, then advance by AW of B which is again ZERO, and
then A and then advance the pen X. This is wrong and will make the diacritic
not above A and infact at a distance of 2 pixels away towards left hand side
from the left corner of A, this is i am sure wrong and not designed by the
type designer.
The way we work now is, in cases of diacritic, we change the LSB = AW of
next Character + current LSB. So in this case LSB of B will change to 8 +
(-2) = 6. So we render B away from current penX at right hand side witha
distance of 6 pixels and then move by nothing since AW is zero and then
Render A. and this was B comes over A at exactly 2 pixel away from right
hand corner. But this also now seems to be wrong because we alter the LSB
etc which is incorrect.
So my fist query is what shld be do ?
2. This query is related to the first. Suppose we shld render starting from
right to left in the visual order. The Visual order is BA, and i move to
the the right most point of the area,, and render A at a pont distant from
the curent PenX = LSB + AW of A towards left, render the A, then move
towards left by AW of A, then render B the same way. But then this method
will also endup in same effect, B away towards left equal LSB of B. This is
wrong.
Another way is to see the character AW first. If its zero, then its a
diacritic and we shld not advance the penX and keep penX where it is and
then render the B after A. And if in case B is not a diacritic then first
advance the PenX by AW of A towards left and then render B. Is this
assumption correct ?
Pls suggest if i am able to explain all this correctly, i need the help in
this regard asap to have the generic implementation for RtoL languages.
Thanx
Lokesh
--
{The harder I work, the luckier I get ! (Failure is never an option)}
This archive was generated by hypermail 2.1.5 : Tue Mar 20 2007 - 06:08:28 CST