Fontbakery: investigate BLACKLISTED: IOError: execution context too long

[felipesanches]

blacklisted on font_compare_metrics.py (Issue #684)

• FiraSans
• FiraMono

fontfile: '../../github_google/fonts/ofl/firasans/FiraSans-Italic.ttf'
Traceback (most recent call last):
  File "tools/compute_font_metrics.py", line 269, in <module>
    main()
  File "tools/compute_font_metrics.py", line 127, in main
    properties.append(get_width(fontfile))
  File "tools/compute_font_metrics.py", line 219, in get_width
    text_width, text_height = font.getsize(TEXT)
  File "/usr/lib/python2.7/dist-packages/PIL/ImageFont.py", line 143, in getsize
    return self.font.getsize(text)[0]
IOError: execution context too long

[felipesanches]

The only remaining blacklisted families with this issue are:

• Padauk
• KumarOne

[felipesanches]

This is likely a side effect of bad hinting tables. Let's track the issue in a single place: https://github.com/googlefonts/fontbakery/issues/1021

[HinTak]

FontVal 2.1 includes a couple of tests errors/warnings for execution taking too long. This was introduced after 2.0, so you need the latest ubuntu binary from earlier today if you want to see if that works.

[felipesanches]

show me the code ;-)

[HinTak]

Show me an updated version of b06 :-).

The python side of code was as I wrote in
https://github.com/googlefonts/fontbakery/issues/1335#issuecomment-315366703
https://github.com/HinTak/freetype-py/blob/fontval-diag/freetype/ft_enums/fv_diag.py , line 128 - 131, error code E6070, and E6071:

128     '_rast_E_FT_EXECUTION_TOO_LONG' :  
129     [ 'E6070', 'Execution time too long and exceeds dynamic limit' ], 
130     '_rast_E_FT_EXECUTION_TOO_LONG_BACKWARD_JUMP' :  
131     [ 'E6071', 'Execution time too long and exceeds dynamic limit in backward jump' ], 

So one of E6070 or E6071 should happen with FontVal 2.1 (or if you prefer, with the python wrapper).

[HinTak]

@felipesanches - also I 'd like to point out that I named 4 things you could contribute -
https://github.com/googlefonts/fontbakery/issues/1524#issuecomment-324778512 - you did not understand one of them and it took me ages to explain, did not attempt another before somebody else did; so your contribution so far is perhaps negative: in asking too many questions and delaying my working on the 2.1.1 binary. I hope you make some positive contribution to atone for your negative ones before making more demands. Just saying.

It also does not inspire confidence that you will "improve" the code, when you did not understand the first part of it. Show me that you are capable of understanding it first, at least. That's also one reason why I would not sign microsoft's cla: they did not show that they can build it (by providing a binary).

[felipesanches]

Whoa!

[felipesanches]

Just noticed that I did not even read that whole bunch of comments at https://github.com/googlefonts/fontbakery/issues/1524#issuecomment-324778512

Maybe I saw the first one, but I'll have to re-read all that. Sorry.
Thanks for the "ping" here, but keep cool, please :-)

[felipesanches]

To be fair... your recent reluctance to publishing the full custom-freetype patch-set (which is used to build the FVal binaries mentioned above) is also slowing down a bit my own work. A copy of the source code (which can be provided in the blink of an eye) would definitely be very useful and it is the way to go for a free software project like FontBakery. That's the reason why I asked for the code (not in any way trying to be rude).

Access to source code is a pre-condition that I have established for incorporating any third-party component as a dependency here. If I can't see what's going on, then how can I trust it will really provide the best quality-assurance in all FAIL/PASS/WARNING scenarios ?

I know we can trust you in general due to your past good-quality contributions. But, in principle, I'd really prefer to trust the code directly, rather than by proxy. After all, everybody is prone to errors, so it is pretty reasonable that we may desire to double-check things.

[HinTak]

Look, you probably get paid to work on it, I don't. So what you are asking, and been doing is, that just because I donated some blood, and you feel like you can ask for one of my kidneys too. Just saying.

As I said, one of the reasons I did not sign Microsoft's CLA was that they did not show they can maintain the code (as a first step, building it and provide a "official" binary). If they want to maintain it, they need to show that they can. That's not going to change until you make some positive contribution.

Show you more code so that you can ask more questions, and make more negative contributions? I don't think so ;-).

[HinTak]

You might want to go back and read - you missed most of the information about b06, as well as the new ubuntu binaries... I do feel like a lot of it did not register. Lobbying Google or whatever to fund further work is also one of the 4 (now 3) contributions you could make.

[chrissimpkins]

Show you more code so that you can ask more questions, and make more negative contributions? I don't think so ;-).

Open the source because there is a tremendous benefit to others (including our team and those like us who do not work for corporations with the financial incentive to compensate you for your work nor are we compensated for work in any of our projects to pass along to you for the privilege of access to your code) in learning from your progress and significant detriment to others (including our projects) of embedding closed source projects, including those that build from any closed source dependencies, as dependencies in Font Bakery. This violates the Debian Free Software Guidelines and limits our capacity to use any functionality in Font Bakery for our builds on platforms that follow these and similar free software guidelines.

Maintaining closed source in an attempt to achieve compensation is a business model. We all need to make a buck and I understand this, but there are consequences for other stakeholders in this project that may not be appreciated.

I encourage the Font Bakery team to eliminate all dependencies that lead to such consequences for the end user so that those of us who are impacted by this can benefit from the free/open portion of the project.

[HinTak]

Please re-read https://github.com/googlefonts/fontbakery/issues/1524#issuecomment-324778512 and what follows. I don't want to repeat myself, but

• consider that opening one part took so long to explain what it is, etc is a significant burden already, I don't particularly want to add more trouble to myself.

• google is rich. If google wants something, they can surely affort to pay for it.

• I don't want to repeat the metaphor : I donated blood. Are you entitled to ask for one of my kidneys too? What I am willing to give and donate is just what it is, nothing more and nothing less. Please accept it for what it is, not an excuse to ask for a donation of a much bigger amount.

• the main users are strangely, mac users. I uploaded the analysis reports a year ago on all libre fonts found on fedora 24. Did the debian people act on them to improve libre fonts? Show me your contribution before you make demands.

• as I explained perhaps the 10th time. One major reason for not showing the full patch set is that the first and essential part is not safe to be applied to system-wide freetype. It was posted publicly more than a year ago. I invited people to improve it from time to time. You are free to improve it too so that it is safe for public consumption. Then discussion about the rest can follow.

[HinTak]

I have collected most of my recent postings and other info and expand it a bit more into the FAQ - https://github.com/HinTak/Font-Validator/wiki/FAQ .

@chrissimpkins - have a look at the "debian guideline entry" - https://github.com/HinTak/Font-Validator/wiki/FAQ#what-about-the-debian-free-software-guidelines - and see what you can do to help. I expect to see some improvements on libre fonts next year from Debian people.

@davelab6 - would really appreciate if you could try to answer some of the questions yourself , instead of sending people in my direction.

[chrissimpkins]

@HinTak Thanks. We have Debian packagers (and Fedora) who are developing build from source packages for the Hack typeface to meet font re-distribution guidelines on those distros. We have been working closely with them as we determine the build dependencies for our transition to OSS tooling in the upcoming release. I don't have any particular expertise in (and certainly no influence over) Debian font releases or quality control. Best to contact their user groups/mailing lists directly for that issue. I am not certain what you found in the reports, but would reports of issues with the typefaces not be best suited for the individual typeface development teams rather than the Linux distro re-distribution teams? Ideally changes would occur at the upstream source rather than in individual, distro specific downstream packages.

[HinTak]

Those posts I made were CC'ed my Ubuntu and Fedora contacts (in the printing side of things), as well as to CREATE. Obvously it is not practical for me to look up and contact 300-400+ font owners individually. I'd hope that it would alert the fontconfig packagers, for example, and get forwarded.