Subject: Re: A Proposal (why we should have setBold(true))
From: Eric W. Sink (eric@sourcegear.com)
Date: Sat May 27 2000 - 09:26:53 CDT
I agree that there is much bogosity in passing around properties in
the form of strings and lists of same.
In fact, I got fed up with this once and tried to fix the situation.
I did not complete the task, but I did learn just how widespread and
pervasive this particular implementation tactic is. Lots and lots
of code will have to be fixed in order to remedy this situation.
Have a look at the toolbar state management code.
Bottom line: In principle, your proposal is very sensible, and
it should probably have been done a long time ago. Just try to clear
your schedule for 2-3 days when you sit down to try and make the
code change. :-)
-->-----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-----
Eric W. Sink, Software Craftsman SourceGear Corporation eric@sourcegear.com
This archive was generated by hypermail 2b25 : Sat May 27 2000 - 09:23:20 CDT