On 5 Dec 2007, at 18:23, Howard Shank wrote:
> 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.

>> I think that 3600 classes could be eliminated without loss of
>> functionality and it would always be possible to extends  
>> RtfCtrlWordBase
>> for some specific uses. This would probably allow iText to be
>> distributed in a single jar.
> I think 1/2 of the classes could be eliminated at the cost of not  
> being able to generate the RtfCtrlWordBase_* layer that handles  
> unimplemented control words. As for "it would always be possible to  
> extends RtfCtrlWordBase for some specific uses", each and every  
> keyword has a specific use that is different from other control  
> words and some control words serve multiple uses depending on the  
> current document state.
I can only agree with you here, RTF is a catastrophic format, as far  
as its design goes, and any implementation is doomed to become very  
complex and large.

> 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.

Regards,
Mark

-------------------------------------------------------------------------
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/

Reply via email to