Closed m4rc1e closed 7 years ago
I'd also like to alert you to these glyphs which may be missing or not:
Kastroke-cy, cedilla.cap, caron.cap, ertick-cy, nine.tscf, dzeabkhasian-cy, five.alt, macron.cap, seven.posf, circumflex.cap, dieresis.cap, nine.alt, nonmarkingreturn, zero.posf, acute.cap, hungarumlaut.cap, Tetse-cy, breve.cap, .null, four.posf, Emtail-cy, Semisoftsign-cy, caron.alt, seven.tscf, chedescenderabkhasian-cy, tilde.cap, iishorttail-cy, one.tscf, seven.alt, eight.tscf, ring.cap, Entail-cy, one.alt, ordfeminine.smcp, grave.cap, five.tscf, Kahook-cy, six.tscf, two.posf, hadescender-cy, kahook-cy, Cheabkhasian-cy, zero.tscf, commaaccentcomb.cap, one.posf, Dzeabkhasian-cy, edieresis-cy, Eltail-cy, semisoftsign-cy, tonos.cap, cheabkhasian-cy, two.tscf, kastroke-cy, six.posf, eltail-cy, five.posf, ogonek.cap, three.alt, ordmasculine.smcp, dotaccent.cap, tedescender-cy, Schwadieresis-cy, eight.alt, three.tscf, Edieresis-cy, schwadieresis-cy, zero.alt, Iishorttail-cy, haabkhasian-cy, emtail-cy, i.locl, Enhook-cy, two.alt, eight.posf, three.posf, Tedescender-cy, enhook-cy, six.alt, Ertick-cy, four.alt, Hadescender-cy, nine.posf, Obarreddieresis-cy, Chedescenderabkhasian-cy, four.tscf, entail-cy, Pemiddlehook-cy, Haabkhasian-cy, obarreddieresis-cy, tetse-cy, pemiddlehook-cy
Seems like the majority of them are accent marks for caps, defunct figures, composite glyphs.
I will refine this test so it will also check of the unicode exists between the fonts.
Cheers, Marc
Btw, is it possible to include Irene's work on Play https://github.com/irenevl/Play-Greek or would it be better to reserve it for a future milestone?
@thlinard I'm awaiting this to be resolved before I upload https://github.com/irenevl/Play-Greek/issues/1
@alexeiva once Irene has finished the Greek. I guess I'll piece it back together, no need for you to do anything. This is all pretty fixable from my side.
cc @irenevl
Kastroke-cy, cedilla.cap, caron.cap, ertick-cy, nine.tscf, dzeabkhasian-cy, five.alt, macron.cap, seven.posf, circumflex.cap, dieresis.cap, nine.alt, nonmarkingreturn, zero.posf, acute.cap, hungarumlaut.cap, Tetse-cy, breve.cap, .null, four.posf, Emtail-cy, Semisoftsign-cy, caron.alt, seven.tscf, chedescenderabkhasian-cy, tilde.cap, iishorttail-cy, one.tscf, seven.alt, eight.tscf, ring.cap, Entail-cy, one.alt, ordfeminine.smcp, grave.cap, five.tscf, Kahook-cy, six.tscf, two.posf, hadescender-cy, kahook-cy, Cheabkhasian-cy, zero.tscf, commaaccentcomb.cap, one.posf, Dzeabkhasian-cy, edieresis-cy, Eltail-cy, semisoftsign-cy, tonos.cap, cheabkhasian-cy, two.tscf, kastroke-cy, six.posf, eltail-cy, five.posf, ogonek.cap, three.alt, ordmasculine.smcp, dotaccent.cap, tedescender-cy, Schwadieresis-cy, eight.alt, three.tscf, Edieresis-cy, schwadieresis-cy, zero.alt, Iishorttail-cy, haabkhasian-cy, emtail-cy, i.locl, Enhook-cy, two.alt, eight.posf, three.posf, Tedescender-cy, enhook-cy, six.alt, Ertick-cy, four.alt, Hadescender-cy, nine.posf, Obarreddieresis-cy, Chedescenderabkhasian-cy, four.tscf, entail-cy, Pemiddlehook-cy, Haabkhasian-cy, obarreddieresis-cy, tetse-cy, pemiddlehook-cy
I take it this is a list from your regression script?
There are many Cyrillic glyphs from the Pro range that have been omitted in v.2000 since it covered Cyr Plus (Due to time limits). All .cap glyphs have been renamed to .case, and suffixes for figures changed according to Glyphs naming conventions. So, nothing interesting here.
Do you have a script to check the glyphs set agains out GF lists?
deleted: Eth.001, perthousand.001, bulletoperator.001
renamed: gravecomb.001 > gravecomb.loclVIT acutecomb.001 > gravecomb.loclVIT
I take it this is a list from your regression script?
Yes. I'll make the output cleaner soonish sir
There are many Cyrillic glyphs from the Pro range that have been omitted in v.2000 since it covered Cyr Plus (Due to time limits).
If a previous version had a glyph, the new version must include it. I understand you want to comply with character sets but we mut be backwards compatible at the same time.
However, you can have better names. As long as the unicode is there, I'm happy. I need to add this to my script. At the moment, it is name only.
Thank you for fixing this stuff!
If a previous version had a glyph, the new version must include it. I understand you want to comply with character sets but we mut be backwards compatible at the same time
Problem with these Cyr Pro glyphs is that they require reworking, and only partially cover the Pro range. "No glyph, no problem"
For sake of compatibility I am happy to copy over the old glyphs. No script for that yet?
For sake of compatibility I am happy to copy over the old glyphs. No script for that yet?
It's tricky, some people go all out and change the weight and we end up with this scenario, https://github.com/google/fonts/issues/647.
I'm starting to believe that designers will base their whole design and requirements on a single font family. It is the basic unit which affects everything else.
Problem with these Cyr Pro glyphs is that they require reworking, and only partially cover the Pro range. "No glyph, no problem"
"No glyph today that was there yesterday" is a big problem for users, so even if you didn't touch them with your magic, you should retain them (and ask me for a scope extension to ensure that Pro range is fully covered, if it was partially covered yesterday :)
@thlinard I agree that we should ship the Greek font updates ASAP :)
@davelab6 Oh yes! :) And publish https://github.com/google/fonts/tree/greek-glyphsets/tools/encodings/GF%202016%20Glyph%20Sets/Greek in master branch. ;)
@thlinard Just made a PR for that https://github.com/google/fonts/pull/650
@alexeiva Great! 👍
Hi guys! thanks @alexeiva and @thlinard great work! Something that I'm not sure if we need to define is the Greek .sc set. There are two different approaches when it comes to the accented ones. One is if we treat them as UC, so all the accents apart from the dieresis are dropped and the other as we treat them as lc set that the accents stay as they are in lc. The same issue occurs of course with the polytonic set. I guess the choice is to the designer, but if we are building standards and some kind of basic structure, it would be good to have a specific proposal.
Another weird detail is that the finalsigma glyphs, doesn't have its own form of .sc, it becomes a sigma, so we don't really have a finalsigma.sc, we use the default sigma.sc
@irenevl the finalsigma doesn't need .sc, of course! How could I forget that? Same problem in (historical) Latin script, with ſ and s.
For accented small caps, I think the fonts must give the possibility of both approaches. For example, in Brill, unaccented caps is favored: calt is used to provide unaccented caps in "all caps" context, so calt + smcp or s2sc give unaccented small caps, but smcp or s2sc give accented. And so the accented small caps are still needed.
Do I understand correct that sigmafinal.sc should be removed?
24 ς sigmafinal.sc uni03C2.sc 25 σ sigma.sc uni03C3.sc
sigmafinal.sups is also unnecessary?
273 ς sigmafinal.sups uni03C2.sups 274 σ sigma.sups uni03C3.sups
sigmafinal.sc = sigma.sc. I already seen sigmafinal.sc (the same glyph that sigma.sc) only for the needs of the smcp feature. But I wonder if sigmafinal.sc is really mandatory to keep the code simple. I don't think so, so we can remove it.
And if a creator prefers
smcp {sub sigmafinal by sigmafinal.sc;}
to
smcp {sub sigmafinal by sigma.sc;}
it's not a big deal to create sigmafinal.sc.
sigmafinal.sups must be keep. Thanks Alexei!
@thlinard I agree with the approach of having the option for accented sc and polytonic sc. The calt+smcp approach is the most appropriate one, but I always preferred to include a plain substitution through a stylistic set, for straight forward use. So the cast plus a SSxx that makes accented to unaccented, or the other way around, depending on what the designer wants.
smcp {sub sigmafinal by sigma.sc;}
In this case if a user converts sigmafinal to .sc and then back he will get a sigma.
So we need an sigmafinal.sc. Sorry for the mess…
@alexeiva I think it doesn't, small caps feature creates variants, it's a soft conversion, it doesn't interfere with the Unicode value of the glyph. The unicode value is preserved and when the user switches off the feature, the glyph will go back to what it was. SBL is like that, Adobe's fonts etc
I am continuing our discussion in the related PR thread: https://github.com/google/fonts/pull/650
We have issues with the following:
.001 glyphs: Eth.001, bulletoperator.001, perthousand.001, gravecomb.001, acutecomb.001
Bad form: dcroat wacute