Shaw can jump in here anytime to correct me if I'm wrong, but my
understanding is that a large part of the problem has to do with
printing metrics. Some (maybe lots, depending on your installation) of
the fonts that X uses have only the data required to *display* the font
on the screen. Heck, that's all X is going to do, so that's all it
needs to work.
But to *print* a font, you need printing metrics. So, to guarantee
that the fonts we're using *have* print metrics, Abiword has it's own
copy of fonts. It can't just use X's list of fonts, because it doesn't
know if the printing metrics are available or not.
So while you could try to fault X for not requiring print metrics, the
problem is really a *font* problem - people are using and distributing
"incomplete" fonts.
The GNOME printing framework should have the same limitations.
<snip>
>> Windows doesn't do pipes. I don't know if BeOS does. It would also
>> be tremendously slow to hit ispell through a pipe for every word
>> completed in the course of normal typing, and even worse for each word
>> in a paragraph upon document load. We could batch it up and check whole
>> regions, and then we'd get to write (and debug) a parser for ispell.
>
> THe idea is to run ispell *once* (that is what the library I was talking
> about does) and "ask it" to look up the words you
> want to check, through the pipe. It's still a bit of an overhead, but
> it would allow Abiword to use ispell, whilst avoiding the duplication of
> functionality and files on the system.
Shaw's first objection has to do with cross-platform capabilities.
Abiword is cross-platform, so they try and implement things that work
easily on all the platforms that they use. Windows doesn't support
pipes, so if they use ispell on the *nix side, they have to have a
different solution for the Win* side. Instead of supporting two
codebases, they'd rather build *one* that works everywhere. So far,
using the ispell hash file directly seems to be acceptably XP.
So, even though your solution doesn't add *too* much overhead, it still
only works on *nix. The "problem" that it solves (duplicated files,
duplicated functionality, inability to specify a user-specific ispell
alternative) really only exist on the *nix side of things. Windows and
Mac (and maybe BeOS, I don't know) don't ship with ispell, so there
aren't any duplicated files or functionality there. You *might* be
able to run aspell on Windows (again, I'm not sure), but you have the
same "lack of pipes" problem to solve.
So it boils down to this: Do the Abi coders want to support two
different codebases for spelling on different architectures?
I *think* that's why Shaw then says this:
>> Using a library interface, instead of the way we actually compile ispell
>> into our binary, would definitely be possible, if one were to work
>> out the interface to accurately express the kinds of things we have to
>> know about words.
*Maybe* what we could do is abstract the spell-checking subsystem into
a separate library that uses ispell on the "no-pipes" architectures and
uses a custom solution like you describe on the "have-pipes"
architectures.
The downside, as I see it, is that there will *still* be UI differences
between architectures, because now we have to have a way for
"have-pipes" people to specify which third-party spell application they
want to use.
Oh, and we also have to guarantee that that third-party spell
application will communicate with us over pipes the *same* way that
ispell does. That might be a bigger problem...
Have fun,
Nato