Peter Herweg wrote:
i'd like to spend again some time with enhancing the RTF support. I have
been inactive for over a year now (sorry, i was quite busy). Do you want me
to send patches, because i was inactive for such a long time? Or can i
access the svn repository?
I have received the fop-dev-mailing list, but usually have only read the
Welcome back and as Jeremias said, its okay to commit without sending
I'd like to accomplish following tasks:
(1) FOP has already support for white-space-treatment, linefeed-treatment
and white-space-collapse. But the results of these implementations are only
availabe in RTFHandler.endBlock. So i had introduced delaying processing of
the FOs until endBlock. Unfortunatelly this makes the code quite complex and
buggy, so i want to remove this (of course the rtf module won't support
above mentioned attributes any longer).
I don't like the idea of removing functionality. I read point (4) below
and see that you intend to support for white-space-treatment again, but
you can't think of a new approach. I think I understand the problem and
I also think the current solution is the only one! So stick with it and
see if you can fix the bugs.
(2) I want to test support for fo:table. This had worked quite good before i
introduced the delaying. But now the table-columns get not processed. This
will be fixed when (1) is finished. Sorry, i didn't notice this malfunction.
Can this not be achieved with (1) still in place?
(3) Add support for baseline-shift="sub" and baseline-shift="super".
(4) After all that i have to think about how we can get
white-space-treatment, linefeed-treatment and white-space-collapse to work.
The difficulty is that RTFHandler handles text nodes in its implementation
of FOEventHandler.characters. But at this time FOP's algorithms have not
been run. Currently i see three possibilities (just ideas: any comment
a. Find a solution without delaying processing any FOs. (I don't know how
this could work, in spite of implementing the complete algorithm by myself
just for the RTFHandler. Maybe this is the worst solution.)
IIUC you are saying you don't know how to solve (1) another way, which
is why I think you should not remove that code.
b. Find a solution by delaying *every* FO. This would make the
FOInputHandler interface useless, because i just had to wait for a
particular event (e. g. endPageSequence) and then iterate the passed
PageSequence object. Would be a great effort and would introduce the same
problems as described in (1).
This is the current solution and the only realistic one IMHO.
c. Maybe i should not process the text nodes in FOEventHandler.characters
but simply add a placeholder to my rtf. When i reach endBlock i have to
iterate the passed Block object and search only for FOText objects. The
contents of these FOText's have to replace the placeholders.
Sounds like a lot of work to me and prone to the sorts of problems you