-
Notifications
You must be signed in to change notification settings - Fork 8
allow non-ascii bytes in cache file names #17
Comments
Ok for v1. Also, is ttc correctly handled by v1 or should we wait for v2.2 to remove the ttc from the blacklist? |
If it’s true, just go ahead and remove it. I can’t really test it myself for lack of a specimen. |
It’s now applied with the new master. I think I can test one ttc later today. |
The bug is interesting... maybe it should be reported to the maintainers of the unicode library? By the way, I'll build a svn fontforge today and if it still fails with lingoes, I'll report it. |
It seems that my debian stable is outdated for fontforge building, I'll report it anyway... |
I tested Cambria.ttc (with 2 subfonts) and it should be fine. Also, I connected the dots and I believe I know now who the ominous Kim was that the subfont rule in the original request parser was dedicated to (grep for |
Fixed in upstream: phi-gamma@ed0cde7 |
Here’s the original report: http://tug.org/pipermail/lualatex-dev/2013-April/001499.html
Intuitively I’d opt for replacing the functions by their equivalents from the unicode library, but they cause strange output on my system:
From which I get:
....
华文仿宋.ttf å-æ-ä-å-ttf
....
So for now I’m in favor of applying the patch by Dohyun Kim to v1, whereas for the dev version I’ll ask Hans first (data-con.lua is entirely his own territory).
You can also put it as an override in luaotfload.lua somewhere after data-con.lua is loaded, somewhere around the location where attribute[0] is set.
The text was updated successfully, but these errors were encountered: