Open adishavit opened 9 years ago
You're right, we don't take direction into account when rendering the font, assuming LTR direction.
I wouldn't trust kerning values in the other direction. You should reverse kerning pairs then as well.
Is there an open-source Hebrew font I can test with?
This site has lots of info about Hebrew fonts and a bunch of them for free.
Another issue with blind reversal might be diacritics: לַגּוֹפָן יֵשׁ נִקּוּד מְתֻכְנָת Any string reveral will have to make sure these are resevred as well, so that: אָלֶף is not turned ףֶלָא (and this is with a tool designed for reversing Unicode strings!)
@davelab6 : Yeah, that's why I removed it...
Indeed, and even more than one design was done for Hebrew…! The addition of the Arabic/Hebrew (both with full diacriticals) to existing base .ttf
caused regressions by changing the line-height metrics. There is something in the works for solving that, but suggestions are still welcome. If somebody needs an alpha version for eg. doing some work with diacriticals on the two Semitic scripts I'm happy to assist in supplying access to one; but it's not ready for distribution/betaing until a solution is found that doesn't reflow the line-height metrics in documents and the UI for existing user-cases. See animation in comment #1 of:
"[nc] Line spacing causes major UI problems" https://bugs.launchpad.net/ubuntu-font-family/+bug/1394914
@davelab6 I'm curious – what's the fonts.gstatic.com domain? Is that an "official" place to download OTF fonts?
On 21 May 2015 at 17:18, Frederik De Bleser notifications@github.com wrote:
@davelab6 https://github.com/davelab6 I'm curious – what's the fonts.gstatic.com domain? Is that an "official" place to download OTF fonts?
Its a Google CDN domain. The links are from www.google.com/fonts/earlyaccess
Thanks — I wondered what the /ea/
was for.
On 21 May 2015 at 17:05, Paul Sladen notifications@github.com wrote:
Indeed, and even more one design was done for Hebrew. The addition of the Arabic/Hebrew (both with full diacriticals) to existing base .ttf caused regressions by changing the line-height metrics. There is something in the works for solving that. If somebody needs an alpha version for eg. doing some work with diacriticals on the two Semitic scripts I'm happy to assist in getting one; but it's not ready for distribution/betaing until a solution is found that doesn't reflow the line-height metrics in documents and the UI for existing user-cases. See animation in comment #1 https://github.com/nodebox/opentype.js/pull/1 of
The problem is that if you do this, the new scripts will be VERY small at the same pt/px size... its better to release them as separate families, and use fontconfig rules to fall back from one to the other.
Has anybody looked into this? Arabic support seems good, which also has RTL scripts.
Here is my Cuttle test project.
Hebrew puts the characters in the wrong order. In addition, the marks are misplaced in the basic example.
Cuttle supports many Google fonts, and you can find fonts by searching "hebrew" in the font picker.
I noticed that when loading a right-to-left font (like a Hebrew font), the letters get generated from left to right.
Is this by design?
If I reverse the input string (assuming I know the language and there are no mixed characters), would the kerning be correct?