Oh well, it's very boring, but I don't think Fonty Python will be released as a Debian package in the near future -- this is entirely due to my own ignorance of the issues involved with i18n and unicode.
It seems I have to write code to support the default "C" locale, which is ascii, and that conflicts (a lot) with the many different filenames given to fonts. I am suffering horrible unicode errors as a result and just can't say when I'll have it all sorted out.
You can still fetch and use the latest version, but you'll have to ensure that you set your locale to something based on utf8 for now.
I really need help on this, anyone up for clueing me in?
\d
5 comments:
Man, I hate Blogger's (lack of) successful post feedback... or my inability to see it :/
Ok, now I think it didn't work, so here it goes again:
Hey, Donn,
Cheer up, you're doing a great job! Very cool program, really useful POG idea, beautiful help.
Your chat with Martin shows that you're very capable of sorting things out. Regarding that thread, I suggest that you focus on what you can do with ease before you spend too much time on corner cases... as you'll see below, some corner cases come with solutions attached :)
I just got six thousand fonts downloaded and fontypython is going to help me sort them :)
Now, I have a buglet and a suggestion that I might patch:
a) ~/.fontypython was owned by root after sudo setup.py install (Ubuntu Gutsy), so I guess the install process created that... maybe leave it to the first run?
b) you already catch bad fonts that crash fontypython, may I suggest that you decouple the indexing process, blacklist crashers and resume gracefully? Would that be a desirable patch? (Well, six thousand fonts are sure to contain a few crashers, I'd patch mine anyway) :)
Going down to code,
Daniel
> I just got six thousand fonts downloaded and fontypython is going to
> help me sort them :)
Good luck! Nice list - I think I'll go get it too.
> a) ~/.fontypython was owned by root after sudo setup.py install (Ubuntu
> Gutsy), so I guess the install process created that... maybe leave it
> to the first run?
That's not intentional. The whole setup.py thing is more complex than it
should be and I don't fully savvy it. I'm not sure why that happened. That
directory is written on first run. Weird.
> b) you already catch bad fonts that crash fontypython, may I suggest
> that you decouple the indexing process, blacklist crashers and resume
> gracefully?
I thought about that - I didn't have time to figure out the implied recursion.
Perhaps a simple loop is all that's needed.
> Would that be a desirable patch? (Well, six thousand fonts
> are sure to contain a few crashers,
Yeah, if you are up to sending me code. I'm a pre-svn coder from the bad old
days of basic and z80 so I know diddly about patches and trunks etc. I prefer
a good old tarball which I can examine and manually merge. Call me a
dinosaur.
I have posted to the PIL list about those crashes and I think they are fixing
it. The segfaults happen when there are null strings in the font file. I hope
they release some updates soon.
> I'd patch mine anyway
The joys of open source :)
> Going down to code,
Great. Can't wait.
Hi,
I did find a workaround for segfaults, but it's pretty ugly :)
http://fontypython.webfactional.com/ticket/14
Regarding your thread in comp.lang.python, I suggest you move those problematic files and start working from a clean slate... it might be that you're chasing bugs that don't exist except in your highly complex historical settings.
Thanks ajaksu, I posted some comments on the ticket.
Post a Comment