From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Mon Oct 21 2002 - 22:36:00 EDT
--- F J Franklin <F.J.Franklin@sheffield.ac.uk>
wrote:
> On 20 Oct 2002, David Chart wrote:
> > You know I said I was keeping things in CVS? This
> > is why.
> >
> > Abi seems to be using Frank's new phtml exporter
> > whenever you ask it to save a .abw document, even
> > if you just press the Save button on the toolbar.
>
> The export mechanism is supplying ieft=11 for some
> reason, though it's importing ieft=1; not sure
> whether it's something I did or not. I'll be looking
> into changing the current ieft mechanism anyway
> since it seems rather dangerous with respect to
> plugins.
Just a rundown on the problems with AbiWord's filetype
(ieft) concept, what's wrong with it, and what would
be
better:
AbiWord doesn't have one filetype, it has two. One
for importers and one for exporters. These are
numbers
assigned as the import/export modules are loaded.
Since it is not a requirement to create both an
importer and an exporter, these numbers usually are
not
the same for the two filetypes.
When saving a file which has previously been loaded or
when loading after a file has been saved, we attempt
to synchronize the two filetypes. Originally we did
this by looking for an importer or exporter which
supports the same file extension as the filetype we
last used. This was found to break down with the
Plain Text, Human-Readable Text, and Encoded Text
filetypes since they all support the same extension.
I recently changed the synch logic to look for the
importer/exporter with the identical file description
field. My testing showed that it fixed the known
problems but as this was not the function of the
description field it's likely to fail in some
situations. If an importer and exporter have slightly
different descriptions (by typo or be design), the
filetypes will not synch.
If no matching filetype is found, we should fallback
to .abw.
A better system would replace the numeric filetype
with an ASCII string ID specifically designed to be
passed around as a filetype and to be checkable to
synchronize importers and exporters. I'm not sure
what the best procedure would be in the case of
2 modules providing the same ID. Maybe that's an
error or maybe there could be a valid reason for it??
It might also be beneficial for an import/export
module
to be able to specify which filetype to use as its
opposite in the case where only import or export is
provided. For instance, the "RTF for old apps" module
could recommend "RTF" as its opposite.
Any ideas or suggestions?
Andrew Dunbar.
> Ciao, Frank
>
> Francis James Franklin
> F.J.Franklin@shef.ac.uk
>
> `Medium atomic weights are available: Gold, Lead,
> Copper, Jet, Diamond,
> Radium, Sapphire, Silver and Steel.
> `Sapphire and Steel have been assigned...'
>
=====
http://linguaphile.sourceforge.net/cgi-bin/translator.pl http://www.abisource.com
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
This archive was generated by hypermail 2.1.4 : Mon Oct 21 2002 - 22:43:24 EDT