[googlefonts-discuss] [Work Log] Organising Google fonts: build chain

[Lasse Fister]

Hi All,

Marc already introduced our project here:
https://groups.google.com/forum/#!msg/googlefonts-discuss/H5F6NUzaWFk/ewRdMP2yBAAJ

So here's my first report for today:

1. what I did today

- I read a lot of code of relevant projects concerning CI, test and
build automation of fonts, to get an overview over what's available and
already done:

fontmake, glyphsLib, Fontbakery, google/fonts//tools,
googlei18n/nototools, fontqa.com

- I made some notes and started to think about some ideas.

- Also, like Marc: Built Wei's Work-Sans as a test with fontmake.

2. what I'll do tomorrow

- get more concrete about the building and testing workflow

- chat more with Marc

- inspect the source repositories and try to do something useful with them.

3. any questions for the team

---


Best, Lasse

[Lasse Fister]

1. what I did today

- Got some computing problems sorted out.

- I was dealing with the old googlefontdirectory source files repository
which is quite big (~5GB) and not online anymore.
It just takes forever to move the files around. One attempt from Dave to
put the files on Google Drive failed. Which I didn't realize at first.
So I got a google drive compatible linux client:
https://github.com/odeke-em/drive, a fine piece of software by the way.
Then, downloaded the files. When I eventually found out that the
downloaded repository was incomplete I also found that I had a clone of
the original repository already on disk.

At the moment (and since 4.5 hours) mercurial is still preparing
("bundling") to push the repository to bitbucket:
https://bitbucket.org/lassefister/old-googlefontdirectory
I'll check back in the morning …

- I wrote a small script to inspect the contents of the repository and
make a spreadsheet from it.

Here's the script:
https://github.com/graphicore/fontdev-adhoc-dump/blob/master/inspect_sources.py

It'll need some better filtering and a bit more knowledge about the
source repo structure, but then
we can probably use parts of it to drive some of the conversions into
the new projects automatically.

Here's the current output:
https://docs.google.com/spreadsheets/d/15sBK4Ro7K8ehEjO7fT82xyO9QdBZZgaaNkvRNiQyLOE/edit?usp=sharing

2. what I'll do tomorrow

still to do:

- get more concrete about the building and testing workflow

- inspect the source repositories and try to do something useful with them.

Best, L.

[Dave Crossland]

For the 538 families with a 'src' folder that had a source font file, we'll need to find out if they have newer upstream sources (for example the family with the largest number of source files in the repo - Raleway - is upstream in github.com/impallari) but many of them do not have other upstreams. 

The best way to know about the upstreams is to ask the designers; and therefore it would be helpful if your script could fetch the designer key's value from the METADATA.json files in the hg repo (and perhaps also their emails or domains, with a regex of the copyright keys in the json files) and add them to the spreadsheet, so we can sort the table by the designer. 

BTW I'd previously made a search of rightsholder emails - https://github.com/google/fonts/blob/master/TRIVIA.md#rightsholder-contacts - that might help :) 

Nhung has already been searching for the upstream earlier this week, and hopefully these efforts can dovetail :) 

[Lasse Fister]

1. what I did today:

- I checked if the push to bitbucket of the old googlfontsdirectory went well, it did. Later Dave pushed his remaining more current changes, so we have it now completely archived here: https://bitbucket.org/lassefister/old-googlefontdirectory

-I updated the script that I started yesterday, it now includes data from the METADATA.json as suggested by Dave:

On 27.07.2016 05:54, Dave Crossland wrote:

For the 538 families with a 'src' folder that had a source font file, we'll need to find out if they have newer upstream sources (for example the family with the largest number of source files in the repo - Raleway - is upstream in github.com/impallari) but many of them do not have other upstreams. 

The best way to know about the upstreams is to ask the designers; and therefore it would be helpful if your script could fetch the designer key's value from the METADATA.json files in the hg repo (and perhaps also their emails or domains, with a regex of the copyright keys in the json files) and add them to the spreadsheet, so we can sort the table by the designer. 

BTW I'd previously made a search of rightsholder emails - https://github.com/google/fonts/blob/master/TRIVIA.md#rightsholder-contacts - that might help :) 

I got a bit lost in optimizing regular expressions to extract Emails and URLs, so, there is little noise in these fields now.

updated data, still at:

https://docs.google.com/spreadsheets/d/15sBK4Ro7K8ehEjO7fT82xyO9QdBZZgaaNkvRNiQyLOE/edit?usp=sharing

2. what I'll do tomorrow:

If there's interest, I'd like to dump the the data extracted from the googlfontsdirectory into a Sqlite3 database.
We can then use: http://kripken.github.io/sql.js/GUI/ to run queries against it.
I'd curate a collection of useful queries that we can run via just clicking on links. Nothing fancy really, its just that SQL is so much better to give a good view on data of this kind than spreadsheets IMO.
Also, we could add other tables, like the data of Nhung or data from the big google drive spreadsheet, and relate them. JOIN ON family_name "GROUP BY designer" etc.

Otherwise, I'll return to the basic mission, take a look at the bigger picture and try to do something smart.


3. questions for the team:

Nhung has already been searching for the upstream earlier this week, and hopefully these efforts can dovetail :)

I'd be happy to merge the data, is it available in any format?

[Lasse Fister]

1. What I did today:

Checking out the preparation requirements.
Hangout and chats about the preparation tasks.
A pair programming-style preparation session with Marc for Francois One.
I had to bring up my tools up to speed.

2. What I'll do tomorrow:

More pair programming-style font-prep session with Marc, concerning
Montserat.

3. Questions for the team:

@Dave: I think Montserrat was a bad choice for me and Marc for tomorrow
because it's in a fine shape. Montserrat is already on Github and in
Glyphs-format: https://github.com/JulietaUla/Montserrat

[Dave Crossland]

On 28 July 2016 at 19:54, Lasse Fister <la...@graphicore.de> wrote:

@Dave: I think Montserrat was a bad choice for me and Marc for tomorrow
because it's in a fine shape. Montserrat is already on Github and in
Glyphs-format: https://github.com/JulietaUla/Montserrat

It has problems, check its issue tracker - https://github.com/JulietaUla/Montserrat/issues 

The glyphs file doesn't follow my checklist, and so even if you come up with very little to change, I am certain that there are things to change. 

I want it to be a perfect model for what a big family should be like :) 

--

Cheers
Dave

[Lasse Fister]

1. What I did today:

(Friday till Sunday night.)

After the hangout meeting I started working on Montserrat. Worked my way
down the checklist until I found out that:
a) Glyphs scripts usually need to be applied for each layer individually
b) The checklist point "Correct Path direction for whole glyph set"
is the Armageddon for interpolation compatibility.

That evening I fixed some interpolation problems by hand before I had to
leave I made a PR [1].

Saturday:
I started my own brew of Glyph-Scripts[2]

notably: boilerplate.py which makes the general task more DRY

Correct Path Directions All Layers.py and Delete Stray Points All
Layers.py do exactly what one would expect, but with all layers of each
selected glyph.

New scripts are:

