More seriously: We're not saying "This is hard, so we should
be afraid of it". We're saying, "This is so hard that it's
not worth doing."
Parsing HTML is not just hard, it's an ugly mess. The resulting
code will be large, complex, and difficult to maintain. That's
just the nature of common practice in HTML.
An HTML importer that does a poor job may be worse than none
at all. Suppose we have an HTML importer, and someone tries to
use that code to import an HTML document and it fails. Suppose
also that the HTML document in question works fine in Netscape
and Internet Explorer. This will reflect badly on AbiWord.
There are serious design questions in play here. What will
you do about frames? How to handle inline images? What
about Java, JavaScript, CSS? Which version of HTML will
you support?
This is more an issue of focus than it is one of shying
away from complexity. We want to be sure that AbiWord keeps
its priorities in line. Word processors, first and foremost,
are about paper. I don't mind if AbiWord, like most other
word processors, wants to branch out into content creation
for other media, but doing so is not important to me,
and will not be important to me until AFTER AbiWord does
a good job at its core feature, which is paper.
Bear in mind, of course, that the above is mostly just
my $.02. AbiWord is open source, and it's a bazaar.
Working code speaks volumes. Show me the source, and
I'll shut up. As a last resort, if you don't like the
focus we're trying to evangelize, the GPL is pretty
explicit about what you're options are. :-)
With all that said, I probably overstated our resistance.
If someone else wants to code this feature and submit it
as a patch, we'd be happy to consider it. However, I
don't think we'd *encourage* anyone to do so.
--On Wed, Mar 24, 1999 at 04:54:47PM +0000, Steve Ratcliffe wrote: > Return-Path: <owner-abiword-dev@abisource.com> > Received: (from majordomo@localhost) > by postman.abisource.com (8.8.7/8.8.7) id KAA31427 > for abiword-dev-outgoing; Wed, 24 Mar 1999 10:54:59 -0600 > Received: from post-20.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) > by postman.abisource.com (8.8.7/8.8.7) with ESMTP id KAA31420 > for <abiword-dev@abisource.com>; Wed, 24 Mar 1999 10:54:57 -0600 > Received: from [212.228.182.246] (helo=ariel.sr.home) > by post-20.mail.demon.net with esmtp (Exim 2.10 #2) > id 10Pqve-0001gi-0K > for abiword-dev@abisource.com; Wed, 24 Mar 1999 16:54:55 +0000 > Received: (from steve@localhost) > by ariel.sr.home (8.8.7/8.8.7) id QAA26953 > for abiword-dev@abisource.com; Wed, 24 Mar 1999 16:54:47 GMT > Date: Wed, 24 Mar 1999 16:54:47 GMT > From: Steve Ratcliffe <steve@parabola.demon.co.uk> > Message-Id: <199903241654.QAA26953@ariel.sr.home> > To: abiword-dev@abisource.com > Subject: Re: 0.5.2 tarball > Sender: owner-abiword-dev@abisource.com > Precedence: bulk
> > As far as we know, no one is working on an HTML importer > > for AbiWord. > > > > The core team here at AbiSource doesn't have much interest > > in this particular feature, actually. Here's why: > > > > 1. Importing HTML into a word processor is hard. > > > 2. Very hard. [ ... ] > > > 3. Really hard. [ ... ] > > I'm not being funny, but I don't understand this argument. Lots of > things are hard; i18n is hard and yet you are still going to do it. > > > 4. Writing an interoperable HTML implementation is not fun. > > I can understand that doing the same thing that you have done before is > not fun. But doesn't it still need to be done by someone who doesn't > bear the scars? > > Since you can write a document out as html you should at the very least > be able to read it back in again. > > ..Steve
-- Eric W. Sink, Software Craftsman eric@abisource.com