Tarobish / Mirza

Mirza Arabic Font Project
http://tarobish.github.io/Mirza/
SIL Open Font License 1.1
32 stars 4 forks source link

Find a workflow for collaboration #77

Closed graphicore closed 8 years ago

graphicore commented 8 years ago

Our first try was me sending a .fea to @Tarobish and asking him to import it into the glyphs project.

It failed:

I tried bit it wasn’t successful, i think its possible to this with Glyphs let's do hangout you may figure it out :)

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.

graphicore commented 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.

graphicore commented 8 years ago

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.

Tarobish commented 8 years ago

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.

graphicore commented 8 years ago

Allright. Two updates:

  1. I have a working "Plan-B" when we can't get Glyphs into doing what we want. I figured out how to parse and merge fea files with fontTools here
  2. I brought back some of the testing pages we used for Jomhuria: http://tarobish.github.io/Mirza/

@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

Tarobish commented 8 years ago

@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

screen shot 2015-12-10 at 8 11 10 pm

graphicore commented 8 years ago

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).

graphicore commented 8 years ago

I was already wondering how so many glyph combinations could yield in the same ligature-glyph.

graphicore commented 8 years ago

Maybe we can just take the base forms and ligate them in an lookup with IgnoreMarks being set. (I'm hoping actually)

graphicore commented 8 years ago

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.

khaledhosny commented 8 years ago

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).

graphicore commented 8 years ago

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!)

khaledhosny commented 8 years ago

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.

graphicore commented 8 years ago

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.