Bertrand Delacretaz wrote: > If you're going to work on the RTFHandler I'd be happy to commit the > relevant jfor sources (the RTF library I assume) to the FOP codebase > with appropriate package name changes.
Yes, I think the RTF libs are the only parts that are needed. I don't want to mislead anyone into thinking I'm making a big commitment here -- it will probably be a little here and a little there. > As Jeremias mentions, it might be better if I do it myself so that the > legal stuff is clear. > I should be able to do it between today and tomorrow. > > The idea of using jfor in binary form at first was to avoid having to > maintain two RTF libraries - but if you're going for it, then the time > might be right to actually move the code here. Again, "go for it" is too strong. However, I think integrating the libraries is a necessary prerequisite for any real progress. > > .. Some of the source files contain non-ASCII characters (see > > main/JForVersionInfo.java, line 67, for example), but are encoded as > > ASCII > > (instead of UTF-8), so the IDE was choking... > > Are .java files meant to be encoded in UTF-8? I didn't know that. Java source is Unicode, and I don't think the encoding would matter, but UTF-8 makes the most sense as most of the source is ASCII. And it could be that most tools don't care, but I know that JBuilder does. > > ...dropping in the Apache license (looks like no problem), > > no problem indeed > > > and some > > style issues.... > > Do you mean code writing style like brace positions and stuff, or > deeper code structure issues? I'm talking about the superficial stuff, $Log$ being the most obvious, and there may be some that checkstyle doesn't like. As far as the code structure, what I saw was clean and easily understandable. The only real trouble I had was finding ATTR_ constants, and I may very well be using the wrong ones (but they work). I had the RTF standard in hand as I was working through it, so I was able to reverse-engineer some of it by looking at the strings that the jfor constants were using. So I might try to document or otherwise clarify some of that stuff in the code. On the paragraph shading that I was messing with, I tried dropping the RTF codes directly in, and something downstream (probably in the actual document creating) seemed to be filtering out or ignoring them, which is why I was going to try to follow the code through that process in the debugger. It may be that some of that is documented in that downstream location. So, if there is some doc on the RTF libs, especially a mapping of what attributes are used with each RTF object, and which of the overloaded methods to use with each, that would be extremely useful. It seems like the wiki said to look at how the conversion tools used them, but that didn't seem to help much. Does it make sense in the long run for the jfor libs to be a separate project? It seems like it should have wider appeal than just for FOP, although FOP is probably a good home for it for now. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
