Sorry, I didn't mean for my proposal to be taken at face value. It was
intended as a humorous dig at Apple precisely because they seem
incapable of preventing the Java runtime from crashing when there are
font problems. I was obtusely implying that if Apple could write such a
font test, then they could just as well fix the Java runtime problems.
I wonder if Cocoa applications suffer from the same fate as Java
applications.
Dealing with font problems in Java is costing our company a lot of time
and effort (translate that to money), as well as making our product look
bad at our customer sites. Lately I had a peer flame me to pieces in a
widely distributed e-mail because I wasn't resolving the font problems
to his satisfaction.
I've been trying to collect data from our customer sites to feed back as
bug-reports to Apple, but our customers are not cooperating with us.
They have better things to do than troubleshoot Apple's problems.
Who do I have to send a case of beer to at Apple to take this problem
seriously?
If someone else can write a good Java Font Test program, I'll look into
sending them that case of beer :-)
Cheers, Eric
-----Original Message-----
From: java-dev-bounces+eric.kolotyluk=email@hidden
[mailto:java-dev-bounces+eric.kolotyluk=email@hidden] On
Behalf Of Greg Guerin
Sent: Friday, October 28, 2005 2:13 PM
To: email@hidden
Subject: Re: Font Test Program
Eric Kolotyluk wrote:
>I just thought of a really nice tool Apple should write called Java
Font
>Test. You could run it and it would verify if you can run a Java
>application that will not crash because of font problem.
Why should Apple do this?
I'd rather have Apple concentrate on fixing Java so it won't crash, no
matter what kind of malformed, damaged fonts are given to it. They're
in a
position to do that, which no one else is.
A third party can write Java Font Test. It could be me, or even you.
In fact, several months ago a friend of mine asked me to write just such
a
thing, though it was in reference to crashing a non-Java program (I
forget
what, but it was something like Photoshop, as I vaguely recall). What
he
wanted was to automate the manual procedure of moving fonts in and out
of
the relevant Fonts folders, running the app, seeing the crash (or not),
and
eventually narrowing down the problematic fonts. A simple algorithm,
mind-numbing manual drudgery, and so a perfect candidate for automation.
The app used as the probe (crash or not crash) can be arbitrary.
The hunting procedure is always the same: classical binary search.
The only tricky things are:
1. It's not a plain simple binary search, because there may be
multiple
results (i.e. more than one font that causes a crash). This is pretty
easy
to deal with.
2. It may be a combination of fonts that crashes, while each one works
fine on its own. This is somewhat more difficult to handle without
causing
a combinatorial explosion.
I didn't write the bad-font hunter app because I was scheduled to start
a
new gig soon, and because he found the offending font pretty quickly.
He
drastically narrowed the initial hunt by moving out only recently
installed
fonts, as determined by comparing to a known-good backup.
It'd make a nice term project for an intermediate CS class, because it's
a
nice mix of a straightforward algorithm that involves real-world actions
like moving files around, controlling other apps, and detecting crashes.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
m
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
