-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
investigate BLACKLISTED: IOError: execution context too long #703
Comments
The only remaining blacklisted families with this issue are:
|
This is likely a side effect of bad hinting tables. Let's track the issue in a single place: #1021 |
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. |
show me the code ;-) |
Show me an updated version of b06 :-). The python side of code was as I wrote in
So one of E6070 or E6071 should happen with FontVal 2.1 (or if you prefer, with the python wrapper). |
@felipesanches - also I 'd like to point out that I named 4 things you could contribute - 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). |
Whoa! |
Just noticed that I did not even read that whole bunch of comments at #1524 (comment) Maybe I saw the first one, but I'll have to re-read all that. Sorry. |
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. |
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 ;-). |
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. |
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. |
Please re-read #1524 (comment) and what follows. I don't want to repeat myself, but
|
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. |
@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. |
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. |
how to solute this problem,thanks |
blacklisted on font_compare_metrics.py (Issue #684)
The text was updated successfully, but these errors were encountered: