Migrate project to graphicore/charset-inspector

[davelab6]

Per https://github.com/graphicore/charset-inspector/issues/1

[felipesanches]

Pyfontaine is a useful fontbakery dependency. While I appreciate that other projects such as charset-inspector may reuse the charsets available on this repo, I disagree that pyfontaine should (as of mid-2017) be shutdown. That's not the case anymore. So I'll close this issue.

[davelab6]

I'm not totally sure. Currently fb uses pyfontaine via shell, not as a python module. If we get a js codebase with equivalent functionality including at command line, what would be the difference?

Or would you plan to refactor pyfontaine to have an API as a module?

On May 24, 2017 9:05 AM, "Felipe Corrêa da Silva Sanches" < notifications@github.com> wrote:

Closed #87 https://github.com/davelab6/pyfontaine/issues/87.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/davelab6/pyfontaine/issues/87#event-1095531243, or mute the thread https://github.com/notifications/unsubscribe-auth/AAP9y7Wven8mZNsqN6XSubgpWVjLEQ_hks5r9CrdgaJpZM4IL9OJ .

[graphicore]

I made some pretty advanced coverage analysis stuff in specimenTools/mdlFontSpecimen which is almost done (I think). It combines CLDR and the google/fonts/tools/encodings. I think that's an interesting approach.

graphicore/charset-inspector uses only unicode codepages.

I'd really prefer if we could develop an understanding of what we actually want to do instead of just using one of the projects sitting around. And then decide how to do it.

Pyfontaine already forked some of the code I recently wrote for google/fonts, that is a bad thing in itself.

I guess, what I'm saying is that we need a bigger concept and then make a clean solution.

[felipesanches]

yes, a pyfontaine python module with an API is something I've been considering in order to generate better output on fontbakery

Also it feels a lot awkward to have a python program use the shell to invoke a javascript dependency via nodejs.

[graphicore]

Also it feels a lot awkward to have a python program use the shell to invoke a javascript dependency via nodejs.

That's no difference than invoking any other command as sub process. I don't see how js is qualitatively different from python or mono (MS Fontvalidator.exe) or anything else for that matter.

[felipesanches]

I agree. Nothing wrong(er) in comparison to the other third-party tools we use on fontbakery, indeed.

But a path towards a python module sounds much better.

[davelab6]

Indeed Lasse is right, I think.

The purpose of the language support reporting is more to inform users in the dashboard, or to inspect random fonts.

whereas checks for Google Fonts 2016 glyph set definitions support in fb is a much more simple case, and the audience is different, font developers checking compliance with GF specifications - so this check can just be inlined to fb to keep things fast and simple there - and language analysis can be deprecated and moved to a js project.

On May 24, 2017 9:42 AM, "Lasse Fister" notifications@github.com wrote:

Also it feels a lot awkward to have a python program use the shell to invoke a javascript dependency via nodejs.

That's no difference than invoking any other command as sub process. I don't see how js is qualitatively different from python or mono (MS Fontvalidator.exe) or anything else for that matter.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/davelab6/pyfontaine/issues/87#issuecomment-303727249, or mute the thread https://github.com/notifications/unsubscribe-auth/AAP9y8A5Uy-XKFUkEGZnn9N5tyu5bWI7ks5r9DO9gaJpZM4IL9OJ .

[felipesanches]

Yes. Inlining the checks on FB sounds good to me. Thanks for the clarification.

[davelab6]

On May 24, 2017 9:32 AM, "Lasse Fister" notifications@github.com wrote:

I made some pretty advanced coverage analysis stuff in specimenTools http://graphicore/specimenTools/mdlFontSpecimen https://github.com/graphicore/mdlFontSpecimen which is almost done (I think). It combines CLDR and the google/fonts/tools/encodings. I think that's an interesting approach.

What end users care about is languages. I guess the ontology goes something like,

Language -> orthography + typography requirements -> font specification (chars, glyph, ot features) -> (subset of) a writing system

Eg

French -> ABC..., abcdé..., guillemets, thin space, etc -> U+0064 U+0065 «» /thinspace [gsub rules for guillemets] -> Latin

Cldr has some of this but I'm not sure it has the typographic stuff.

graphicore/charset-inspector uses only unicode codepages.

It should perhaps be renamed "codepage inspector" then :)

I'd really prefer if we could develop an understanding of what we actually want to do instead of just using one of the projects sitting around. And then decide how to do it.

Pyfontaine already forked some of the code I recently wrote for google/fonts, that is a bad thing in itself.

I guess, what I'm saying is that we need a bigger concept and then make a clean solution

For sure. A long standing failure mode of mine is that I offer only high level guidance and then all contractors who have no better domain knowledge to figure it out. Asking to interrogate the concept is good, but probably I should arrange for someone with experience in linguistics and typography to pitch in. Maybe SIL?

Maybe lots of people? Like a tweet from gf asking for suggestions about what they often find missing from fonts when using their language?

[davelab6]

On May 24, 2017 10:01 AM, "Felipe Corrêa da Silva Sanches" < notifications@github.com> wrote:

Yes. Inlining the checks on FB sounds good to me. Thanks for the clarification

I mean just the sets defined in GitHub.com/Google/Fonts

[felipesanches]

I mean just the sets defined in GitHub.com/Google/Fonts

Yes, that's what I had understood. :+1: