Libertinus: Hebrew holam not well aligned

Created on 8 Nov 2017  Â·  19Comments  Â·  Source: alerque/libertinus

In the following text, the Hebrew holam does not change its position on Vav even if you inserted ZWNJ:

עֲוֹנֹת עֲו‌ֹנֹת 

snapshot

bug combining marks pr-welcome script hebrew

Most helpful comment

This contextual positioning is inappropriate. In Unicode, a vav with U+05B9 is always a holam male. Adding automatic typo-correction to a font makes documents produced with it incompatible with other fonts.

All 19 comments

Please give some context, I don’t know Hebrew at all.

I don’t know Hebrew too, but as my observe, the key of this problem is the sequence ו‌ֹ (vav + ZWNJ + holam), the ZWNJ could making holam shift to left, otherwise is shift to right.

The bug is that U+05B9 should be centered directly above U+05D5.

U+05B9 HEBREW POINT HOLAM is a vowel point above and to the left of its base letter. The exception is when the base letter is U+05D5 HEBREW LETTER VAV, where the holam goes directly above. However, the exception has exceptions; the holam above left on a vav is encoded as U+05BA HEBREW POINT HOLAM HASER FOR VAV. I don’t know what ZWNJ has to do with anything; maybe it was used as a workaround before U+05BA was encoded.

The text is copied from Wikipedia article Zero-width non-joiner, the article explains that the placement of the holam dot to the left of the letter vav is correct in Biblical Hebrew, otherwise would resemble "seasons". However it does not mentioned any more technical purposes.

Can anybody with a working knowledge of Hebrew tell me if I am correct in assuming that:

1) The correct rendering of the U+05D5 + U+05B9 and of U+05D5 + U+05DA is as in the following screen shot (modified by hand from a LibreOffice screen shot by shifting slightly to the right the dot in the left-hand pair):

issue_107_screenshot_01

2) U+05D5 and U+05DA are the only diacritics which go above the HEBREW LETTER VAV.

If the answer to both points is yes, I think I can fix the issue (but I would probably lower a bit the diacritic in the U+05D5 + U+05B9 combination).

@dajare This sounds like something you might be able to answer.

This looks good to me. Just to spell out (as it were) the difference (with some simplifications):

  • U+05D5 is the "base" letter, waw, which is a consonant, but commonly in biblical (Tiberian) Hebrew can also represent the vowel "o" (holem, the name of its over-dot sign);
  • when waw is used consonantally with the mark (over-dot) for "o" (so the base + dot together = wo), then U+05BA (Point Holam Haser for Vav) is used with it, and the over-dot is shifted towards the left edge of the base waw;
  • but when waw is used to represent a vowel, then the "holem-waw" combination (which also has a precomposed representation at U+FB4B) has the over-dot U+05B9 Point Holam centered over the base letter waw (and the base + dot together = o).

These scenarios are correctly displayed in @mgavioli comment above.

P.s. The form used by OP to diagnose this problem = עֲוֹנֹת has a file on Wikimedia Commons showing the correct placement of the "over-dot" for Holam Haser for Vav:

pic

This a case of "consonantal waw", and you can see the holam over the waw is "shifted" off to the left which is what U+05BA is supposed to do (not directly aligned over the waw). From my understanding, in fact, it's a little too far to the left, and @mgavioli's example above (on the left margin of the glyph -- if that's the right term here) is better.

@dajare : thanks for the details. I had a look and I found that Hebrew set-up in Libertinus (for sure inherited from Linux Libertine) is, also given my quite limited knowledge of Hebrew, rather unclear. Primarily:

  1. it uses the same anchors used for Latin/Greek/Cyrillic, which allows for entertaining combinations like A + SEGOL or Gamma + QUBUTS..., notwithstanding that Hebrew diacritics and Latin/Greek/Cyrillic diacritics 'hang' on different sides;
  2. it also uses the same anchor for all the diacritics on the same 'edge' of the base glyph; for instance HOLAM, HOLAM FOR VAV, RAFE, SHIN DOT and SIN DOT all use the same anchor;
  3. some letters lack some (necessary?) anchor; for instance, VAV, ZAYIN, YOD, NUN and FINAL NUN lack the anchor for the 'top' diacritics; ALEPH, ZAYIN, YOD, FINAL NUN, TSADI and FINAL TSADI, SHIN, DOUBLE VAV, VAV YOD and DOUBLE YOD lack the anchor for the middle diacritic(s) (primarily DAGESH/MAPIQ).

The results are, to my eye, sub-optimal, and the details are difficult to understand, debug and improve; for instance, this is the result of combining HOLAM with all the Hebrew letters for which the 'top' anchor is defined (screen shot from FontForge itself):

issue_107_screenshot_02

To me, at least the position above DALET, HET, LAMED, SHIN and, if relevant, the double vowels looks dubious.

I see two possible approaches:

A) Either simply 'fix' the "holam / holam-for-waw over waw" issue, as described in the OP, fixing the two relevant anchor offsets within the current set-up; this would be rather quick and 'dirty'
    OR
B) try to rationalise the anchoring set-up for Hebrew with specialised anchors, in order to arrive at generally better results; this is going to take a while (and has to be repeated for each font) and I for one would surely need the help of someone like you, with a more deep knowledge of Hebrew writing and 'working'; I am also unsure of the real relevance of this font family for (advanced?) Hebrew usage.

Comments, anyone?

@mgavioli I've got some comments, but (just now) not much time, so....

  1. THANK YOU for looking into this. That's a lot of work, it's appreciated.

  2. The absolute worst of the cases your graphic captures is LAMED. The others are passable (well, SHIN is dodgy), but LAMED is just plain wrong the HOLAM should be on the left of the upright stroke, not the right.

  3. The five final forms never appear with HOLAM (it is linguistically impossible), so they don't need an "anchor" (if that's the right language), let alone have one fixed.

  4. On your A/B alternative scenarios: A makes more sense to me, as anyone doing "advanced" Hebrew usage will surely use SBL Hebrew which is "industry standard". Except that...

  5. ... It might be possible to use SBL Hebrew's "layout engine" (?) in Libertinus. The Culmus Project has produced a number of Hebrew fonts with vowels and accents/cantillation using the "layout logic" for the accents from SBL Hebrew (from the Culmus Project landing page):

    Hebrew cantillation marks OpenType layout logic copyright (c) 2003 & 2007, Ralph Hancock and John Hudson. This layout logic for Biblical Hebrew is open source software under the MIT License; for details contact copyright holders at Tiro.

    I don't know quite what this means for "fixing" these placement issues with Hebrew vowels (and accents) in Libertinus, but I thought it was worth mentioning.

I hope that helps for the moment. If I have other thoughts worth sharing, I'll be back! ;)

Hi!
It is possible to contextually place the HOLAM on the VAV only if it's supposed to be in the middle!

Here is a screenshot of the font I'm working on:

1]
screenshot 2018-02-27 08 37 55
This is how it is when the VAV itself is pronounced.

2]
screenshot 2018-02-27 08 38 07
This is how it is when the VAV itself is not pronounced, just used as a vowel for the preceding letter.

And best of all, it happens automatically as you type (with the power of OpenType)!

@dajare : thanks for your detailed comments; they have already some guide lines which can be used. While the possibility to re-use some already existing logic is interesting, it is anyway a fair amount of work (including 'clerical' work like contacting copyright holder and so on). I do not think I have the competences and the expertise to undertake such a task as 're-wiring' the Hebrew section from scratch.

Right now, I am dedicating the little spare time I have for these things to a much 'mundane' fix for the Latin part of the fonts. Once this is done, I'll see if if there is way to optimise the amount of work required and the generality of the result.

@newgraph : thanks for the post and the suggestion. I would say there is a contextual substitution based on the presence of a vowel mark on the preceding consonant, correct?

<vovel> + VAV + HOLAM => HOLAM_FOR_VAV

This seems an interesting solution, but I am sure there are caveats and traps the uninformed designed may easily fall into! Possibly I'll start with a 'simpler' solution...

I would say there is a contextual substitution based on the presence of a vowel mark on the preceding consonant, correct?

@mgavioli Correct!!!
This will always be correct with no exception!

If there is no vowel mark on the preceding letter it will always be a HOLAM MALEH [the dot on top-middle of the VAV].

Just keep in mind that I meant vowel mark, not cantillation mark.

@newgraph : sounds great!

Of course, HOLAM FOR VAV (U+5BA) shall still work correctly in its own, to cope with texts using it.

Just keep in mind that I meant vowel mark, not cantillation mark.

Sure. Which makes for interesting fine points, as I think cantillation marks can occur between the preceding vowel and the VAV...

This is my contextual positioning code [takes into account any possibility (I hope...)]:

lookup vavHolam {
lookupflag RightToLeft;
script hebr;

pos @anyLetter vav holam' <300 -30 0 0>;
pos @anyLetter [shindot etnahta segolta shalshelet zaqefqatan zaqefgadol tipehaleft reviamugrash zarqa pashta yetiv tevirleft gereshaccent gereshmuqdam gershayimaccent qarneypara telishagedola pazer munahleft mahapakhleft merkhaleft merkhakefulaleft dargaleft qadma telishaqetana yerahbenyomoleft ole iluy dehi zinor masoracircle dagesh siluqleft rafe sindot] vav holam' <300 -30 0 0>;
pos @anyLetter [shindot etnahta segolta shalshelet zaqefqatan zaqefgadol tipehaleft reviamugrash zarqa pashta yetiv tevirleft gereshaccent gereshmuqdam gershayimaccent qarneypara telishagedola pazer munahleft mahapakhleft merkhaleft merkhakefulaleft dargaleft qadma telishaqetana yerahbenyomoleft ole iluy dehi zinor masoracircle dagesh siluqleft rafe sindot] [shindot etnahta segolta shalshelet zaqefqatan zaqefgadol tipehaleft reviamugrash zarqa pashta yetiv tevirleft gereshaccent gereshmuqdam gershayimaccent qarneypara telishagedola pazer munahleft mahapakhleft merkhaleft merkhakefulaleft dargaleft qadma telishaqetana yerahbenyomoleft ole iluy dehi zinor masoracircle dagesh siluqleft rafe sindot] vav holam' <300 -30 0 0>;
pos @anyLetter [shindot etnahta segolta shalshelet zaqefqatan zaqefgadol tipehaleft reviamugrash zarqa pashta yetiv tevirleft gereshaccent gereshmuqdam gershayimaccent qarneypara telishagedola pazer munahleft mahapakhleft merkhaleft merkhakefulaleft dargaleft qadma telishaqetana yerahbenyomoleft ole iluy dehi zinor masoracircle dagesh siluqleft rafe sindot] [shindot etnahta segolta shalshelet zaqefqatan zaqefgadol tipehaleft reviamugrash zarqa pashta yetiv tevirleft gereshaccent gereshmuqdam gershayimaccent qarneypara telishagedola pazer munahleft mahapakhleft merkhaleft merkhakefulaleft dargaleft qadma telishaqetana yerahbenyomoleft ole iluy dehi zinor masoracircle dagesh siluqleft rafe sindot] [shindot etnahta segolta shalshelet zaqefqatan zaqefgadol tipehaleft reviamugrash zarqa pashta yetiv tevirleft gereshaccent gereshmuqdam gershayimaccent qarneypara telishagedola pazer munahleft mahapakhleft merkhaleft merkhakefulaleft dargaleft qadma telishaqetana yerahbenyomoleft ole iluy dehi zinor masoracircle dagesh siluqleft rafe sindot] vav holam' <300 -30 0 0>;
pos @anyLetter vav [shindot etnahta segolta shalshelet zaqefqatan zaqefgadol tipehaleft reviamugrash zarqa pashta yetiv tevirleft gereshaccent gereshmuqdam gershayimaccent qarneypara telishagedola pazer munahleft mahapakhleft merkhaleft merkhakefulaleft dargaleft qadma telishaqetana yerahbenyomoleft ole iluy dehi zinor masoracircle dagesh siluqleft rafe sindot] holam' <300 -30 0 0>;
pos @anyLetter vav [shindot etnahta segolta shalshelet zaqefqatan zaqefgadol tipehaleft reviamugrash zarqa pashta yetiv tevirleft gereshaccent gereshmuqdam gershayimaccent qarneypara telishagedola pazer munahleft mahapakhleft merkhaleft merkhakefulaleft dargaleft qadma telishaqetana yerahbenyomoleft ole iluy dehi zinor masoracircle dagesh siluqleft rafe sindot] [shindot etnahta segolta shalshelet zaqefqatan zaqefgadol tipehaleft reviamugrash zarqa pashta yetiv tevirleft gereshaccent gereshmuqdam gershayimaccent qarneypara telishagedola pazer munahleft mahapakhleft merkhaleft merkhakefulaleft dargaleft qadma telishaqetana yerahbenyomoleft ole iluy dehi zinor masoracircle dagesh siluqleft rafe sindot] holam' <300 -30 0 0>;

} vavHolam;

The default position of the HOLAM is on the top-let of the VAV, except if the preceding letter has no mark, then the above lookup will move it to the top-centre.

simple enough!

This contextual positioning is inappropriate. In Unicode, a vav with U+05B9 is always a holam male. Adding automatic typo-correction to a font makes documents produced with it incompatible with other fonts.

Correct, U+05B9 is always a holam male.

But the fact is [from my experience] that most texts are always typed with U+05B9 holam, and people don't use [or don't have the nerves to use] the second holam.

So the above is an excellent automatic solution for that!!!

But of course the other holam is still set to work, in order to be compatible with older texts...

SIL also published some documentations about Ezra SIL, they could be helpful for this, especially two PDF documents at the section "In Keyman package only".
https://scripts.sil.org/cms/scripts/page.php?item_id=SILHebrUni_Documentation

Someone who knows Hebrew needs to fix this.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

philosaurus picture philosaurus  Â·  5Comments

kauesena picture kauesena  Â·  6Comments

tukusejssirs picture tukusejssirs  Â·  6Comments

khaledhosny picture khaledhosny  Â·  3Comments

aksr picture aksr  Â·  6Comments