Sort Paths.py [3] (There's a docstring in the and there are comments.)

Does the same as the "Correct Path Direction" filter, but doesn't need
your attention. In my test file it worked in almost all cases very well
and when it did not work it did not break anything.
I made this ti fix the mess left by "Correct Path Direction", but
ironically if Sort Paths produces bad results, "Correct Path Direction"
can usually fix it.
Run this after: "Correct Path Direction"

Set First Points.py[4] (There's a docstring in the and there are comments.)

This fixes the rest of the "Correct Path Direction" havoc (don't get me
wrong, I think "Correct Path Direction" is a fine feature, but running
it on the whole glyph set of an interpolated project creates scorched
earth.)
This will always create masters that interpolate, if they are generally
compatible and if the paths are sorted correctly. However, in many cases
the choice of a good starting point is hard to do for a computer and in
some of the cases we are left with twisted and scrambled interpolations.

I have an idea how to tackle that as well, however, I'd need some time
to do so.

Here as well, often when this script fails "Correct Path Direction" can
repair it.
Run this after: "Correct Path Direction"

Sort Paths.py and Set First Points.py don't need to be run in a special
order, but after "Correct Path Direction" it makes sense to run both on
all glyphs and then check manually for interpolations that are
scrambled. It shouldn't be many, though, maybe different designs work
better or worse with the scripts.

2. What I'll do tomorrow:

See what the project plan has to offer for me. Coordinate with Marc.
Add a .gitignore to Montserrat
Maybe file some issues in Montserrat from my cleanup log.

3. Questions for the team:

Should we really run "Correct Path direction for whole glyph set" in
interpolated projects? It seems to me that it does more harm than good.
Though, with the new scripts, I think the effort can be done.

[1] https://github.com/JulietaUla/Montserrat
[2] https://github.com/graphicore/Glyphs-Scripts
[4]
https://github.com/graphicore/Glyphs-Scripts/blob/master/Paths/Sort%20Paths.py
[3]
https://github.com/graphicore/Glyphs-Scripts/blob/master/Paths/Set%20First%20Points.py

On 29.07.2016 01:54, Lasse Fister wrote:
>
> Checking out the preparation requirements.
> Hangout and chats about the preparation tasks.
> A pair programming-style preparation session with Marc for Francois One.
> I had to bring up my tools up to speed.
>
>
>

[Lasse Fister]

1. What I did today:

This:

See what the project plan has to offer for me. Coordinate with Marc.
Add a .gitignore to Montserrat
Maybe file some issues in Montserrat from my cleanup log.

And:

I reviewed a bit of Francois One and Marcs Glyphs Scripts.

I started today Nunito: https://github.com/graphicore/NunitoFont

I could have finished it, but I preferred making setting up new repositories a blast and made a script: init_from_old_project.py[1]
There's also a font directory template[2] that the scipt uses.

[1] https://github.com/graphicore/fontdev-adhoc-dump/blob/master/g_font_repositories/init_from_old_project.py
[2] https://github.com/graphicore/fontdev-adhoc-dump/tree/master/g_font_repositories/templates/old_project_new_repo

Check out the Nunito repository for the vanilla result of running this script. (initial commit)

The script reuses the meta data extraction, that I wrote last week, to initialize a font repository with the data from the old googlefontdirectory.




It also has an interactive mode to check and change what goes into the font:



Result:

2. What I'll do tomorrow:

Finish Nunito, hopefully start the next font.

3. Questions for the team:

Nope

L.

[Lasse Fister]

1. What I did today:

Nunito had an upstream by Vernon so I forked it and copied the directory
structure to it.
Finished bringing Nunito into Glyphs:
https://github.com/graphicore/NunitoFont/tree/cleanup

Added a more detailed "Report Compattibility by Numbers", inspired by
Tosche, to my Glyphs-Scripts repository.

Added two obligatory lines to the README in the font directory template:
* Improve README.md
* Run fonts through Fontbakery and ship fonts.

2. What I'll do tomorrow:

Work on Questrial

3. Questions for the team:

@Dave: Nunito has an upstream GitHub, but it is not maintained. My fork
now has a `cleanup` branch, where to put it for Jaques?
Maybe you could fork https://github.com/vernnobile/NunitoFont to
googlefonts and then I could make a PR.

@Dave: Nunitos font info has a "trademark" key. I did not touch it. What
to do there?

[Dave Crossland]

On 2 August 2016 at 20:59, Lasse Fister <la...@graphicore.de> wrote:

@Dave: Nunito has an upstream GitHub, but it is not maintained. My fork
now has a `cleanup` branch, where to put it for Jaques?
Maybe you could fork https://github.com/vernnobile/NunitoFont to
googlefonts and then I could make a PR.

Forked! :) 

 

@Dave: Nunitos font info has a "trademark" key. I did not touch it. What
to do there?

Leave it in

[Lasse Fister]

1. What I did today:

My first day after vacation. I had a hangout with Marc who brought me up
to speed with what happened the past two weeks.

I was reading the documentation and new glyphs scripts made by Marc and
tried to catch up in general.

2. What I'll do tomorrow:

Prepare Josefin Sans.
Probably make some contributions to Marcs scripts and docs.

3. Questions for the team:

-

L.

[Lasse Fister]

1. What I did today:

> Prepare Josefin Sans.

Did this: https://github.com/graphicore/JosefinSansFont

> Probably make some contributions to Marcs scripts and docs.

I did not commit anything but I ran in a few nasty bugs using Marcs
scripts . Seems like it comes from within Glyphs and must be fixed
there. I was able to work around, but want to collect a bit more
information before reporting this to Georg.

2. What I'll do tomorrow:

Investigate those Glyphs script bugs.
Prep more fonts.

[Lasse Fister]

0. What I did yesterday

Sorry for not writing m report yesterday.

Yesterday I started working on the issues in the "Bugs in Font Files" milestone https://github.com/google/fonts/milestone/4

I started probably with to high expectations and soon got lost in picking bugs worthwhile to tackle and finding out how to start it.

I did not get much done in the end of the day, a least I asked for more information on the issues I picked:

https://github.com/google/fonts/issues/253#issuecomment-243185318

and 

https://github.com/itfoundry/poppins/issues/5

Also I installed dependencies like hindkit.

I think I will try to avoid bugs in itf fonts in the closer future. For one, they are actively maintained, so we can't just go there and apply our glyphs based tooling (hindkit is a ufo-workflow) and for another, hindkit is also still in flux, so some of the fonts are currently not in sync with it and there's a lot more to do than just fixing a bug.

One way of cooperation would be to also join the hindkit development efforts and try to blend some of our ideas of project engineering. Much more work than hammering out some bugs though.

Also on Friday I wrote:

> Seems like it comes from within Glyphs and must be fixed there. I was able to work around, but want to collect a bit more information before reporting this to Georg.

This was me running the stable Glyphs version 2.3. the latest cutting edge does not show the problem anymore.



1. What I did today:

I "fixed" a bug by pointing out that it can't be reproduced no lo longer: https://github.com/google/fonts/issues/60#issuecomment-243403677

I sent a PR for one of the bugs in Poppins I set out yesterday to fix: "Low double quotation mark (99) is missing"
 https://github.com/itfoundry/poppins/pull/6

Turns out it was not missing, it had two comma components but both on the same position. I tried it out and found that this is the default result when Glyphs generates "quotedblbase".

This is an easy one to overlook as a human but also an easy one to find for a computer, so, I contributed a script to Marcs mf-glyphs-scripts/QA/Check Font tool, that detects if two or more components of the same type share the same transformation/position

PR: https://github.com/m4rc1e/mf-glyphs-scripts/pull/10 (merged already)
Function: https://github.com/m4rc1e/mf-glyphs-scripts/blob/master/QA/glyphs.py#L43

Then I digged again in the bugs to find the next one to tackle. Decided to go for all bugs of Amatic SC: https://github.com/google/fonts/issues?q=is%3Aopen+is%3Aissue+label%3Az_Amatic_SC
Forked Vernons repository and began to port the sources to glyphs here: https://github.com/graphicore/MaticFonts.



2. What I'll do tomorrow:

AmaticSC

Find me another bug.



3. Questions for the team:

 -

L.

[Lasse Fister]

Admin: Last week after our NYC workshop I've been to Berlin and did some other stuff. So, I added one week of me being on the project to the end of the projekt calendar.

I'll continue to do this log regularly again for the next weeks.

1. What I did today:

I picked up work on the SpecimenTools again, wich will be used in our font specimen page.
Repo: https://github.com/graphicore/specimenTools

We can now get a character coverage number for each font using data from the Unicode CLDR (Common Locale Data Repository).

It works quite nicely, though, one question is below.

2. What I'll do tomorrow:

If there is another task that involves getting information out of font files, related to our planned specimen tools, I'll make that happen.

I want to start to use the tools in a realistic setup. That means a specimen website using google material design light (https://getmdl.io/).

This will probably become a new repository, which besides having all the specimen building blocks will also define the "skin" for the SpecimenTools.

As a good example, http://overpassfont.org/ will probably inspire me for the tools a bit.

3. Questions for the team:

Regarding the language coverage, we have a lot of 99% cases my sample fonts see: https://graphicore.github.io/specimenTools/html/font-data.html

The first font: Jura-Medium.ttf under "Language Coverage":

French: 99 % 113 of 114 missing: U+2010

U+2010 is the "Hyphen" and the CLDR data expects it obviously to be present. The font has a U+002D HYPHEN-MINUS

I included the "missing: U+...." information for fonts with a coverage of 90 % and above. Please have a short look yourself.

So the questions are: What now?

Is the hyphen missing (and maybe also the other code points) and the fonts are incomplete and must be fixed?

Is the CLDR wrong and we need a manual fix in the code?

Best, L.

-- 
Lasse Fister

Tel.: +49 (160) 949 106 15

Glückstraße 7
90763 Fürth

Visit www.graphicore.de

[Alexei Vanyashin]

Should we really run "Correct Path direction for whole glyph set" in 
interpolated projects? It seems to me that it does more harm than good. Though, with the new scripts, I think the effort can be done. 

I agree that correct path direction may do harm. 

When I ran it on the whole glyph set hoping it would fix bad path direction issues, 

but instead is made a lot of component incompatible — because the starting node changes. 

I use your script instead of the built in glyphs function. 

3. Questions for the team:

Regarding the language coverage, we have a lot of 99% cases my sample fonts see: https://graphicore.github.io/specimenTools/html/font-data.html

The first font: Jura-Medium.ttf under "Language Coverage":

French: 99 % 113 of 114 missing: U+2010

U+2010 is the "Hyphen" and the CLDR data expects it obviously to be present. The font has a U+002D HYPHEN-MINUS

I included the "missing: U+...." information for fonts with a coverage of 90 % and above. Please have a short look yourself.

So the questions are: What now?

Is the hyphen missing (and maybe also the other code points) and the fonts are incomplete and must be fixed?

Is the CLDR wrong and we need a manual fix in the code?

There is a clash in naming conventions. 

What we currently use as default in GF Latin Plus:

<glyph unicode="002D" name="hyphen" category="Punctuation" subCategory="Dash" description="HYPHEN-MINUS" />

To make CLDR happy we can add another glyph `hyphentwo` to the glyphs app filter lists

<glyph unicode="2010" name="hyphentwo" decompose="hyphen" category="Punctuation" subCategory="Dash" production="uni2010" description="HYPHEN" />

 

[Alexei Vanyashin]

Vietnamese: 100 % 217 of 218 missing: U+2032
Welsh: 99 % 129 of 130 missing: U+2032
Catalan: 99 % 110 of 111 missing: U+2032
Portuguese: 99 % 109 of 110 missing: U+2032
Spanish: 99 % 107 of 108 missing: U+2032
Dutch: 99 % 106 of 107 missing: U+2032
Afrikaans: 99 % 105 of 106 missing: U+2032
Polish: 99 % 100 of 101 missing: U+2032
Latvian: 99 % 99 of 100 missing: U+2032
Galician: 99 % 97 of 98 missing: U+2032

From this out I see that Polish is missing a prime. 

That doesn't make sense to me.

Prime is part of GF Latin Pro, but not Latin Plus. IMO it isn't required for Polish, and other languages support. It is typographical finesse. 

If this is a big problem we can more the prime to GF Latin Plus to claim that these languages are supported by CLDR.

 

[Lasse Fister]

1. What I did today:

Started with Material Design Lite for the specimen. I think MDL is nice
to work with but unfortunately I did not get very far. This will be the
home: https://github.com/graphicore/mdlFontSpecimen contains only stubs now.

Also: Helped to get the tip of Montserrat back into its own repository
at: https://github.com/JulietaUla/Montserrat

2. What I'll do tomorrow:

Keep on doing mdlFontSpecimen

3. Questions for the team:

-

[Dave Crossland]

Thanks Lasse! Would be good if you can sync up with Yuin on this MDL specimen page stuff :)

I see CLDR as a good starting place; I would be happy if you could add a simple way to 'overlay' adjustments (+/-ve) to its definitions, such that these 99% cases can be cleaned up . 

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/3d6b175f-22bf-3548-ea1d-afda9dec189e%40graphicore.de.

For more options, visit https://groups.google.com/d/optout.

--

Cheers
Dave

[Alexei Vanyashin]

Hi Lasse, 

I pushed my Jura specimen to git, 

if this may help

https://alexeiva.github.io/Jura-specimen/ (w-i-p still)

[Lasse Fister]

Amazing, you just read my mind! I am at the moment writing my daily report and was going to ask you for this.

Thanks.

L.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To post to this group, send email to googlefon...@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/19621fa7-161e-429d-82df-a0a88de54ba0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Lasse Fister

Tel.: +49 (160) 949 106 15

[Lasse Fister]

On 19.10.2016 06:45, Dave Crossland wrote:
> Thanks Lasse! Would be good if you can sync up with Yuin on this MDL
> specimen page stuff :)

OK, can you connect us please, hangout maybe?

> I see CLDR as a good starting place; I would be happy if you could add
> a simple way to 'overlay' adjustments (+/-ve) to its definitions, such
> that these 99% cases can be cleaned up.

Sure, I'll do. Not sure where and how yet.


What I did today:

There are two repos right now: specimentTools and mdlFontSpecimen.

specimentTools has more or less the raw widgets code without any fancy
markup or css-styles.

In mdlFontSpecimen I'm working on integrating the specimentTools into the
material design lite environment and on creating a base for all our
specimen needs.

The most work happened in specimentTools today when I started to
integrate the GlyphTable into mdlFontSpecimen.

