Open m4rc1e opened 6 years ago
@davelab6 After chatting with @m4rc1e on a private chat, I wanted to get confirmation on what levels of tolerance/matching the original we are shooting for, especially given Roboto Slab had a set updates made that never got pushed.
A couple of notes on the setup and why there may be a number of differences:
Additionally, we had discussed doing the hinting for these projects in VTT. @m4rc1e informed me that the current static Roboto Slab fonts served use ttfautohint so I am not sure if I should hold off until ttfautohint can handle VFs, or if you want to move forward with VTT
On Mon, Aug 6, 2018, 7:48 AM Mike LaGattuta notifications@github.com wrote:
@davelab6 https://github.com/davelab6 After chatting with @m4rc1e https://github.com/m4rc1e on a private chat, I wanted to get confirmation on what levels of tolerance/matching the original we are shooting for, especially given Roboto Slab had a set updates made that never got pushed.
I believe we should be making stuff better quality, and anything that deviates from the current version but is better is fine. Even if it's very disruptive; the future is longer than the past.
The fontdifferenator and diffbrowsers tools give us insight into what changed, and confidence that what changed is better, and didn't unintentionally change anything.
A few families we want to be much more careful about changes because they are system fonts, but even Roboto was radically changed in 2014/15 and there was less outrage than Montserrat last year.
Roboto Slab is pretty popular, but it isn't set in stone.
A couple of notes on the setup and why there may be a number of differences:
- The ufos up on github were updates that had never been pushed, and I used those as the starting point for the VF remastering
Yes, good
- Given the addition of a black weight (extrapolated and corrected) we had discussed the potential for a 3-master setup (see #7 https://github.com/googlefonts/robotoslab/issues/7). The file in the repo uses Thin, Regular, and Black as masters (effectively making Bold an instance)
Sure, should be good
- In working on the file, I performed some cleanup where possible. With kerning, I removed unused classes and merged identical values into classes. I also believe some metrics and kerns were modified in the ufos I started with (see #8 https://github.com/googlefonts/robotoslab/issues/8)
Yep I think they were, and moving to classes is great
- Additionally I set all relevant glyphs and marks up with anchors and added components where possible. While doing this I replaced some glyphs with those used in a typical glyphs setup (replaced /crossbar with /strokeshortcomb, /tail with /tail-cy, etc.)
Great
- One area I am concerned with are changes that were made in the ufos that are less visible
If less visible, why more concerned? :)
Additionally, we had discussed doing the hinting for these projects in VTT. @m4rc1e https://github.com/m4rc1e informed me that the current static Roboto Slab fonts served use ttfautohint so I am not sure if I should hold off until ttfautohint can handle VFs, or if you want to move forward with VTT
It seems VF support in ttfautohint is coming along so I'm ok to have Roboto Slab 99% Ready To Go except for hinting and then circle back to it when we get to publication time and decide if ttfautohint is acceptable. Of course I prefer it as a libre solution.
If less visible, why more concerned? :)
In converting from ufo to .glyphs there was a portion of user data that as far as I know goes unused by Glyphs, as well as extra custom parameters such as "OS2strikeoutPosition" and "OS2strikeoutSize" which I believe are also ignored by glyphs.
I was unsure how important such information was and if there was a way I should be implementing it into the glyphs source properly
Ah yes, right. I guess that stuff is in the current TTFs too, and there are font level Glyphsapp Custom Parameters you can use to set those values if you want to set them manually. I wonder if the Glyphsapp defaults for them are even different from what's in the TTFs
The original file I started with imported those values for the first ufo I opened in Glyphs (Roboto Slab Thin) but much of them were greyed out:
When cleaning up the file I removed the ones that were greyed out. I believe Glyphs generates these values and they seem to be different as shown in first diff above comparing attribute numbers
much of them were greyed out
Not sure what that means. Have asked (https://forum.glyphsapp.com/t/greyed-out-custom-parameters/9525)
Basically I think its fine to forget about that stuff.
Thanks
I was thinking the same, based on the assumption that it being grayed out meant that Glyphs was just storing that information but it was not actually going be used in the creation of the ttf.
However, since the font is generated with fontmake I'm not sure how that deals with the greyed out custom parameters
Have asked (forum.glyphsapp.com/t/greyed-out-custom-parameters/9525)
Have answer: greyed out CPs are inactive, their key's string is not used by GlyphsApp, but because you can have such "private" CPs, they are kept in the file
since the font is generated with fontmake I'm not sure how that deals with the greyed out custom parameters
Right; also not sure.
Here's some diffs against the fonts currently hosted on GF.
Some quick observations
RobotoSlab-Regular.ttf vs RobotoSlab-Regular.ttf
attribs 21 modified
mkmks 26 new
kerns 14077 new
kerns 10973 modified
kerns 119 missing
metrics 418 modified
names 5 modified
names 7 missing
marks 3450 new
glyphs 246 new
glyph --- | D.ss05 Dcroat.ss05 K.ss05 OE.ss05 R.ss05 a.sc aacute.sc abreve.sc acircumflex.sc adieresis.sc ae.sc ae.ss03 aeacute.sc agrave.sc alpha.ss02 amacron.sc aogonek.sc aring.sc aringacute.sc atilde.sc b.sc c.sc c.sc.ss05 cacute.sc ccaron.sc ccedilla.sc ccircumflex.sc cdotaccent.sc d.sc d.sc.ss05 dcaron.sc dcroat.sc e.sc eacute.sc ebreve.sc ecaron.sc ecircumflex.sc edieresis.sc edotaccent.sc egrave.sc eight.sc emacron.sc eng.sc eogonek.sc eth.sc f.sc five.sc four.sc g.sc g.sc.ss05
glyphs 168 modified
glyphs 114 missing
glyph --- | A.smcp Aacute.smcp Abreve.smcp Acircumflex.smcp Adieresis.smcp Agrave.smcp Amacron.smcp Aogonek.smcp Aring.smcp Aringacute.smcp Atilde.smcp B.smcp C.smcp Cacute.smcp Ccaron.smcp Ccedilla.smcp Ccircumflex.smcp D.smcp Dcaron.smcp Dcroat.smcp E.smcp Eacute.smcp Ebreve.smcp Ecaron.smcp Ecircumflex.smcp Edieresis.smcp Edotaccent.smcp Egrave.smcp Emacron.smcp Eogonek.smcp Eth.smcp F.smcp G.smcp Gbreve.smcp Gcircumflex.smcp Gcommaaccent.smcp H.smcp Hcircumflex.smcp I.smcp Iacute.smcp Ibreve.smcp Icircumflex.smcp Idieresis.smcp Idotaccent.smcp Igrave.smcp Imacron.smcp Iogonek.smcp Itilde.smcp J.smcp Jcircumflex.smcp