I guess that splitting the RTF parser into another jar is the solution.
Paulo
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Howard Shank
> Sent: Wednesday, December 05, 2007 7:04 PM
> To: Post all your questions about iText here
> Subject: Re: [iText-questions] RTF Parser update
>
> >> There are so many control words in the RTF spec that I tried to
> >> simplify the creation of the classes through automating the
> >> generation of them. This way new control words
> (RtfCtrlWordBase_*)
> >> can be added through the generation process without disturbing
> >> manual coding that may change the RtfCtrlWord_* classes.
> (I may have
> >> caused some confusion because I have generated all RtfCtrlWord_*
> >> files without implementing them yet.) If the RtfCtrlWordBase_*
> >> classes are eliminated the ability to re-generate the class files
> >> without overwriting modified files is also eliminated.
> >I'm not quite sure, but wouldn't eliminating the RtfCtrlWordBase_*
> >classes only mean that the generation code needs to be a bit
> smarter,
> >not that it cannot be used anymore? That would reduce the number of
> >files by 50%, a major saving. As the generation process is
> only to be
> >called on new specification versions, I feel that would be a
> >worthwhile improvement.
> Yes, I could spend more time on the generator to be better at
> creating the classes! I'm still working on it anyways.
> In reality, unless an update adds more control words than one
> would want to copy/paste/modify classes the regeneration
> would not happen.
>
> >> Above all, parsing and handling the RTF spec is complicated and I
> >> wanted to make the parser easy for others to work with by making
> >> classes that perform specific functions. The parser needs to be
> >> seperated from the control word handling logic.The control word
> >> manager should be responsible for handing off the control
> word and/
> >> or values to the appropriate handler. Having one class
> that tries to
> >> handle unknown different situations through a bunch of logic (if/
> >> switch/etc.) statements would be a poor and confusing
> design in my
> >> opinion.
> >I definitively agree with this approach. I have tried RTF
> generation
> >in a single and then in a few classes and it becomes unmaintainable
> >very quickly, and RTF generation is a lot simpler than
> parsing it. We
> >are stuck with a large and complex parsing component, so
> possibly it
> >is inevitable that we provide at least part of it as a separate jar.
> Having to split the parser would not be the end of the world!
>
> Howard
Aviso Legal:
Esta mensagem é destinada exclusivamente ao destinatário. Pode conter
informação confidencial ou legalmente protegida. A incorrecta transmissão desta
mensagem não significa a perca de confidencialidade. Se esta mensagem for
recebida por engano, por favor envie-a de volta para o remetente e apague-a do
seu sistema de imediato. É proibido a qualquer pessoa que não o destinatário de
usar, revelar ou distribuir qualquer parte desta mensagem.
Disclaimer:
This message is destined exclusively to the intended receiver. It may contain
confidential or legally protected information. The incorrect transmission of
this message does not mean the loss of its confidentiality. If this message is
received by mistake, please send it back to the sender and delete it from your
system immediately. It is forbidden to any person who is not the intended
receiver to use, distribute or copy any part of this message.
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
iText-questions mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://itext.ugent.be/itext-in-action/