I added a mechanism to set some options for our speciment widgets, like
custom class names. I changed the font loading code to be more flexible,
specifically, I added a signaling/pubsub module that signals the widgets
to get them initialized.
We'll also use it inter-widget communication e.g. to change the fonts in
the glyph table or type tester and such.
I made a stand alone, yet primitive, font-selection interface (was part
of glyph table before, now it communicates via the pubsub thing.

I'm now loading all fonts before initializing the glyph-table, this way
I can determine the max dimensions needed for all glyphs in all fonts.
So, switching fonts doesn't change the table layout.
Maybe we could initialize the first table as early as possible and then
re-render when the global dimensions are available, so the time until
something is on the screen is lower.

What I'll do tomorrow:

Maybe: Fix Japanese fonts?
Sync with Marc.
Continue on specimen.

Questions for the team:

-

Best, L.

[Lasse Fister]

What I did yesterday:

Synced with Marc.
Started "FamilyControlInterface" which will be our font switching widget.
It's smart enough to looks at the list of loaded fonts, orders them by
family, detects italics and romans that belongs together and then builds
the interface.
The aim is to keep the configuration effort low for this.

What I did today:

More hangouts.
I worked on integrating the FamilyControlInterface into MDL. One thing
that took a bit of time was to figure out how to control MDL elements
from JavaScript.
We now use mdl-button, to switch between weights and mdl-switch to
switch between roman and italic.
The rest of the widget still needs a bit more markup/css to be a proper
MDL-wiget, but that's not too much to do anymore.

What I'll do tomorrow:

Bit more FamilyControlInterface tuning.
Go on to add widgets that read data from the font (language coverage,
features etc.) We already know how to get the information, now it's time
to use it.
I'll have to master some fonts.

Questions for the team:

-

Best, L.

[Dave Crossland]

On 21 October 2016 at 18:00, Lasse Fister <la...@graphicore.de> wrote:

Bit more FamilyControlInterface tuning.
Go on to add widgets that read data from the font (language coverage,
features etc.) We already know how to get the information, now it's time
to use it.
I'll have to master some fonts.

Sounds great!

[Lasse Fister]

I'll master these: Arima, Lalezar, David Libre

@all: Can any of you point me to the current, latest repositories for these projects?

@all: What's the status of Libre Bodoni

@Alexei: will you master Arsenal?

[Alexei Vanyashin]

Hey Lasse,

I have already mastered Arsenal. 

[Lasse Fister]

>
> I have already mastered Arsenal.

Great! Can you note that in the Pipeline sheet? That row is still empty.

[Pablo Impallari]

Hi Lasse,

> @all: What's the status of Libre Bodoni

Nhung submitted a Pull Request https://github.com/impallari/Libre-Bodoni/pull/10 but I can't merge yet because it has lots of problems.

2016-10-21 19:37 GMT-03:00 Lasse Fister <la...@graphicore.de>:

>
> I have already mastered Arsenal.
Great! Can you note that in the Pipeline sheet? That row is still empty.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/f848d315-9bfb-7750-c0ad-7c2c0b7202fb%40graphicore.de.

For more options, visit https://groups.google.com/d/optout.

--

Un Abrazo
Pablo Impallari

[Lasse Fister]

Sorry @all for not updating daily. I was a bit absorbed by the specimen
tools project, which comes out nicely as I think.


What I did this week:

I made a lot of improvements to the specimen tools, check yourself the
current state here:

https://graphicore.github.io/mdlFontSpecimen/

I made a central module to get information from the font to show
(FontsData). This is used by many other widgets that display info about
the fonts.

There is a minimalistic "GenericFontDataWidget" which displays data
directly from FontsData, works only with simple text like information.
E.g. to show all supported languages It is initialized like this :

<div class=" mdlfs-font-data mdlfs-font"
data-getter="SupportedLanguages"></div>

I made a module that makes the fonts loaded via Ajax available as web
fonts, via CSS.

And I made CurrentWebFontWidget which sets the CSS to show the currently
active font as webfont (font-family: ...), used like this on any element:

<span class="mdlfs-current-font" contenteditable="true">Hello</span>

I extracted some data about OpenType features from the microsoft specs,
so that I can use them on a more informed base i.e. at the moment to
decide weather a feature is on by default or optional. Module:
OTFeatureInfo.

I made a TypeTester widget, wich provides a font-size selector and a OT
features interface. The latter uses just the features found in the font
of course.

I improved the loading style of the GlyphTable to not block the UI
anymore (by using gradual rendering of glyphs and
window.requestAnimationFrame)

On click on a glyph in the GlyphTable it will be enlarged.

All the Widgets are used and activated using html with special classes.
So I think the mdlFontSpecimen script will be one drop in scripts in the
end. This will make it a blast to build custom specimen that use some or
all of the provided widgets.


What I do next/tomorrow:

I need to add some more widgets that demo what the features do (like if
we have smallcaps, show a smallcaps demo card) I'll probably do this
today. Since now there's OTFeatureInfo and FontsData prepared to handle
features, it shouldn't be hard to do anymore.

Then, the mdlFontSpecimen project needs to be build into one single
file, Also we need some docs. At the moment, looking into:
https://github.com/graphicore/mdlFontSpecimen/blob/master/index.html is
the only doc there is.

I'll work on some font mastering.


Questions to the team:

None

[Dave Crossland]

On 28 October 2016 at 09:07, Lasse Fister <la...@graphicore.de> wrote:

https://graphicore.github.io/mdlFontSpecimen/

Nice! 

I think the top bar is meant to be position:fixed on scroll, like material.io

--

Cheers
Dave

[Lasse Fister]

I think MDL has several styles for this. It was just copy paste from the docs in this case. I'm currently more concerned with making the widgets work together with MDL where actually sliders/buttons/switches are used, because these need to be controlled via the MDL js interfaces.
For example, the ripple effect is there when you click on a button in the font selection widget, but it's still missing on the feature buttons in the type tester (booo! shame on me).

The general usage of MDL and making the specimen comply to Material can be easily done without writing javascript in the end, at least so I hope ;-)

[Lasse Fister]

What I did today:

We now have a "FeatureDisplay" widget. The idea is that we can make a
small widget for each (at the moment optional) OT Feature, to show what
it does and that it is in the font. By the way, in general we are
limited to GSUB features, becuause there's no GPOS support in
opentype.js yet.

I'm using only the optional features because the default ones are
usually not meant to be switched off. Also, we can switch off default
features in the TypeTester.

So far this new widgets works. The example texts must be present in the
OTFeatureInfo widget to make it possible to display a feature. Also, I
think we'll need a configuration option for these texts, so that we can
change them to something more appropriate if the fonts used require it.

Not all possible features have texts yet, in fact there are many
missing. I think this can be added over time, because the changes to add
an example text are simple and we'll have a config-option eventually
anyways.

I also did some cleaning up and restructuring.

What I'll do tomorrow:

I'll prepare the specimen projects for being reviewed, this includes a
build script.

I hope I'll be mastering soon again.

Questions to the team:

None

[Lasse Fister]

What I did today:

I made a build script for mdlSpecimenTools (builds
mdl-specimen-tools.js/css), so that we have a one script drop-in solution.
I also added a README with some useful information and I cleaned up a
lot, so that the repo can be reviewed.

Latest version (using the single script approach mdl-specimen-tools.js):
https://graphicore.github.io/mdlFontSpecimen/
This only uses the fonts of one family—Raleway—as this is the default
use case.

I also fixed some bugs and started to clean up a bit in specimenTools.

What I'll do tomorrow:

specimentTools needs more clean up and preparation for review: docs,
more README etc.

A design review for mdlSpecimenTools is planned.

I think this is already a good tool to find bugs in fonts and
font-families. I found a subtle bug today in Raleway (which is also
already fixed by Alexei!)
where the font family switcher would not let me select all loaded fonts,
because one font had a wrong OS/2 weight class.
I'd like to add a mode/version where the fonts for the specimen can be
dragged into the browser (similar to Pablos testing page) If I find the
time, I'll do this as well tomorrow.

Questions to the team:

None

Cheers L.

[Pablo Impallari]

Hi Lasse,

That version of Raleway that you are using there, it have some kerning issues, please use the latest stable one https://github.com/impallari/Raleway/tree/master/fonts/v3.000%20Fontlab

[Lasse Fister]

What I did today (and yesterday):

- polished the two repos I'm working on, so that it is easier for a
reviewer follow whats happening.
- received new design instructions.
- reviewed a similar project http://fontsampler.johannesneumeier.com/
- added a load progress indicator to the specimen at
https://graphicore.github.io/mdlFontSpecimen so that we don't have to
stare at uninhibited template artifacts while loading fonts.
- added a specimen that waits for fonts to dropped onto it at:
https://graphicore.github.io/mdlFontSpecimen/html/drop-fonts.html enjoy!

What I'll do tomorrow:

I received layout guidelines, I'll start to implement them.

Questions to the team:

None

Best, L.

[Dave Crossland]

Thanks Lasse

[Lasse Fister]

Hi all!

I'm well behind with reporting, so here a short one: The last week and this week I was working on implementing js-widgets for a design made for our font specimens.

We talked on a hangout about one specific widget an I have some issue implementing it, what follows is a discussion of that.

Long email ahead, sorry about that. It's about the character sets/languages display.

Yesterday I started to figure out how we can relate the char-sets Dave sent me,a spredsheet called "Character Set Samples (per script)" to the languages that we can detect (using CLDR data).

I'll relate to the char-sets in the spreadsheet as "google char-sets" and to the char-sets for language detection with CLDR as "language" and to the char-set that is contained in the font just as "font", as if a font or language was just a char-set and nothing else.


The initial idea was that we

a) have  a list of all supported google char-sets (google char-set ⊆ font)
-> that is all the google char-sets that are subsets of the font

b) next to each google char-set a list of languages that are supported by that char-set (language ⊆ google char-set) and (language ⊆ font)
-> that is all the languages that are subsets of the google char-set and subsets of the font.

c) That we can count all the languages next to the google char-sets and come to the same number as the number of languages that we can detect.


Problems with this so far:

• The languages char-sets are often super sets of the  google char-sets and the google char-sets don't cover all languages.
• things like German (ä), French (é) or Spanish (¿) are not included in "Latin Extended"
• we can't write all the supported languages next to the char-sets and end up with a list of all supported languages that we can detect.
• The google char-sets are badly documented:
•  minimal requirement seems odd, need explanation: Weather or when to use the "full" or the "minimal" sets is not clear
• symbols/numbers "if different than Latin", does this mean Latin symbols and numbers must always be included?
• The languages contain some chars that may actually not be that necessary to write in a certain language. e.g. not in the google char-sets but in the language English: ‐–—…'\"†‡′″: hyphen u2010, en-dash, em-dash, elipsis, apostrophe u+0027 (this is even in ASCII!), quotation mark u+0022 (also in ASCII) dagger, double dagger
  Maybe we need to add some more "lax" exceptions, we already have one for hyphen, because we expect hyphen-minus to be present.
  

If our aim is to find all languages that we can detect next to all char-sets that we can describe I think we have a problem:

We'd need to define new char-sets based on the languages, at least on the "lax" versions of these. The goal is that we would cover each language with one or more char-sets.

The one inherent problem with this is, if the char-sets grow too big a font may not support a char-set, but a language that is supported by the char-set (char-set > language). This is basically the inverse problem that we have right now (language > google char-set)

What we could do, though, is to kind of "decouple" it and make some of the constraints, (language ⊆ font), (language ⊆ char-set) and (char-set ⊆ font) disappear.

So we, could show all the chars of font that are in the char-set, but not necessarily the complete char-set (only the intersection char-set ∩ font). Detected languages would be assigned to a char-set that fits the expectation, we'd need to figure this out in detail. The meaning would be: "We found these chars that are contained within this char-set." not "The font supports this entire char-set".

Since our google char-sets are insufficient in many ways, but the naming is similar, I propose we illustrate unicode coverage on a per unicode-block base see https://en.wikipedia.org/wiki/Unicode_block for a list.

I.e. we would print per Unicode Block that intersects with the font the intersecting characters. And, next to the most appropriate block the languages supported by the font. E.g. next to "Latin-1 Supplement" we'd probably find "French" and "German" etc.

We don't have to use Unicode Blocks, of course, and could come up with our own char-sets. But this is at least something that uses a common standard that people can relate to.


Tell me what you think!

Best, Lasse

[Dave Crossland]

The samples are just the chars used in fonts. Google. Com.... I'm not sure this is a good direction at all. Can you confirm the exact request from me? Was it written or just discussed on a call?

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/85487dc1-55f5-0887-c4dc-7b1463d4aceb%40graphicore.de.

[Lasse Fister]

On 20.11.2016 19:36, 'Dave Crossland' via Google Fonts Discussions wrote:

The samples are just the chars used in fonts. Google. Com.... I'm not sure this is a good direction at all. Can you confirm the exact request from me? Was it written or just discussed on a call?

It was discussed in the last call. In the design mocks from Yuin we have this section "languages", the very last at the bottom (I don't know if I it's OK to post this here, or parts of it, Yuin sent it via Email to us). The section shows four blocks "Cyrillic", "Cyrillic Extended", "Latin", "Latin Extended" each showing the chars of these sets.

I argued that this are not really languages, but rather char-sets. But apparently that's what's used as "Languages" in fonts. google. com. The reasons why you called it languages and not char sets or such was that users understood languages better, I think. The reason why Yuin used these char-sets was to use the same sematics the fonts. google page uses.

I think Omer said, in the long run there should be some fix of the language/char-set issue (that your char sets are not really languages, e.g. "Latin Extended" is no a language). And I think pretty much at that point we developed that idea of putting the actual names of languages supported by each char-set next to it. Best talk to Omer, maybe I got something wrong?

The idea was that we can detect that a font supports say 40 languages. We put that number somewhere (or not). When we go down to the "Languages" section and count the names of languages next to all char-sets, we should end up with 40.

There was no written request from you, rather a conversation you took part in. I don't think we have recorded it. At the end we agreed that I will try to correlate the CLDR based language detection with the data of that google-char-set spreadsheet. Which I did—the trying—and I couldn't make it work. Thus my last email, reporting what I found out.


Best, L.

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To post to this group, send email to googlefon...@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAOgqPYc9UodRQ86GfJww8yqOggDk9ua%3DZ42Ov-10LfL4Kme%2B9A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Lasse Fister]

What I did:

I finally got the FeatureDisplay widget reworked. Now we can create all the OT-feature samples that we have in the mock design. I was a bit stuck with this and thus went dark for a while. One of the aims was to make this easily configurable, but since there are a lot of subtle exceptions that is not really the case now. Maybe we need a higher level abstraction eventually or we may refactor it once again, when know more about our needs.

This is the features part of the mockup:



This is straight from my browser:




Some remarks:

Stylistic Alternates:
This is a live generated SVG. I included two letters "l" (lower case L) because I have currently two ways to display the letters. The more easy one to set up uses the svg <text> element and the OT-features via CSS and lets the browser do the shaping, which is pretty straight forward. But for the "l" this fails, because in this case the side bearings for the two glyphs differ and thus the stems do not align well, see the small white gap in the first "l" drawing. So, second method to draw these letters is drawing it ourselves, using the <path> element and the pen-protocol. In this case, the setup needs the two glyph-names to be drawn, and also instructions how to align (left, center, right)

Currencies:
This is not a Open-Type feature, it's placed there in the mock to look good, but it's not covered by the FeatureDisplay widget obviously. I can either figure out another special treatment or we could change the design. The problem with this kind of things is that the configuration gets harder and harder, but one of our aims was to make it mostly automatic and easy to configure. We'll have to figure out a balance between easy to configure and versatile for the designer, but it pretty much seems to me this are different poles.

Tabular figures:
Shouldn't the dot be spaced to figure width when this feature is on?

Tabular Old-Style Figures:
I don't know this feature. Need to investigate, maybe it's in an stylistic set or just a mock.

Subscript/Superscript
This needed very special treatment, apparently, in the H2O superscript example, H and O also have superscript forms. I made an option that only applies the features to the highlighted glyphs for this.

The features with the arrow in it:
This widget has a semi automatic mode (can be turned of of course), where you can specify how a feature should be displayed, but if it is not specified for an existing feature it will choose to show the default (if available) as fallback. Not all defaults are defined, so in this font (WorkSans) are still more features than we can see here.


Here is the setup that it took to generate the items as above: https://github.com/graphicore/mdlFontSpecimen/blob/d5367eb3ed989d5ad90e1c40d35966c4a37f1f9b/lib/main.js#L105


a simple one looks like the swsh widget:

{
    weight: '-9.97'
  , contents: [
        {
          type: 'text'
        , features: 'swsh'
        , content: '*A*f*t*e*r* *M*us*ty*'
        }
    ]
}

It has only one content and theres a simple markup with asterixes * to mark highligted parts, inspired by markdown of course.

a more complex one is the sups/subs widget:

{
    weight: '-9.95'
  , addClasses: [
          'mdlfs-feature-display__item__content_inline'
      , 'mdlfs-feature-display__item__content_inline-no-gap'
    ]
  , contents: [
        {
          type: 'text'
        , features: 'sups'
        , content: 'H*2*O '
        , featuresOnHighlights: true
        }
      , {
          type: 'text'
        , features: 'subs'
        , content: '(Z*9*'
        , featuresOnHighlights: true
        }
      , {
          type: 'text'
        , features: 'sups'
        , content: 'X*6*'
        , featuresOnHighlights: true
        }
      , {
          type: 'text'
        , features: 'subs'
        , content: 'W*3*)'
        , featuresOnHighlights: true
        }
    ]
}

We need to apply special CSS-classes (the first one should maybe be the default, but the second one is needed)
We have four content blocks with alternating features.
We use the "featuresOnHighlights" options.

Here is the one for the Stylistic Alternates, which uses ss01, ss02, ss03 and ss04:


{
    friendlyName: 'Stylistic Alternates'
  , weight: '-10'
  , removeClasses: ['mdl-cell--4-col']
  , addClasses: ['mdl-cell--6-col']
  , contents: [
        {
            type: 'stacked'
          , features: ['ss01', 'ss02', 'ss03', 'ss04']
          , content: ['G', 'g', 'R', 'l', 'outline! l:l.ss02, align:left']
          , behavior: 'mixed'
        }
    ]
}

The friendly name is usually generated using the feature name, but in this case we have four features and their names are not very friendly as well ("Stylistic Set" 01 etc.)
It's wider than the other samples so we need to add and remove CSS-classes for the grid setup.
The "stacked" type generates this kinds of SVG images.
The "behavior: mixed" says we have "webfont" or "outline" items. I described this above, "webfont" uses <text> and CSS featurs. "outline" draws manually and needs to know two glyph names to draw.


So this is pretty much the extent of configuration that we encounter here.

What I'll do next:

I'll take care of the  responsiveness.
 

Questons to the Team:

@dave: The languages issue is still undiscussed, see below the quoted email for the last status.
Also, we could probably make a review mid next week?

[Dave Crossland]

Hi

Thanks for the update - lots of progress, this is good!

I'll set up some meetings next week to review and dive into the language thing

Cheers

dave

[Lasse Fister]

Hi Team,

I just finished moving from Fürth to Nuremberg (very central, if you need a place to stay just ask) and with today I got the biggest related backlog task crossed of my list (clearing/renovating the old apartment). This means I'll now return to mainly work on the specimen tools.

What I did last week:

End of last year we found out that I was looking at the wrong data, regarding the language issue.

Last week I had some days to dive again into the language detection issue. There's now a script that can detect the languages
supported by the encodings from https://github.com/google/fonts/tree/master/tools/encodings The detection is based on the CLDR.
One of the tasks will be to figure out how strict we take the CLDR. There are two ways to improve the reported language coverage:
a) ignore chars that the CLDR demands (either per encoding/case or in general)
b) add chars to the encodings, to properly meet the CLDR data

In the end, I think we can store the languages supported by each encoding and then just detect which encodings are supported by a font. This also means we could claim language support that is not backed by CLDR data, if needed for any reason.

What I'll do tomorrow:

The script I wrote also adds the possibility of a "header" to the ".nam" format. A .nam-file can define "#$ include filename" statements, so that we know encodings that are dependencies. I.e. typically a "pro" encoding would include its "plus" encoding and the latter would include its "base" encoding. The "header" data is stored in comments (lines starting with #) and thus fully backwards compatible. The intention is to make the encodings data more self documenting and computer processable. Other meta data could also be added, like for instance a human readable name for the encoding.

Depending on the discussion of the issue (linked below) I'd like to propose this header thing and also work on the the documentation of the .nam format. One other thing with the .nam format is that we now have chars contained that don't have a Unicode, accessed via GSUB in the end. This is not documented at https://github.com/google/fonts/blob/master/tools/encodings/README.md and so it should be mentioned as well.


Questions to the Team:

There's an issue I filed about how all the encodings are meant to be used https://github.com/google/fonts/issues/624
@dave @alexei I think I'll need a conversation with you to get my questions answered. I'd like to improve the documentation of the encodings directory eventually.

Where do you want these discussions to be made? I used the google/fonts issue tracker, but there was no reaction yet. We could also use the https://github.com/graphicore/specimenTools issue tracker or this mailing list or a mixture of github and list.


Best, Lasse

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To post to this group, send email to googlefon...@googlegroups.com.
Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAEozd0xX_%3DtfEov%2BQtGod2bYZR9yLVT-isEFBE3gsbcPc3Aiow%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Lasse Fister

Tel.: +49 (160) 949 106 15

Galgenhofstraße 12
90459 Nürnberg

Visit www.graphicore.de

[Dave Crossland]

Hi

Great stuff! 

I think you and Alexei should connect on this topic and decide the best thing :) 

Cheers,
Dave

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAEozd0xX_%3DtfEov%2BQtGod2bYZR9yLVT-isEFBE3gsbcPc3Aiow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Lasse Fister

Tel.: +49 (160) 949 106 15

Galgenhofstraße 12
90459 Nürnberg

Visit www.graphicore.de

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/29986c2a-9117-dcba-93e9-a9c0b4373abc%40graphicore.de.

[Lasse Fister]

What I did today:

I went ahead and started updating and extending the Namelist format documentation.

See: https://github.com/graphicore/fonts/blob/encodings_nam-format/tools/encodings/README.md
PR for discussions: https://github.com/google/fonts/pull/642

I also read into some code found in tools/util and got one of the questions of issue #624 answered, how the current including is handled: https://github.com/google/fonts/issues/624#issuecomment-278041775 I hope that code is the real thing.

What I'll do tomorrow:

I'm depending on the feedback I get, but I can improve on what I started today.
I also could port my js implementation of the header #$ include mechanism to python and put it into tools/util/google_fonts.py
I'd like to define the includes for the 2016 glyph sets and probably for the legacy ones as well as I now know how they work.
Then I want continue on figuring out how we'll do the language detection thing. I guess I'll have to improve my data and questions in order to make participating in the discussion easier, as I'm not getting answers :-)


Questions to the Team:

The first question of #624 needs answering, this is part of defining the proper dependencies for the 2016 glyph sets (but not a biggie probably).


Best, L.

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To post to this group, send email to googlefon...@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAOgqPYdk0uQs-xqLcB_MqpuVwDCdTYZJPE7%2B7e%3DQJCE3%3DE82bg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Alexei Vanyashin]

On Tue, Feb 7, 2017 at 12:53 AM Lasse Fister <la...@graphicore.de> wrote:

Hi Team,

I just finished moving from Fürth to Nuremberg (very central, if you need a place to stay just ask) and with today I got the biggest related backlog task crossed of my list (clearing/renovating the old apartment). This means I'll now return to mainly work on the specimen tools.

What I did last week:

End of last year we found out that I was looking at the wrong data, regarding the language issue.

Last week I had some days to dive again into the language detection issue. There's now a script that can detect the languages
supported by the encodings from https://github.com/google/fonts/tree/master/tools/encodings The detection is based on the CLDR.
One of the tasks will be to figure out how strict we take the CLDR. There are two ways to improve the reported language coverage:
a) ignore chars that the CLDR demands (either per encoding/case or in general)
b) add chars to the encodings, to properly meet the CLDR data

In the end, I think we can store the languages supported by each encoding and then just detect which encodings are supported by a font. This also means we could claim language support that is not backed by

I think we should move these glyphs from Pro to Plus for compatibility with CLDR:

0x2010  ‐ hyphentwo

0x02B9  ʹ primemod

0x02BA  ″ doubleprimemod

They are quick to design, and hyphentwo is a duplicate of hyphen.

For previously released fonts I suggest making exceptions for these mentioned glyphs. 

So, a double-edged sword solution for the compatibility issue. 

 

You received this message because you are subscribed to a topic in the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/googlefonts-discuss/x2oRYyP4gMQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to googlefonts-dis...@googlegroups.com.

To post to this group, send email to googlefon...@googlegroups.com.
Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/29986c2a-9117-dcba-93e9-a9c0b4373abc%40graphicore.de.

[Lasse Fister]

What I did today and yesterday:
 
- Defined the includes for the 2016 glyph sets and legacy ones as well
- Ported my js implementation of the header #$ include mechanism to python and put it into tools/util/google_fonts.py
- Wrote a test for the python implementation in tools/util/google_fonts.py to ensure the old `CodepointsInSubset` and the new `codepointsInNamelist` produce the same results.
- Fixed encodings/ethiopic_unique-glyphs.nam which had unicodes defined with lowercase chars, which is not permitted by the spec.

What I'll do tomorrow:

I see Alexei answered, so I'll communicate.
I'll continue figuring out how we'll do the language detection thing. I'll work on my data and questions in order to make participating in the discussion easier.


Best, L.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/73c5050a-c36c-a1e4-12c4-4dae92b6df43%40graphicore.de.

For more options, visit https://groups.google.com/d/optout.

[Lasse Fister]

What I did since my last report:

- Improved the tools/namelist.py script based on Alexeis feedback
- A lot refactoring in graphicore/specimenTools (services/FontsInfo and build/analzeCharsets.js) mainly to compare generic sets of code points with each other and to interpret the results.
- Added the facilities to export json-data from the encoding Namelists, so that we can figure out which charstets are supported by a font and which languages each of these charsets support.

The approach currently is a) match supported languages to GF-encodings b) match a fonts charset to the GF-encodings c) report the languages of the encodings that are supported by the font. This way we'll always get the same amount of languages for the fonts and the GF-encodings. We may need to tweak at this point a bit.

- Added a specimenTools widget that displays our char set info for a font (needs design direction)
- Made the PR #642 ready to assign it to Dave
- I updated the page at https://graphicore.github.io/mdlFontSpecimen/html/language-coverage-details.html so that we can see a lot more info for the reported coverage for a font (languages and charsets/encodings now) than in the specimen sample (this is mainly for debugging and inspection)
- I updated the specimen sample itself at https://graphicore.github.io/mdlFontSpecimen

What I'll do tomorrow:

- Start a PR to merge the specimenTools branch "languages" into master (https://github.com/graphicore/specimenTools/commits/languages) // depends a bit on #642
- I wrote down detailed question about the encoding/language coverage discovery complex and I'd like to ask them, needs some research still I think.
- Our GF 2016 encodings need some changes, I'll work on it: #660 and #624. Also, I'll probably open new issues.

I think we have now all tools in place to do this encoding/language support reporting properly. But, we'll have to work on the data that goes into the machine.

Questions:

@dave see https://graphicore.github.io/mdlFontSpecimen there's now a "Char Sets" section between "OpenType Features" and "Paragraph" This needs desing direction. Also note that WorkSans doesn't cover a lot of our encoding, only the legacy Latin one. Maybe we should switch to a font that supports our new encodings better?

I'll have more questions :-)

Best, L.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/46afb86d-d991-362b-c319-666522171d0b%40graphicore.de.

For more options, visit https://groups.google.com/d/optout.

[Lasse Fister]

What I did:

Asked: https://github.com/graphicore/specimenTools/issues/20 and started to implement it

I'm having a discussion with Thomas Linard at https://github.com/graphicore/specimenTools/issues/19

What I'll do tomorrow:

I need my questions answered, see below (and above).


Questions for the Team:

Sorry long text ahead. These are all the things I'm thinking about. Needs some decisions I think. After all this I hope I can finalize the specimen thing.
I'm posting all of this here, I may however spread some sections of this over GitHub issues. Just to give you a hint where I'm stuck at the moment.

The language detection issue I'm working on is unfortunately rather complex. This is because many prerequisites to solve the rather simple problem are not in place. Hence, I've been Yak-shaving for quite a while:

• Improving the Docs for our Namelist format.
• Trying to figure out how exactly those Namelists are going to be used.
• Defining dependencies of the different Namelists.
• Tooling the process of reading and analyzing Namelists and to compare them wit other char sets (=language coverage detection).
• Creating code to display the results of these analyses.

Now there are some questions left that I'm struggling to answer myself. Some are rather linguistic in nature, some concern how the novel char sets will be handled by the Fonts API. There are many pieces that need to be answered by different actors, so that we know in the end if everything is done the right way.

Namelists

includes

• Did I define the Namelist includes correctly in https://github.com/google/fonts/pull/642?
• We'll need a second pass on this for sure. I'd like to get #642 merged first though.

"technical" Namelists?

Also mentioned in https://github.com/graphicore/specimenTools/issues/19#issuecomment-282352868

Do we need a kind of "technical" Namelists to define common dependencies in a DRY manner OR should we rather define these common dependencies directly within the Namelist that needs them. I.e. See this section in the README of the Greek charsets:

GF Greek Pro:

N.B. List of characters from GF Latin Plus and Pro sets that are prerequisites to this set.

This means this charset needs characters from GF Latin Plus and Pro, but probably not the whole char set. So, how can we describe that to a computer, preferably via the include mechanism?

A) make a "technical" char set, that is only used to DRY in terms of dependencies, but not exposed via the Fonts API.

B) duplicate these chars and just include them in the char set.

Latin Core

My understanding is also, that GF Latin Core defines a lot of punctuation needed for other languages. Yet we don't have an explicit "GF-latin-core_unique-glyps.nam" file.

@davelab6 wrote:

Exactly. Core is what is served when only the Latin subset is served, the others are all more and more reaching into the Latin-Ext subset range. The

Latin subset (core) is a bug test for what is required to be in a font.

and @thlinhard wrote:

But Latin Core seems to exist only virtually. Probably this should be clarified.

So, I think its safe to say that we need a separate "Latin Core" file.

From Greek-Core, btw, these chars are missing according to the CLDR data:

0x0021 ! EXCLAMATION MARK
0x0022 " QUOTATION MARK
0x0026 & AMPERSAND
0x0028 ( LEFT PARENTHESIS
0x0029 ) RIGHT PARENTHESIS
0x002A * ASTERISK
0x002C , COMMA
0x002D - HYPHEN-MINUS
0x002E . FULL STOP
0x002F / SOLIDUS
0x003A : COLON
0x003B ; SEMICOLON
0x0040 @ COMMERCIAL AT
0x005B [ LEFT SQUARE BRACKET
0x005C \ REVERSE SOLIDUS
0x005D ] RIGHT SQUARE BRACKET
0x00A7 § SECTION SIGN
0x00AB « LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
0x00BB » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
0x0301 ́ COMBINING ACUTE ACCENT
0x0308 ̈ COMBINING DIAERESIS
0x2010 ‐ HYPHEN
0x2013 – EN DASH
0x2014 — EM DASH
0x2026 … HORIZONTAL ELLIPSIS

Of these: COMBINING ACUTE ACCENT and COMBINING DIAERESIS are not in the legacy latin_unique-glyphs.nam file, which is roughly equivalent to the novel core charset AFAIK.

filter-lists

See: https://github.com/google/fonts/issues/675

I often see references to the filter-lists in relation with my Namelist/Charset issues, yet I don't have a reliable answer on what exactly these Filter-Lists are and how I should process them. The only apparent use they seem to have is within GlyphsApp. If I should consider these when processing Namelists, I'd need docs or at least enough information on how to factor them in. These Filter-lists are bad for at least the fact that they don't include Unicodes. The names though could probably be mapped to Unicodes using GlyphsInfo/GlyphData, I hope.

CLDR

• I just found out, thanks to @thlinard that we do not include numerals in language support detection. That's bad. But we located the information in https://github.com/graphicore/specimenTools/issues/19#issuecomment-282357291
• @thlinard: "The list still lacks basic characters, like # % < > + = × ÷" do we need these?
• We are using "cldr-misc-modern" There's also "cldr-misc-full" which would detect more languages, but also make the loading times bigger.
• We are only using the main locales for language detection, e.g. "en, de, fr", we could detect more languages when including sublocales, eg. "en, en-us, en-br, ..., de, de-de, de-at, de-ch, fr, fr-cf ..." see the dirs here for example. We can also include just some sublocales specified manually. This would make the loading times bigger as well.

