Skip to content

Option to not embed Adobe Glyph List in fonttools and use system-installed version #83

behdad opened this Issue Jan 16, 2014 · 13 comments

6 participants

brawer commented Sep 9, 2015

Curious, which problem would this solve? The Adobe Glyph List isn’t changing much; the last change was on November 6, 2008.


I don't understand.. where should the Adobe Glyph List be installed system-wise?

twardoch commented Sep 9, 2015

I'd vote to reject this. AGL is highly unlikely to be changed, ever. And the integration of the Unicode standard in Python is highly problematic, and depends on the version of Python it is deployed on.

Perhaps we might want to provide a lightweight integration to the unicodedata2 module ( ). That module allows users to build their own unicodedata2 module for Python 2.x from the current data files in a way that is compatible with the Python-provided unicodedata module (which is ancient). Something like:

  import unicodedata2 as unicodedata
except ImportError: 
  import unicodedata

But I don't know if it's worth the overhead.


where should the Adobe Glyph List be installed system-wise?

The original issue text by @pabs referred to system-wide unicode data, which Behdad resolved with fea81ee .

I agree with Adam that sounds good

If we wanted to expunge the aglfn, and fetch it from a URL at build time instead (such as we could do, but I don't see a strong reason to do so; the reason given by @pabs3 was the then non-libre licensing, which has since been resolved as it is now Apache licensed.

Regarding Behdad said on the SF issue that it can't be automatically extracted from the spec.

I'm not sure if there is a libre licensing concern with that data; I think we can license that code as we do, or claim it isn't subject to copyright due to utilitarian API compatibility fair use, or similar such that distros are unconcerned. If a distro has an actual concern, I am pretty sure it can be resolved.


Thanks @twardoch and @davelab6 for clarifying the issue.
I like Adam's idea of attempting to import unicodedata2 backport module for python2, and falling back to built-in unicodedata if that isn't available.
I'll send in a PR.

@anthrotype anthrotype added a commit to anthrotype/fonttools that referenced this issue Sep 10, 2015
@anthrotype anthrotype [unicode] attempt to import `unicodedata2` backport module
As suggested by Adam @twardoch in behdad#83 (comment)
pabs3 commented Sep 18, 2015
pabs3 commented Sep 18, 2015

Bah, github doesn't look at email attachments, posted via the web.

pabs3 commented Sep 18, 2015

Nor the web, hmm.

Here is the code, feel free to use it under whatever license you want:

brawer commented Sep 18, 2015

Sorry for lacking context of this discussion, but which problem are we trying to solve?

If it’s licensing: Adobe has released the data file under the Apache 2.0 license. Not free enough?

If it’s keeping track of upstream changes: Is it an actual problem? The file has last been changed seven years ago, and (as @twardoch pointed out earlier on this bug) it is rather unlikely to ever change again. Should it change, we’ll certainly update fonttools.


If it’s licensing: Adobe has released the data file under the Apache 2.0 license. Not free enough? includes data from the OpenType spec, which (afaik) Adobe hasn't liberated. But I expect it would be straightforward to get them to do so if there is a problem.

behdad commented Sep 18, 2015

Dave, stay on-topic please.

There's nothing to fix here AFAICS. otData CAN'T BE AUTO-CREATED. There's no point in run-time-loading a file that is not expected to ever change again.

@behdad behdad closed this Sep 18, 2015

I agree

pabs3 commented Sep 18, 2015

I expect otData actually can be auto-created. The documentation in otData should be removed at least.

I still think keeping a copy of aglfn instead of depending on it is the wrong way to go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.