Closed graphicore closed 8 years ago
One thing that is confusing is that Glyphs uses internally it's "human readable" glyph names but the issues #1 to #75 that describe the needed features use uni1234
style names.
I wonder if glyphs manages to "translate" these names when the fea
file is being imported.
I'll try to check this with fonttools and/or afdko next.
I used fonttools/feaLib and https://github.com/typesupply/feaTools/ both accepted my fea code, so I'm rather confident that there's no syntax error.
You are absolutely right! I thought, this way it may be easier for you. (you can search the name) but i checked before. when I’m importing a ligature with the “uni1234, etc…” Glyphs automatically recognize the name but when it makes the new ligature, it appearance as a “human readable” character’s name. so i think it wont be any problem :)
On Dec 7, 2015, at 10:58 AM, Lasse Fister notifications@github.com wrote:
One thing that is confusing is that Glyphs uses internally it's "human readable" glyph names but the issues #0 to #75 https://github.com/Tarobish/Mirza/issues/75 that describe the needed features use uni1234 style names.
I wonder if glyphs manages to "translate" these names when the fea file is being imported.
— Reply to this email directly or view it on GitHub https://github.com/Tarobish/Mirza/issues/77#issuecomment-162624170.
Allright. Two updates:
fea
files with fontTools here@Tarobish can you check http://tarobish.github.io/Mirza/html/generated-pages.html#tests/ligatures1seems to me like we are not "there" yet. (This will be another issue most probably)
Also some of the other test pages that we had for Jomhuria don't look so well with Mirza. This may be OK, I just can't decide it myself. Jomhuria did a lot more. Probably we can remove these tests, but maybe we still need some others. See the links under Generated Tests (Jomhuria) http://tarobish.github.io/Mirza/html/generated-pages.htm
@graphicore I just checked #tests/ligatures1seems mostly don’t look good. in some characters we have the isolate form which is wrong. The main problem is, we don’t have our ligature’s shape as a main character, then different position of dotes based on the original character. we just have two characters that joined together. for example when we have uniFE91 + uniFE9E = uni066E062D uniFEE7 + uniFEA6 = uni066E062D in this case we should have a same ligature as a final form but different position of dots Please see below
Ok, since no information about the dots is ever present in the example, there's no way to move them over to the next glyph. But we should look if and how harfbuzz does decomposition here. Maybe there is a way around (and we get the information about the marks).
I was already wondering how so many glyph combinations could yield in the same ligature-glyph.
Maybe we can just take the base forms and ligate them in an lookup with IgnoreMarks
being set. (I'm hoping actually)
As of now I'm doing decomposition in https://github.com/Tarobish/Mirza/blob/master/Sources/features.fea and I apply that file using fonttools in https://github.com/Tarobish/Mirza/blob/master/Tools/mergeFeaIntoFont.py
We may be able to translate that features.fea
file back to "Glyphs names" (it uses "production" names) or we may be able to import it directly into Glyphs and let Glyphs do the translating (I doubt that Glyphs does this because I've seen it not working once).
I leave this issue open for reconsideration. However, doing the FontTools thing seems to produce fine results.
You may want to check how my new fonts do glyph composition/decomposition (Aref Ruqaa, Mada, Reem Kufi). I’m especially proud of the new way I did in Reem Kufi (putting references to the dots in a separate layer and generating the anchors and the lookups at build time).
Yeah I checked Aref Ruqaa and it gave me enough hints to decompose the glyphs in the init/medi/fina features. GlyphsApp makes the mark to mark and mark to base features so that they work with the base glyphs and ligatures that we have. I was getting the information needed for decomposition from looking at the components of the component-glyphs, that are replaced by the decomposition, which also worked out.
You can look at the fea here
I think to finalize this workflow issue, in the end I will translate the fea file back to GlyphsApp names, then we can include it from there. I'm using the new fea parser of fonttools right now, works well!)
OK, I see. I advice against using ligatures at all, I had so many problems with mark positioning over ligatures in the past that I stopped using them entirely, and I still see some of he problems today. Using contextual substitution is better and gives you more freedom in positioning the dots contextually.
Ok, thanks, that's interesting. We have some testing tables which work well so far, though. Maybe, after updating the fonts to the latest state, we should find some show stoppers and make test tables/cases for them. I agree that contextual substitution leads to much finer control over the marks, but I want to see it fail first and then getting fixed again. Since it's not increasing our effort I think this is the right way to go.
Our first try was me sending a
.fea
to @Tarobish and asking him to import it into the glyphs project.It failed:
One problem for me is that I don't really get good error feedback this way. So I should at least use some other tool to check if the
*.fea
I sent is syntactically correct. I tried fontforge and sorstmill, both had segmentation faults and no usable feedback. I'll try to check this with fonttools and/or afdko next.I think it would still be best if @Tarobish could load these features directly with Glyphs. If not feasible, this thread will document what we end up with.