Fonts API

• Do we include the legacy encodings? How will the Fonts-API handle this? Maybe for the font's that get a specimen (quality improvement project fonts?), only the novel encodings are interesting?

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/e231e897-521d-4484-5463-4a52b5c2bd34%40graphicore.de.

For more options, visit https://groups.google.com/d/optout.

[Lasse Fister]

Hi all,

I'm currently preparing Roboto Slab for a round of creative revision this year. I had an interesting session today about converting quadratic splines to cubic splines and I want to share what I learned. First my original briefing:

The current release is very old, in the github.com/google/fonts repo, and no sources are available. Therefore it needs to be converted back to cubic/PS outlines, and set up such that it can be built in a simple way with fontmake.

I only worked on the quad to cubic task today, here's a small spoiler: from the briefing the "back" in "it needs to be converted back to cubic/PS outlines" seems to be wrong. At the moment I believe RoboSlab was hand drawn using quadratics, which turns out to be very favorable. Here's my journey:


First I made a new repository[1] and converted the TTFs to UFOs using extractor[2], the command for doing this turned out to be tiny [3]. Then I opened my newly created UFO in Trufont and was a bit surprised:




The controls looked very much like the cubic Bézier controls in every other editor out there (including Trufont). I was a bit baffled and reported back:

> To convert to cubics, Trufont seems to make a good job here, I'm currently trying to figure out how to use this in a script.

Then I started figuring and digging into Trufonts code. It was soon that I realized that I was in fact looking at quadratic Bézier curves with two off-curve points and one *implicit* on-curve point, that is always positioned in the center between the two off-curve points.

Here's FontForge, implicit points are not filled, and you can make them explicit by dragging them:


 

Can your cubics do this*:

(@Dave, you're right, this is a great feature of quadratics, but it's "rather" on the interface side than on the math side. And yes, since this is part of TrueType, it's great fun for variable font madness!)

You can also put more off-curve points between two on-curve points.

Can your cubics do this?**:



For the last image, I had to manipulate the a.glif file in an text editor, here's a screenshot:



(Actually the control points belong to the qcurve directly after the selection, don't be distracted.)

It was here that I realized that the font must have been edited originally as quadratic curves. Because, you see around my selection some x and y coordinates as floating point numbers. These I edited in Trufont, to find the position where I wanted to insert the extra points for this experiment. All the other coordinates in the file are apparently integers, perfectly aligned with the upm-grid.

I made a third test to verify my assumption; it's in the ufo-qu2cu script[4] via the `$ ufo-qu2cu info ...` command. The result looks like this:

*** TOTAL ***
qCurveTo 3: 2470
qCurveTo 2: 1
lineTo 1: 6209
moveTo 1: 753
closePath 0: 752
endPath 0: 1
addComponent 2: 1647

This accumulates all calls to the (Segment-) Pen-API of fonttools and counts the calls, separated by call and number of arguments. In all of RobotoSlab-Regulars paths we can find only one quadratic segment with 1 off-curve point (qCurveTo 2) but 2470 quadratic segments with 2 off-curve points.

My thesis is:

1. All coordinates as integers should cause rather big distortions of the final outline when going from cubics to quads, but the font looks good.
   
2. It should be rather hard to optimize cubic to quadratic conversion so that practically all splines (in all styles of Roboto Slab) turn out as as 2-off-curve quadratics.
3. Doing quadratics with 2 off-curve points by hand with a upm-grid-locked editor is easier than the above.
   

It could be that there is that great conversion, maybe if the cubics are crafted thoughtfully, but I tend to believe that these quadratics are human edited.

There's more on my way to cubics. Here's the result of running all of the font through the BasePen of fonttools, which automatically upgrades quadratics to cubics, via `$ ufo-qu2cu simple ...`[4].



This is a GIF switching between the simple converted version and the original (2 seconds). You won't find the the outline to be rendered differently and that's not a surprise: mathematically cubics can represent all (single control point) quadratics and technically the outline in Trufont is always rendered using BasePen. But, what happened is that our implicit on-curve points became explicit ones. This is rather a bit annoying for drawing, but still the best cubic description of the curve that we can have.

Playing a bit in Trufont, deleting some of these annoying mid-way on-curve points, I noticed that Trufont handles that pretty well. So I dug into the code (again) and found that the function `joinSegments` from `defcon.tools.bezierMath`[5] is used (thanks Frederik). So running our conversion through this via `$ ufo-qu2cu joined ...`[4] we get this:



The controls look seemingly better organized (the longer control handles are the cubic verision). However, when looking closely we can see that the outline is no longer true to its source. This is minimal and I don't know which one to choose, but I'd probably go with the latter cubic version; since the goal is a redesign these minimal changes in the outline shouldn't really matter.

This almost lossless conversion of outline and editing convenience was only easily possible because the source outlines had this clean high quality 2-control-quad style. The code I'm referencing[4] won't do anything special to upgrade a series of 2 1-control-quads. Also, if these 2-control-quads would go to their extremes, like in the "right angle" example above, this would probably fail big time. However, I glanced at all of the glyphs and it seems fine here.

So, which conversion to choose?


Footnotes:


* No, it does not work that way.

** Yes your cubics can do something like this! You just need to remove an Exception in ufoLib.glifLib and Trufont will allow to load it:





This works because fontTools implements a function called `decomposeSuperBezierSegment` in BasePen. It's rarely known and it seems like nobody uses (or used) it ever. It's also in the JavaScript BasePen[5] in case you wonder ;-)

Best, Lasse


[1] https://github.com/graphicore/RobotoSlab
[2] https://github.com/typesupply/extractor
[3] https://github.com/graphicore/RobotoSlab/blob/master/scripts/bin/ttf2ufo
[4] https://github.com/graphicore/RobotoSlab/blob/master/scripts/bin/ufo-qu2cu
[5] https://github.com/typesupply/defcon/blob/master/Lib/defcon/tools/bezierMath.py
[6] https://github.com/graphicore/Atem-Pen-Case/blob/master/lib/pens/BasePen.js

[Marc Foley]

Hey Lasse,

I don't think Roboto Slab was drawn with quadratic curves. The reason it looks so glorious is because of fontcrunch. Roboto's Makefile calls it for the android fonts.

[Lasse Fister]

I don't think Roboto Slab was drawn with quadratic curves. The reason it looks so glorious is because of fontcrunch. Roboto's Makefile calls it for the android fonts.

Interesting, thanks for the info! I didn't know fontcrunch. We don't have a makefile for RobotoSlab though. I'll try this out to reverse my conversion to see if it is that good :-) But yeah, the README says this is the purpose of fontcrunch.

[Denis Jacquerye]

You may want to have a look at https://github.com/googlei18n/cu2qu/pull/29

On Fri, 21 Apr 2017 at 15:42 Lasse Fister <la...@graphicore.de> wrote:

I don't think Roboto Slab was drawn with quadratic curves. The reason it looks so glorious is because of fontcrunch. Roboto's Makefile calls it for the android fonts.

Interesting, thanks for the info! I didn't know fontcrunch. We don't have a makefile for RobotoSlab though. I'll try this out to reverse my conversion to see if it is that good :-) But yeah, the README says this is the purpose of fontcrunch.

--

You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To post to this group, send email to googlefon...@googlegroups.com.
Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/c79652ad-377b-da5b-0c7a-299b0b706802%40graphicore.de.

[Lasse Fister]

More news from the RobotoSlab to UFO task. I thought this would go
faster, but that's how it is. I made some fun things though:

The process to convert the old RobotoSlab TTF files to UFOs made with
shell scripts[1]. Currently the call to convert a font looks like this:

$ init_ufo old/version-1.100263/RobotoSlab-Thin.ttf
sources/RobotoSlab-Thin.ufo

The more interesting part is however what is happening inside of init_ufo:

```sh
ttf2ufo $INFILE \
| ufo-importfea \| $INFILE --blacklist "GPOS" \
| ufo-qu2cu joining \| \
| ufo-glyphnames \| $OUTUFO --ufoFormatVersion 2;
```

$INFILE is the TTF-file
$OUTUFO is the UFO-Dir to write

I'm going to describe these commands in detail below, but first here are
some general remarks that are valid for all of the scripts.

For the CLIs of the scripts I'm using python-fire[2], a new library by
Google and I like it so far. It'll be first choice in the future, before
defaulting to pythons argparse.

What you may have noticed is that I'm piping (|) the results of each
script to the next one. In fact, the ufo is only written to disk by the
last command `ufo-glyphnames` before that it only exists in memory. I
like this approach, because it lets me cleanly separate concerns.

I remembered how otfcc[4] used pipelines for similar tasks[5] and I also
remembered that I implemented the defcon[3] serialization interface (for
undo/redo in Trufont back then) and that I was able to safe and load the
whole defcon object as a JSON in the end. This is not JSON, I'm using
the Python-pickle module instead, but it works nicely. So, yeah, shell
pipelines could be a nice feature for your tools as well, it would make
it easy for us to plug scripts together. At least if we can agree on
pickled defcon objects as format to modify UFO:

```py
# loading from stdin:
font = defcon.Font()
font.deserialize(sys.stdin.read())

# writing to stdout
sys.stdout.write(font.serialize())
```

In this case, the scripts expect a literal pipe character to go into
reading from stdin or writing from stdout. So in the call `ufo-qu2cu
joining \|` the \| is just an escaped pipe, This would also do the
trick: `ufo-qu2cu joining "|"`.


## ttf2ufo

This script uses extractor[6] to initialize a new UFO with data from a
OpenType font. I already mentioned it in my last post.

## ufo-importfea

Unfortunately extractor does not extract a features.fea file. So, for
this I resurrected an older project of mine "ft2fea-feature file
dumper"[7] now stand alone as extractFea[8]. As you can see in the
discussion of the older PR[7], we have since then quite a nice feaLib in
fontTools, but it still does not binary to fea. Also, I still kind of
like my query interface that I added to query and extract partial
features. I'd expect to switch with extractFea to a feaLib based
implementation, once we have implemented binary to fea-ast, but keep the
query interface. Also, maybe we can then put it altogether into extractor.

## ufo-glyphnames

This scripts renames glyphs into the friendly names provided by
GlyphInfo[9]. I'm using functions I wrote recently for
google/fonts/tools/util[10], unfortunately it's a mess right now to
include this dependency, even with my googleFontsTools[11] approach. We
should make a stand alone module for some of the stuff in
google/fonts/tools and depend on that in google/fonts. I'm not quite
sure where to make the cut though. (Should I think about it and make a
proposal? We had quite a similar problem[12] in pyfontaine recently!)

After the renaming of all glyphs I realized that glyph names are all
over the place in a UFO. So I'm also renaming glyphs in: groups.plist,
kerning.plist, lib.plist{public.postscriptnames|public.glyphorder} and
features.fea.

The only interesting one is features.fea. I'm using fonttools.feaLib.
For this I monkey patched the ast objects GlyphName and GlyphClass (yeah
evil, but maybe it can inspire a feature in feaLib). It's in the
function `update_features` of that script, if you are interested.

Oh, and all the scripts support an `--ufoFormatVersion` option, so if
you save your defcon object to disk as UFO, you can use this to make it
UFO 2 or whatever.


That's it for now. Best, L.

[1] https://github.com/graphicore/RobotoSlab/tree/master/scripts/bin
[2] https://github.com/google/python-fire
[3] https://github.com/typesupply/defcon/
[4] https://github.com/caryll/otfcc
[5] https://github.com/caryll/otfcc-cubic2quad#usage
[6] https://github.com/typesupply/extractor/
[7] https://github.com/fonttools/fonttools/pull/479
[8] https://github.com/graphicore/extractFea
[9] https://github.com/schriftgestalt/GlyphsInfo
[10] https://github.com/google/fonts/tree/master/tools/util
[11] https://github.com/graphicore/googleFontsTools
[12] https://github.com/davelab6/pyfontaine/pull/93

[Lasse Fister]

Hey all, it's been a while. Mainly because I started learning Kubernetes
(management software for cloud applications). I'll take care of the Font
Bakery dashboard in the next time.

Yesterday was busy though:

- I moved the files of Font Bakery Dashboard to
https://github.com/googlefonts/fontbakery-dashboard, I also removed
these files from the fontbakery repository
- We had a hangout about the next steps in Font Bakery development.
Since I had a closer look on the code in the last two weeks, I suggested
some changes.
- Erin did not see all of the Kerning in RobotoSlab, which I prepared
for her earlier. It turned out that MetricsMachine needs special kerning
group names. After we found the issue I updated the UFOs.

Yesterday/Today:

- I wrote down my proposal for Font Bakery with some central code
snippets:
https://gist.github.com/graphicore/9456bdbdaf1276b52e56fc817a175058 this
is the first version. It took me all night, so today I wont do so much
anymore. If you have any questions or remarks please write here or to me
directly.
- will start to update Mogra: https://github.com/google/fonts/issues/946

Tomorrow:

- Dashboard related things. I need to get it up and running from here.
There are many tasks waiting for me.

Best, L.

[Lasse Fister]

Yesterday/Today

- updated Mogra
- finally got a sane way to make a local, persistant docker registry for
minikube (for the fontbakery dashboard). Here is my log:
https://github.com/googlefonts/fontbakery-dashboard/issues/3
It's actually pretty straight forward :-)
- experimenting with the current state of fontbakery-dashboard

Next:

- getting started with dashboard development
- make an Roboto-Slab release, apply and understand Marcs Roboto release
tooling
- start fontbakery test runner code etc.
- another job (not sure if I can report here yet)

L.

[Lasse Fister]

What I did today:

- internal font testing in different applications
- I started implementing my Font Bakery proposal here:
https://github.com/graphicore/fontbakery/tree/refactor-architecture

What I'll do tomorrow:

- start Roboto Slab release (and get it done if possible)
- probably after: more Font Bakery proposal implementation

L.

[Lasse Fister]

What I did today:

- wrote an effort estimate for a project Dave asked me for
- started mastering Roboto-Slab:
* Dave asked me in the briefing to reproduce and understand Marcs
process for high profile fonts.
* Thus I enabled all external dependencies for fontbakery (I don't
know which ones Mark is actually using), but I was compiling stuff etc.
* Hopefully improved how fontbakey calls fontforge:
https://github.com/googlefonts/fontbakery/pull/1354
* I've built Roboto from the git repo, which took like forever.
* I'm comparing fontbakery output for Roboto and Roboto-Slab.

What I'll do tomorrow:

Continue with Roboto. Learning what Marc did will take me some time.

Questions to the Team:

@Marc, I'll chat to you

Best, L.

[Lasse Fister]

Sorry for being so quiet this week.

What I did:

Last Friday I PRed the updated roboto slab https://github.com/googlefonts/robotoslab/pull/3
On the weekend and on Monday morning I did some work on the new fontbakery test runner implementation, WIP here: https://github.com/graphicore/fontbakery/tree/refactor-architecture

Since then I'm working on bringing the fontbakery drag and drop interface back. Dave suggested it should take me 2 days (Monday, Tuesday) but unfortunately I'm still not done. This is because I decided to port the interface to the Kubernetes setup that will run the Font Bakery Dashboard on the Google Cloud Platform. In fact, on Tuesday I was just finished with planning my next steps and the new architecture.


This is good for several reasons:

1. It will be part of the Font Bakery Dashboard, thus I don't do it twice.
2. Less maintenance in the long run.
3. I can collect some experience with the setup.
4. We can include more of the external dependencies, like ots-sanitize or fontforge
   
5. We'll be able to create a much better user experience because we can use the rethinkdb change notifications to instantly report to the user. (After the fontbakery rewrite, we should be able to update the interface instantly, per test.
6. We'll have persistent links to revisit test reports.
   

To use the rethinkdb push notifications, I decided to implement the server with nodejs, because the event based model of nodejs makes it much easier to build this asynchronous messaging model. This will also be very nice to have for the other dashboard interfaces.

WIP here: https://github.com/graphicore/fontbakery-dashboard/tree/draganddrop

What I'll do Tomorrow:

So far the server is done, but not fully debugged. The font bakery worker code needs to be done, but that should be fast. The K8s needs to be set up. The client can not yet render the results, but for this iteration that's no big thing either.

Tomorrow I plan to get the server up and running, I guess I won't be able to equip the worker with all the possible external dependencies, but I hope to get the full test run and report cycle done.

Probably on the weekend I hope to get this done, so that I loose no more time on the big plan.

[Felipe Sanches]

Cool! Thanks for the update, Lasse! I'm excited to see what you'll come up with :-)

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/cbb9ad2a-7be1-a35c-1096-83f887640d5a%40graphicore.de.

[Marc Foley]

Hey Lasse,

Thanks for working on this web drag n drop interface. This will save me quite a bit of time since designers will be able to QA themselves.

[Dave Crossland]

Nice job Lasse! Please stay on this until its done :) 

[Lasse Fister]

What I did today:

I did a lot Kubernetes stuff and some debugging. All the K8s setup took me longer than I thought, so I lost some time on the worker that will actually run fontbakery. However, I started that as well, so the full request life cycle will be finished soon.

What I'll do next:

I'll keep on doing this until it's finished :-) Though, I won't do so much on the weekend.

Also, the production deployment will need a slightly different setup than the  local deveoping setup. I'd like at least have a plan for a clean solution in the end.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To post to this group, send email to googlefon...@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/cbb9ad2a-7be1-a35c-1096-83f887640d5a%40graphicore.de.
For more options, visit https://groups.google.com/d/optout.

[Dave Crossland]

Sounds great! 

[Felipe Sanches]

Cool! Thanks for the update, Lasse!

Let me take this opportunity to mention that I've been working on Inkscape's text layout code these days and I'll continue doing so during next week, aiming at adding some initial support for variable fonts rendering using harfbuzz. At this point it is hard to predict how long this will take, since I'm still wrapping my head around a large text-layout codebase (roughtly 25 pages of code on src/libnrtype/Layout-TNG-Compute.cpp alone). But I expect to have a better grasp of it during next week.

I expect to get back to FontBakery-Core on Monday, January 5th, hopefully reviewing your upcoming FB refactoring pull request.

cheers!

2017-05-26 18:58 GMT-03:00 'Dave Crossland' via Google Fonts Discussions <googlefon...@googlegroups.com>:

Sounds great! 

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAOgqPYca%3D4etqR6PfY8Lopjcc-jXJ4awcNj-23Fk3BGXCEQeGg%40mail.gmail.com.

[Felipe Sanches]

I actually meant June 5th, of course ! :-D

2017-05-26 19:14 GMT-03:00 Felipe Sanches <ju...@members.fsf.org>:

Cool! Thanks for the update, Lasse!

Let me take this opportunity to mention that I've been working on Inkscape's text layout code these days and I'll continue doing so during next week, aiming at adding some initial support for variable fonts rendering using harfbuzz. At this point it is hard to predict how long this will take, since I'm still wrapping my head around a large text-layout codebase (roughtly 25 pages of code on src/libnrtype/Layout-TNG-Compute.cpp alone). But I expect to have a better grasp of it during next week.

I expect to get back to FontBakery-Core on Monday, January 5th, hopefully reviewing your upcoming FB refactoring pull request.

cheers!

2017-05-26 18:58 GMT-03:00 'Dave Crossland' via Google Fonts Discussions <googlefonts-discuss@googlegroups.com>:

Sounds great! 

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsubscribe...@googlegroups.com.

To post to this group, send email to googlefonts-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/googlefonts-discuss.

[Dave Crossland]

On 26 May 2017 at 18:14, Felipe Sanches <ju...@members.fsf.org> wrote:

I expect to get back to FontBakery-Core on Monday, January 5th, hopefully reviewing your upcoming FB refactoring pull request.

Lasse suggested on chat a moment ago that building the new test runner he has in mind and other infrastructure stuff will maybe take 2 weeks more, not 1, being realistic: Porting tests should probably be done by all of us and peer reviewed, we should aim to get rid of some technical debt at the same time. But we can organize this flexibly :) 

[Lasse Fister]

Hi all,

sorry for not reporting this week.

What I did:

Monday: more debugging.
Tuesday: summer planning/more debugging.

Since then until yesterday even more debugging and cleaning the server and worker code up. This was a pretty rough ride but I learned a lot (my database had split brain syndrome, stuff like this) I'm a bit annoyed that my time estimates, to get to this point where so off, but sometimes you get stuck, right? Today I started thinking about the client side and I hope I can implement some of that tomorrow and maybe the rest on Sunday. I really want this to be off my desk now :-)

What I'll do next:

I think I can deploy the drag and drop interface publicly at the beginning of next week.

Then go over to fontbakery core hacking.

Best, L.

[Felipe Sanches]

Nice! :-) Thanks, Lasse!

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/cbb9ad2a-7be1-a35c-1096-83f887640d5a%40graphicore.de.
For more options, visit https://groups.google.com/d/optout.

-- 
Lasse Fister

Tel.: +49 (160) 949 106 15

Galgenhofstraße 12
90459 Nürnberg

Visit www.graphicore.de

-- 
Lasse Fister

Tel.: +49 (160) 949 106 15

Galgenhofstraße 12
90459 Nürnberg

Visit www.graphicore.de

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/58d245e6-5533-b2a5-aabc-4b4b48a023f9%40graphicore.de.

[Dave Crossland]

Yeah man this is all good, sometimes "deep work" with no distractions is necessary :) 

[Dave Crossland]

Hi Lasse

Any news on the drag and drop front?

Cheers
Dave

[Lasse Fister]

It's deployed since now, at http://104.197.213.179 Should scale nicely,
I hope, we have 5 worker pods and 3 fronend server pods.

Here's my log of the past 2 days:

https://gist.github.com/graphicore/7ff94d773e3532118f4b0ee02fb036cf

Code is still here:
https://github.com/graphicore/fontbakery-dashboard/tree/draganddrop

Here's the report of a finished run:
http://104.197.213.179/report/5e92ff77-75ae-4eb9-b7f2-8643e1313cb9
Note: we can drop all files of a folder, including METADATA.pb etc :-)

What's left (order reflects my priorities):

- Some of the external dependencies, especially: ots-sanitize and
ttf-autohint, but also ftxvalidator.
- cleaning up the repository, moving old stuff to a place out of the way.
- I must document how all the stuff works together and explain some
concepts.
- probably some usability work, though, we could be better off waitng
for this until we got more basic stuff sorted out, like the refactoring
of fontbakery (will lead to more instant feedback, i.e. we won't need a
progress spinner ...)

What I'll do next:

The above, but also start the main fontbakery work. I think I can do the
above on the side for ~ 1 hour a day until it's done.


Best L.


On 13.06.2017 02:18, 'Dave Crossland' via Google Fonts Discussions wrote:
>
> Hi Lasse
>
> Any news ploun the drag and drop front?
>
> Cheers
> Dave
>

[Dave Crossland]

Hi

On Tue, Jun 13, 2017 at 1:11 PM, Lasse Fister <la...@graphicore.de> wrote:

It's deployed since now, at http://104.197.213.179 Should scale nicely,
I hope, we have 5 worker pods and 3 fronend server pods.

AWESOME!

 

Here's my log of the past 2 days:

https://gist.github.com/graphicore/7ff94d773e3532118f4b0ee02fb036cf

lol - thanks for persevering through this :)

 

Code is still here:
https://github.com/graphicore/fontbakery-dashboard/tree/draganddrop

Here's the report of a finished run:
http://104.197.213.179/report/5e92ff77-75ae-4eb9-b7f2-8643e1313cb9
Note: we can drop all files of a folder, including METADATA.pb etc :-)

NICE!

 

What's left (order reflects my priorities):

- Some of the external dependencies, especially: ots-sanitize and
ttf-autohint, but also ftxvalidator.
- cleaning up the repository, moving old stuff to a place out of the way.
- I must document how all the stuff works together and explain some
concepts.
- probably some usability work, though, we could be better off waitng
for this until we got more basic stuff sorted out, like the refactoring
of fontbakery (will lead to more instant feedback, i.e. we won't need a
progress spinner ...)

What I'll do next:

The above, but also start the main fontbakery work. I think I can do the
above on the side for ~ 1 hour a day until it's done.

Sounds ideal! 

Cheers
Dave 

[Lasse Fister]

What I did today:

Cleaning up in the fontbakery-dashboard/draganddrop branch.

Brought minikube deployments en par with gcloud deployments.

Added ansi_up to the fontbakery drag-and-drop stderr and stdout texts. (The stdout output has ANSI color codes)

Made the buttons in the fontbakery test report more like buttons, though, Dave was talking about the entry page "drag and drop" stuff :)

We had a hangout for planning stuff.

I picked up fb core refactoring again.

What I'll do tomorrow:

some: fb drag and drop backlog
mostly: fb core

[Dave Crossland]

Nice - thanks!

[Lasse Fister]

What I did today:

Wrote a lot of the Font Bakery Testrunner execution logic, I'm pretty
pleased so far. Next thing will be to work more on details as the bigger
picture looks good.

I did not work on the drag and drop backlog though.

What I'll do tomorrow:

I'll start with the drag and drop backlog and do there some tasks, then
Testrunner.

Tomorrow I won't have time to work the full day, I will however catch up
on Sunday.

[Dave Crossland]

Great! 

[Lasse Fister]

What I since Friday:

Some minor improvements to https://github.com/googlefonts/fontbakery/issues/1382

The details I was working on had mainly to do with using inspection to find out which arguments a test expects.

Today, I started a very little dummy test-suite and used that to debug the test runner code that I have so far. It worked all out and the tests are now executing as I was planning.

What I'll do tomorrow:

We can now run a test-suite, but there's not much interpretation of it's output. I'll try to get a console output and an output similar to what we have now as json up and running. But this stuff will be open for other handling as well. We have data that is more structured now, so the reports can become better as well.

Best, L.

[Dave Crossland]

Cool!

I am in a Petr van Blokland "PageBot" workshop this week, it's a new Drawbot library (so pyobjc dependent and python 2.7) that he is working on with a vision to replace the PageMaker/Quark/InDesign/Scribus manual print production application with a fully programmable python environment, to do to them what robofab did to ikarus/fontographer/fontlab ; this is now needed by typenetwork for proofing Variable Fonts, making specimens, but beyond final fonts-in-use specimens, real example Graphic Design pieces to play with. 

Will be posted under an mit license soon. 

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/65bf4235-bdb0-ce8f-217a-7c5d11064048%40graphicore.de.

[Dave Crossland]

Also, I remember that Behdad had suggested exploring msgflo/noflo for a new fb. I'm interested to hear your thoughts on how your upcoming version can work with that

http://bergie.iki.fi/blog/msgflo-noflo-in-hackathons/

[Lasse Fister]

Better read here: http://www.jonnor.com/2015/06/announcing-msgflo-a-distributed-fbp-runtime/

Well, looks like it can be used in the dashboard to organize and connect the workers. It can use RabbitMQ/AMQP as a broker, which we already use. So it's clearly happening in the gcloud/dashboard code, not in fontbakery itself.

The one thing the fontbakery will do is to enable splitting the test suite into smaller workloads, so that we can run one job on multiple workers to speed things up. I did not make up my mind for details of this yet.

On 21.06.2017 16:28, Dave Crossland wrote:

[Lasse Fister]

What I did:

I wrote code to render test output to the terminal, video attached.
`fontbakery dev-testrunner` is a mini, dummy testsuite that also repeats
once to make it look bigger.

It has already support to fine tune the verbosity and
activate/deactivate colors, a cool (optional) progressbar and it can
handle the synchronous and the asynchronous test runner execution model.
The latter is not yet implemented in the runner, but it will be the mode
that is used when multiple processes run a testsuite, where the results
don't appear in order.

What I'll do tomorrow:

The reporter for json. I think this won't take very long.
Then do some backlog work on the dashboard again.

Questions to the team:

@Felipe: At some point, should I show you around what I did so far?
Maybe a hangout call? We need to find out how you can come in.

[Dave Crossland]

Great!

The video didn't work for me on my phone, could you please post to YouTube :)

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/21f95992-5b18-c09e-5eff-d7c3ef29afbc%40graphicore.de.

[Lasse Fister]

here: https://youtu.be/WmOvFl7Srl4

[Dave Crossland]

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/5cffd937-39bf-e1ef-22e7-c1b50bb89601%40graphicore.de.

[Felipe Sanches]

Sure! Let's schedule a hangout. I do have a meeting with Tav schedule
for 10am today (40 minutes from now) on IRC to discuss Inkscape
internals, so I think it is likely that this will lead to some
Inkscape coding later today. But I think I could schedule a hangout
with you for the next day. Friday 10AM (GMT-3) is good for you?

The video looks pretty neat, by the way. I like it. I was just a bit
confused by the ZeroDivisionError s at first, but I see this is a
prototype with fake checks, right?

I should also mention that yesterday I moved the dashboard related
checks to the fontbakery-dashboard repo, even though I know some of
those issues probably don't apply to your current codebase anymore.
Feel free to manage them as you like. You can close the issues that do
not apply anymore, for instance.

cheers,
Felipe

> --
> You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
> To post to this group, send email to googlefon...@googlegroups.com.
> Visit this group at https://groups.google.com/group/googlefonts-discuss.

> To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/21f95992-5b18-c09e-5eff-d7c3ef29afbc%40graphicore.de.

[Lasse Fister]

Thanks!

My GMT offset is +2 so, Friday 15:00 good for me.

> but I see this is a prototype with fake checks, right?

yeah, the checks are dummies.

> yesterday I moved the dashboard related
> checks to the fontbakery-dashboard repo, even though I know some of
> those issues probably don't apply to your current codebase anymore.

I've seen it. Thanks!

L.

[Felipe Sanches]

OK, cool! So we'll have a hangout tomorrow at 15PM (GMT+2). For the
sake of clarity, I think it is good to mention that this is just for
the two of us, right? Or would you want to invite other people from
the team as well?

> To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/593e9066-0743-dac1-e221-0c4833defa09%40graphicore.de.

[Lasse Fister]

We can make it a happening i someone else is interested. Who brings the
popcorn?

I'll walk you through the concepts/bigger picture of the testrunner, so
it will be pretty nerdy. The hope is to make it easier for you starting
to work with the thing.

L.

[Felipe Sanches]

Great! Thanks :-)

> To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/fd2b1c79-fdba-3c2b-c6df-24005a1e3511%40graphicore.de.

[Lasse Fister]

What I did:

Wrote that reporter to serialize a test runner result as e.g. json.

Then I got hung a bit in reading documentation and source code of the python unittest module (and nototools unittest, roboto unittest). I initially thought it would be nice to have our runner run also unittest.TestCase instances, but now I'm not so sure anymore, at least it's going to be more effort than I thought and probably less useful. In short, the nototools.unittest stuff loads the fonts on the module level and binds them to the TestCase classes, but we want to pass different fonts as arguments, so that the tests are reusable (bind at least to the instance not to the class). It's a bit messy to try to marry both concepts. Although, Python is pretty strong in its metaprogramming abilities, there may be a way ;-) Anyways, without a way to use these exisiting tests straight away, the priority for a python unittest adapter gets lower for me. Though, the interface, using `assertEqual` functions etc. may be nice for some folks.

Today I fixed some of the "oldstyle" test adapter and started a specification/googlefont module with command to run it. This was as a preparation for the call with Felipe where I showed him around, then we ported some tests from checks.py as pair programming. The call was quite good, Felipe feels confident to start porting tests. :-)

After the call, I added a new feature to the runner 'derived_iterables', which is working now. I had to move code around for this and made some bug fixes/improvments on m way to get it working.

What I'll do next:

Some features are still missing in the testrunner module, mainly to warn early if there are any usage errors.
And, really need to do some dashboard backlog ...

Best, L.

[Felipe Sanches]

Cool :-D

I'm really happy about all of this !

> --
> You received this message because you are subscribed to the Google Groups
> "Google Fonts Discussions" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to googlefonts-dis...@googlegroups.com.
> To post to this group, send email to googlefon...@googlegroups.com.

> Visit this group at https://groups.google.com/group/googlefonts-discuss.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/googlefonts-discuss/9be1d393-4f58-d17c-dbdb-e101e5d39155%40graphicore.de.