-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Review] comparing ttf output from chain against RobotoTTF #4
Comments
I've just had a look at the Regular and it has the same issues. When I diff the table's of the Reg using https://github.com/googlefonts/tools/blob/master/bin/gftools-compare-font.py. We get the following.
As I mentioned in the first post, I believe the kerning has been rebuilt which is fine. I think a lot of these reported changes above are false positives. I suspect this is being caused by fontmake converting glyph names to unixxxx' e.g Aogonek.NAV has become uni0104.NAV which is fine. It seems your fonts are missing mark, mkmk features. This could be what is causing the issues I have already highlighted. |
Thanks Marc! |
@m4rc1e I spoke with @sberlow about this today and @asaumierdemers will take a look at it soon, and then it would be great if you could arrange a video call with them to go over how your review and checking workflow is going these days :) |
I sync'd with @sberlow just now and he says to expect a full report of the deltas next week likely from @justvanrossum |
Order of events |
Looking into this now. |
@m4rc1e can you point me to Roboto sources which do have class kerning? The UFOs in the main Roboto repo here: |
Isn't this VF derived from the shipping ttf though, not the UFO sources?
…On Thu, Apr 12, 2018, 4:27 PM CJ Dunn ***@***.***> wrote:
@m4rc1e <https://github.com/m4rc1e> can you point me to Roboto sources
which do have class kerning? The UFOs in the main Roboto repo here:
https://github.com/google/roboto/tree/master/src/v2
do not have class kerns or groups of any kind, only flat kerns. Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAP9yyxxJTL9ZNSJ4NeZkcM71h3eEH6pks5tn2RrgaJpZM4QpBTL>
.
|
@davelab6 good question. I wasn't involved early on so I'm not sure what the original source was, but currently there is no class kerning in these UFOs and I'm trying to track it down. Are these the shipping TTFs you're talking about: |
The TTFs were the sources I believe, and had, I believe, flat kerning.
…Sent from my iPad
On Apr 13, 2018, at 4:36 PM, CJ Dunn ***@***.***> wrote:
@davelab6 good question. I wasn't involved early on so I'm not sure what the original source was, but currently there is no class kerning in these UFOs and I'm trying to track it down.
Are these the shipping TTFs you're talking about:
https://github.com/google/roboto/releases/download/v2.138/roboto-unhinted.zip ? Do you know the source of the class kerning in here? If not, perhaps we can try extracting the class kerning from these TTFs. Please let me know if you have any further information about the kerning sources, thanks.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I'd recommend you extract these kerning classes that are currently defined in the Roboto UFOs features.fea files, and store them instead in groups.plist, and also use them in kerning.plist in place of the "key" glyphs that are currently being used. This is how the ufo2ft kernFeatureWriter does it: Note that in the next version of ufo2ft we are planning to drop support for this -- as far as I'm aware, this trick is only used by Roboto, and it is not the way UFO is supposed to store class kerning. We will only keep supporting the following:
|
@anthrotype thank you for this. I was in the middle of writing something similar. |
But those UFOs were derived from the release TTFs, right? I made a PR to clarify the README :) |
@davelab6 during the process of running the original Roboto build chain, it will generate ufos for all weights and then make the ttfs. I'm pretty sure these ufos have been used https://github.com/TypeNetwork/Roboto/tree/master/master_ufo |
Okay :) In that case I will update the README PR. Still, the brief is to make the fonts a 1:1 match for the TTFs. |
This comment has been minimized.
This comment has been minimized.
Yes - please prioritize this project above everything except Markazi |
@m4rc1e If you look at the data in the font files you'll see that the kern values for these pairs in the Robot var font and the Robot non-var font are the same. They are as follows: The very small differences you're seeing may be due to rounding errors or grid fitting issues related to rasterization for var fonts vs non-var fonts or something else, but it is not the kerning. |
Your results are much better than mine. I mistakenly didn't diff the VF you attached above. Ignore my previous two comments. When you say you copied the groups and classes, did you mean you copied/manipulated them from the GPOS table in the ttf? are they now stored in the sources? will running fontmake produce this result? If the answer is yes to the two previous questions, I'll be buying you a brewery, a beer isn't enough. |
But you have now done so and the diff check is showing 0 differences?
That was what I understood - since the rest of the project took a starting point from quadratic UFOs, not TTFs, but the GPOS table data apparently wasn't in those UFOs.
@anthrotype does fontmake allow TTX sources to be included and stitched in, as a standard feature? |
Here's the PR with my updated UFOs: #8 |
Yes, just place the ttx files inside a UFO’s data subfolder, and they will be merged in at compile time. |
@cjdunn Fixing the missing marks is relatively straight forward. If you inspect the missing marks from the report in #8, you'll see the mark anchor is named differently to the base anchor. If you remove "mark" from all mark anchors, the amount missing goes from 5,000+ to 900. The remaining 900 all involve uni035D, which I'm looking into now. |
How the original chain handled these: Source setupAnchorPairs func |
@m4rc1e OK got it, I have removed "mark" from all mark anchors. I'm still not sure why these names don't match since we started with your sources. But if you can let me know what other anchors need to be renamed to resolve those remaining 900 missing, I can renamed those as well. Here's the updated var font: Please let me know if this works better now, thanks. |
@cjdunn I've just discovered that fontmake allows us to add our own custom Roboto-Regular.ttf vs Roboto-Regular.ttfattribs 1 modified
mkmks 7656 new
names 2 modified
The new mkmks may be false. I need to double check these and update the diffenator if so. @anthrotype I need a second opinion. I think it may be better to provide a custom MarkFeatureWriter and KernFeatureWriter, based off the original chain. Atm, we're changing the sources so the fonts will have the same output when genned with default fontmake settings. I think reviewers will appreciate seeing sources which are as close as possible to the previous. |
I was planning to drop those two fontmake command-line options actually... The plan is to have these custom writers specified in the UFO lib (as custom key/value pairs), and ufo2ft will load and use these instead of the default. There's a |
@m4rc1e According to what @anthrotype wrote, it sounds like we should still change the sources. I already renamed all of the pairs mentioned in the link you posted above, which are:
If you can let me know what other anchors need to be renamed to resolve those remaining 900 missing, I can renamed those as well, thanks. |
Hey @cjdunn. Sorry but I've had to work on other projects for the time being. Could we have a hangout sometime next week? I'd like to run you through how I'm QAing so you can do it yourself. A large part of this project is understanding Roboto's buildchain (pre fontmake days) |
@m4rc1e Sure, some time towards the end of next week would be good for me, thanks. |
Here are the notes Marc prepared for the review on 2018-06-07: We need to merge #8 - the kerning issue is now solved. The only issue remaining is the mark positioning. Cosimo says this should be fixed at source, #4 (comment) Test SetupTo test the fonts, we’re comparing the unhinted v2.136 fonts against your chain, by running fontmake to generate the fonts from your build sources like this:
This generates static ttfs. We want to compare the v2.136 ttfs against these instead of a variable font to reduce any noise which may be caused by fontmake producing variable fonts. This noise is not an issue you should be dealing with. To make the comparisons, we’re using my fontdiffenator like this:
We should get the following report once the pr is merged: Roboto-Regular.ttf vs Roboto-Regular.ttfattribs 1 modified
mkmks 615 new
mkmks 3000 missing
names 1 modified
marks 59390 new
marks 1777 modified
marks 305569 missing
glyphs 23 modified
We don’t care about these 23 glyphs that are modified, because the diff amounts are negligible - and being introduced by fontmake. The only issues we care about are the missing and modified marks and mkmks. When I added my own Markwriters to fontmake, I got the desired result. Once the marks are fixed, we should end up with this report: Roboto-Regular.ttf vs Roboto-Regular.ttfattribs 1 modified
glyphs 23 modified
New marks and mkmks are fine. Notes from meetingHere’s the test results of CJ’s anchor renaming: marks 59390 new
marks 2437 modified
marks 3871 missing
|
I believe this review is now complete; @m4rc1e please close if so |
First things first, the quality of the chain and font work is fantastic. Building Roboto using the official buildchain takes a long time. I was super happy to see your chain produce the unhinted fonts in a tenth of the time.
For this review, I'm testing ttfs which have been built by running fontmake on your design space files with the following command:
Once the fonts were built, I've compared them against the official Roboto v2.138 unhinted fonts
So far I've only focused on the Black weight.
Has the kerning been rebuilt? I don't mind if it has. As long as line lengths remain consistent, I'm happy. I'll figure out a way to test this.
I've used a new tool we're currently developing in order to catch visual regressions. I'm attaching a zip of the sample images it has generated as well. If I produce a plot of all the characters and view them across 4 browsers, I can only find 2 issues.
Acutes have shifted
before
after
Misplaced mark positions
before
after
Keep this thread open, I need to do further checks.
TN_Roboto_img.zip
The text was updated successfully, but these errors were encountered: