Subject: A Proposal (why we should have setBold(true))
From: sam th (sam@bur-jud-118-039.rh.uchicago.edu)
Date: Sat May 27 2000 - 05:09:23 CDT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In working on the XHTML importer, I have come upon the following problem:
Currently, there is a 1-1 relationship between the text of the attributes
of an element in the XML produced by abiword and the representation of
formatting in the pt. (actually, the piece table uses a hash table, but
the principle is the same.) This makes life very easy for the .abw
importer - all it has to do is pass the attributes unchanged into the
piece table. However, this means that the means of acessing the piece
table are (IMHO) the worst sort of low level routines. It works well for
the abw importer, since it doesn't have to get down and dirty
parsing attributes, constructing string arrays, and then passing them to
the pt. Additionally, the abw file format has very little concept of
inheritance. It never has to inherit within the same level, such as a
block. The following is illegal abw:
<section>
<p props="font-weight:bold">text<p props="font-weight:normal"> more
text</p></p>
</section>
This means the formatter (which does deal with inheritance) does the work
for the importer.
However, life is much trickier for the XHTML importer (and for me). The
following is legal html:
<body>
text
<p>more text</p>
<p> a <strike>third</strike> <span> line <b> that is bold <i> and
italic</i></b></span></p>
<b>
<p>a fourth line, which is bold</p>
</b>
</body>
This makes my life very difficult. The XHTML importer has to essentially
have only one section, and then create new paragraphs for everything else.
However, I am not allowed to replicate the HTML nesting in the pt (which
is a good thing).
The upshot of this is that I have to keep track of what state everything
is in, so that I can regenerate the property list for each new element
that I create. Needless to say, this makes for ugly code. However, I
don't think this should be the importer's job. Here's how I think the
importer should go:
beginElement(...)
{
...
case TT_BOLD:
[sanity check here]
m_pDocument->setBold(true);
boldRefCount++; // since turning bold on lots of times is possible
...
}
endElement(...)
{
...
case TT_BOLD:
[sanity check]
boldRefCount--;
if(boldRefCount==0)
m_pDocument->setBold(false);
...
}
This would naturally be extended to all the props elements (with some
taking more than true and false). The style elements are easier to deal
with (since only one style at a time is possible, right now) but the may
become more difficult later.
However, this additon wouldn't just make my life easier.
1 - take a look at _toggleSpan in ap_EditMethods.cpp (line 3415)
The code there is a bunch of low-level string manipulation. This is
exactly what should not be in EditMethods. Instead, EditMethods should do
what it does nicely with most commands - call a fairly easy-to-use
function in fv_View that does the low-level work - where it should be.
2 - think about scripting. Eventually, we will want to add a scripting
interface to AbiWord calls. And that language won't be C++. It probably
will have a hard time do anything like the hackery neccessary to currently
manipulate properties. And we can ask our users to think about that sort
of thing either.
3 - the current system locks down the implementation of the ptbl to how it
is accessed. Granted, no one is talking about changing the ptbl right
now. But someone might, especially if it was going to be used, at least
in part, in some other abisuite application. Right now, changing it would
require changing not only the ptbl API, but also the abw file format. As
Justin pointed out a while back, an XML-based word processor could just
manipulate the DOM tree. But that's not the route AbiWord took. Let's
not just get the limitations of that choice, but also the benifits.
Therefore, I propose:
Adding to PD_Document methods such as the following:
UT_Bool setBold(UT_Bool newVal);
UT_Bool setItalic(UT_Bool newVal);
UT_Bool setFont(XML_Char * newFont);
UT_Bool isBold();
// things that can't be toggled (such as fonts) won't need the same
// accessor functions.
etc..
I think this will result in minimal added overhead, and greatly improve
the usablility of the ptbl.
well, what do you think?
sam th
sam@uchicago.edu
http://sam.rh.uchicago.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5L57Vt+kM0Mq9M/wRAk8KAKCvmSRWshMMs6SBCAWoeeUPpprOnACgqBy1
wnGtMJepOrKbHVWjllKrilQ=
=H7Vt
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2b25 : Sat May 27 2000 - 04:58:11 CDT