[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [RFC] filter redesign
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2001-09-13 22:35:38
[Download RAW message or body]

On Thursday, 13. September 2001 16:59, Eva Brucherseifer wrote:
> Hi Nicolas,
>
> sorry for my late answer, I was kind of absent the last days.
>
> > Sure, that is called style in KWord and class in CSS but I was trying to
> > make a library for KWord export filters before finsih it. But however, I
> > have the feeling that nobody cares anymore that I write this library when
> > I read this thread.
>
> I am sorry, that you think this way, that was not my intention. I think you
> already did a great work, esp. regarding all the details one has to care

Thank you for the compliment!

> about. If I would try to make a filter for kspread as good as yours, I
> think, it wouldn't come close to yours in a long time. Also we should have
> common look&feel for dialogs and give the same options to the user. This is
> also important for embedded objects.

I have never thought about saving embedded objects this way. However, it 
seems alone to be a good reason to have common builders.

>
> So far your filter seems to head towards a kword filter only. That is why I
> started to think about how to share work. And the result is the design,
> that I proposed, and that Zander was able to explain much better than me
> (Thank you for helping ;-). I didn't want to overrun you, that is why I
> proposed the whole thing here first.

It is not your idea in general that made me felt "overran", it is the fact 
that I have started to write the library for KWord export filter two weeks 
ago, with no much comment but an interested welcome from David Faure.

The library was meant by me mainly to encapsulate problematic code in the 
ASCII-like export filters (of KWord.) This part of code is known to be 
problematic everytime that the file format of KWord is changed, in particular 
when it is simplified. So I had wanted to separate it, so that modifications 
in the KWord file format could be changed at only one point for most of the 
filters and not in each (KWord) export filters like now.

I thought that I could make it evolve a little and have classes with method 
like StartElementP, charactersElementP, EndElementP, as they exists in 
KWord's AbiWord import the functions. They would have told that a paragrapgh 
was started, that we had some characters for that paragraph and that the 
paragraph was closed. The class that need to implement this methods are not 
the builders, as you have defined them. In the meantime, I think that it is 
not that problematic, as something I call "glue" can be made between the 
parser-like idea I had and builders in the sence of your definition.

However, the library was never meant to be something universally usable, as I 
know that I have not time to do something like that. However, as KWord's file 
format may change soon, something was needed to be done rather quickly.

At the port of KOffice to QT3, I had to stop it, as KWord for me is (still) 
unusable (display problems, cannot save.)

(By the way: I would be glad, if someone can tell me how to use the filters 
from the command line. I know it is possibly but I have forgoten how and I 
cannot find any documentaion about it anymore. Thank you in advance!)

>
> Your is not so different from what I was proposing. You already have a
> hierarchy which very much is the builder side. All the "getXXX" functions
> are functions that are part of a builder.
> What Mr. Gamma called the director in his book, is in your function
> ClassExportFilterBase::filter(...) and all the "ProcessXXX" functions that
> are not part of any class.

The problem is that exactly those Process* function is part of the problem in 
the ASCII-like filters! :-(

So for me, your proposal was going back to the start somehow!

>
> Now imagine, that you create an own class for this "director part". It
> would basically do what the filter and the process function does. Then you
> move all html specific things in the getXXX methods you already have. Maybe
> some extra methods might be usefull then for additional or more general
> tasks. The "ClassExportFilterBase" and the subclasses would be the builder
> classes then. They contain a refernece to the QTextStream for the output.
> It must be build in the director, because the director knows about the
> output file name. The function getHTML() I proposed is not necessary, if
> you write to a QTextStream directly. It is also possible to have the
> instance of QTextStream in the director and you would pass it by refernce
> to each getXXX function then, so that the function can write, what it has
> to write. Well, that is a question of taste then.

Applying my comment of yesterday to myself, I have found that the thing with 
QTextStream or QDataStream is also very limitating. I have thought today that 
what you call the builder should have full control of the export file.

That means that the director must "open" the file in the builder, then 
"write" the file by using the various methods of the builder and finally 
"close" the file at the end, like something you would do with a QFile.

This way permits the builder to be as small or as (big and) powerful as 
needed by the export file format. It also permits to use a DOM in the builder 
if necessary but does not force to use a DOM for simplier file formats.

> The classes of libexport look very general (are they)? And can maybe used
> for the other koffice parts as well. KWEFBaseClass with the above mentioned
> changes would then be the abstract base class for a number of builder
> classes.

Yes, they are very generic, because I had to stop halfway.

>
> I hope I understood your design right. There is not much class/method
> documentation and I didn't read the whole code. So please correct me, if I
> understood anything wrong.

Sorry, documentation for the library was planned for when the library would 
be finished! And the ASCII export filter never had any documentation of its 
mechanism.

>
> Hopefully you understand, I rather want to enlarge the field, where your
> work can be used than to reduce it. Sorry again, if you felt that way.
>
> I really would like to see full html and latex export filters for kspread
> and kformula, and maybe also for kpresenter. The html show is already quite
> useful, but in some occasions one needs a real html filter. And the latex
> export for kspread would be wonderful, because in my work, we do
> experiments and write reports in latex. So why not have data in kspread
> sheets and export them to data? Usually we also make CDs for companies with
> the material we worked on. That is where I need the html - not only for
> kword!
>
> What about latex? Robert JACOLIN is the maintainer, right? As far as I
> understand it, the filter looks like an interpreter - a tree that is build
> up first and that is traversed then to produce the output. Is that right?
> Mmh, I don't see a straight forward method to reuse things in a kspread
> latex export
>
> :-( Robert - what do you think?
>
> That was another long mail, although I should type... typist's neuritis :-(
>
> Greetings,
> eva
>
> > Have a nice day/evening/night!
_______________________________________________
Koffice-devel mailing list
Koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]