Hebrew Nikkud, [mark] feature, FL VI and MS Word vs. Adobe CC
Ori Ben-Dor
Posts: 386
Hi,
I need help figuring out how to use FL VI to make positioning of Hebrew nikkud (diacritics) work in MS Word under Windows.
I created a new font, added matching anchors to two letters and one nikkud sign, let FL VI create the [mark] feature and compiled it. When I exported the font as OTF, nikkud positioning worked in Adobe CC applications but not in MS Word.
So I opened an existing font in which nikkud positioning does work in MS Word and changed the code structure to match the existing font. The result was the same: Adobe CC yes, MS Word no.
So I recompiled the existing font and exported it, to see if nikkud positioning would stop working in MS Word. It didn't stop, it worked just fine.
I should probably add that my new font includes no feature other than [mark], and that the existing font doesn't include other relevant features (it only includes: [aalt], [ccmp], [numr], [dnom] and [frac], on top of [mark]).
Anyone understands this stuff and can help?
Here's the code (the original, FL VI-generated version, is commented out near the end):
I need help figuring out how to use FL VI to make positioning of Hebrew nikkud (diacritics) work in MS Word under Windows.
I created a new font, added matching anchors to two letters and one nikkud sign, let FL VI create the [mark] feature and compiled it. When I exported the font as OTF, nikkud positioning worked in Adobe CC applications but not in MS Word.
So I opened an existing font in which nikkud positioning does work in MS Word and changed the code structure to match the existing font. The result was the same: Adobe CC yes, MS Word no.
So I recompiled the existing font and exported it, to see if nikkud positioning would stop working in MS Word. It didn't stop, it worked just fine.
I should probably add that my new font includes no feature other than [mark], and that the existing font doesn't include other relevant features (it only includes: [aalt], [ccmp], [numr], [dnom] and [frac], on top of [mark]).
Anyone understands this stuff and can help?
Here's the code (the original, FL VI-generated version, is commented out near the end):
feature mark { # GPOS feature : Mark Positioning lookup mark_1 { lookupflag RightToLeft; markClass uni05B4 <anchor 0 0> @lalala; pos base alef <anchor 282 0> mark @lalala; pos base vav <anchor 141 0> mark @lalala; } mark_1; lookup mark_1; script hebr; # Hebrew language IWR ; # Hebrew # markClass uni05B4 <anchor 0 0> @lalala; # # lookup markLTR { # pos base alef # <anchor 282 0> mark @lalala; # pos base vav # <anchor 141 0> mark @lalala; # } markLTR; # # lookup markLTR; } mark;
Tagged:
0
Comments
-
Hi Ori,
try this:
change the language to default:script hebr; # Hebrew
and add another script:
language dflt; # Defaultscript DFLT; # Default
IMHO is much better to use microsoft VOLT to compile hebrew opentype features.
language dflt; # Default
Sami
0 -
Hi Sami Artur,
Thanks for your suggestion, but it didn't work
Why is MS VOLT much better? I hoped FL VI would spare the need for extra tools...0 -
Hi Ori,
MS VOLT is free.
MS VOLT is visual.
You can mix diferent substitutions in the same lookup.
It is much easier to make contextual substitutions or positions (contextual kerning)
MS VOLT Disadvantages:
You cant make GPOS in Stylist Sets (01-20).
You can't do group substitutions with diferent cardinalities.
I'm assuming You are using windows.
If You let me, I would like to examine your font.
samiartur at gmail dot com
Chag Sameach
0 -
Define the mark class outside the feature block and see if it makes any difference. Also don't wrap the position rule inside a lookup. I don't think you need to declare language and script inside the mark feature for this purpose. Also check if you've defined the Hebrew script before all the features.
1 -
You cant make GPOS in Stylist Sets (01-20).?
In VOLT you can assign and compile any kind of lookup to any feature. If you have GPOS lookups in a Stylistic Set feature and they're not working in apps, that's more likely a problem with the apps making assumptions about the features than an issue with VOLT.You can't do group substitutions with different cardinalities.That's going to be true of any tool, isn't it? If the cardinalities are different, how can you know what is 'right' in the substitutions?
0 -
Hi Mr. Hudson, I made a mistake, I mean microsoft apps do not understand SSxx with GPOS.
The other disadvantage is VOLT. does not work with feature parameters (SSxx) and (CVxx).0 -
Yes, if you build your font with VOLT and want to have custom names associated with stylistic sets or character variant features, you need to add these afterwards. I seem to recall this being possible with DTL OTMaster.0
-
John Hudson said:I seem to recall this being possible with DTL OTMaster.0
-
@Bahman Eslami
I'l try your suggestions and report back, thanks!0 -
John Hudson said:Yes, if you build your font with VOLT and want to have custom names associated with stylistic sets or character variant features, you need to add these afterwards.
It seems FontCreator is a good alternative as it supports VOLT script code as well as feature params for character variants, optical size, and stylistic sets.
2
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 799 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports