DO NOT REPLY [Bug 24171] New: - [PATCH] 1st Attempt at Whole Site PDF
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171 [PATCH] 1st Attempt at Whole Site PDF Summary: [PATCH] 1st Attempt at Whole Site PDF Product: Fop Version: all Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This is my first attempt at getting a whole site PDF for the FOP web site. I've hobbled together some of what I've learned to create this. I doubt this will work (CVS is great!) so keep those backups at hand! I'd actually like to do what it takes to get FORREST onto my own box so I can test locally... Anyway, I've updated/created the following files: - sitemap-0.5.xmap (updated) - aggregate2document.xsl (added) - all-documents.xsl (added) It indicates in the code the locations where the two files should be added. I hope this is useful. I anticipate having to fix things, but I'm hoping this'll get us started! Web Maestro Clay
DO NOT REPLY [Bug 24171] - [PATCH] 1st Attempt at Whole Site PDF
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171 [PATCH] 1st Attempt at Whole Site PDF --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 07:05 --- Created an attachment (id=8766) aggregate to document converter
DO NOT REPLY [Bug 24171] - [PATCH] 1st Attempt at Whole Site PDF
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171 [PATCH] 1st Attempt at Whole Site PDF --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 07:06 --- Created an attachment (id=8767) Builds list of documents on the fly (all-documents.xml)
DO NOT REPLY [Bug 24171] - [PATCH] 1st Attempt at Whole Site PDF
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171 [PATCH] 1st Attempt at Whole Site PDF --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 07:06 --- Created an attachment (id=8768) updated sitemap-0.5.xmap file
RE: [VOTE] Two changes to 1.0 branch
Jeremias Maerki wrote: For example, we could easily make Peter Herweg a committer for the RTF libraries and renderer, but there is some hesitation (even on my part, who thinks Peter does good work) to turn him loose in layout until we know more about him, which takes time. In the meantime both he and we must work more slowly. Normally, you don't just go and mess around in other people's code if you don't know what you're doing. I think it's a relatively weak point to deny someone the committership only because of that. If Peter is able to handle the RTF output I don't see any problem allowing him to do that. If he grows into the other parts, so much better. Even I have never messed around in layout, yet. This seems to argue against having regulated commit access at all. IOW, on this same principle, everyone could/should be a FOP committer. Or, perhaps every Apache committer should be a committer on all projects. I doubt that is what you mean, but I guess ... I don't know what you *do* mean. The point is that if all of us had to be proficient on all Apache projects before being given commit access to any/all of them, it would take a long time to grow new committers. That is why FOP's monolithism is a drawback. Also, even if you haven't messed around in layout yet, you have discussed and voted on (IIRC) layout-related issues. There is an expectation that committers will have a feel for the project as a whole, and be able to contribute ideas. It probably sounds like I am crusading for something here, but I am not. Jeremias's original comments about FOP's monolithism rang true in my ears. Hearing no other proposed solutions to the problem, and seeing that mine is deprecated, I humbly acknowledge that it is an unsolvable problem, or perhaps no problem at all. Victor Mote
RE: [VOTE] Two changes to 1.0 branch
Glen Mazza wrote: Making a nice framework for others to create a FOP-like product is not as big a concern for me. I want to create FOP, not something to be used for creating a FOP. Hmmm. I think this comment is directed at me. WRT the first sentence, since this is open source with an Apache-style license, if we fail to make a nice framework for others to create a FOP-like product, then we have, by definition, failed to make a nice framework for FOP developers to create FOP. If a debate is needed here at all, it should be over whether such a framework is needed at all. WRT the second sentence, I guess I don't understand how failing to create things that can be used to create a FOP helps create FOP. It is like saying I don't want to build a foundation, I just want to build a house. Again, a debate about whether we are building something that needs a foundation or not might be interesting and useful. OTOH, maybe it would just be a waste of everyone's time. Victor Mote
Re: [VOTE] Two changes to 1.0 branch
On 28.10.2003 03:56:27 Glen Mazza wrote: Tom DeWeese of Batik made that suggestion a few months back--we're tentatively in agreement that once FOP gets solidified, the transcoders can move to them for their maintenance and documentation. Looks like I missed that one. I still haven't read everything from when I was on holidays. Good news, then, although that means that we have to do something about the PDF lib and the font code because I wouldn't want that duplicated. It should be somewhere accessible to both projects. The PDF transcoder could probably have long been promoted to 1.0 status already. Sie haben vergessen! PDF transcoder is distributed up with Batik right now--it's one of 1.0's few success stories. We don't even use maintenance for the transcoder--there's not a target for it in maintenance's build.xml. I know, but that doesn't count as a release IMO. It's snapshot that has been integrated in a release from another project. The Batik people haven't got control over the code they release. Documentation for the SVG transcoder is practically non-existent except for a few bits on the FOP and Batik sites. As always, our user base's primary concern is to have a product that can generate [absurdly high number of huge image-heavy documents] in [ridiculously small amount of time]. That is FOP's responsibility to Cocoon, Struts programmers, HP PCL users, Adobe PDF, etc. Right, and maybe parts of our user base will suddenly become active contributing Java code if we can make life for a newbie easier. That way, you don't have to do it all by yourself. I see the way of accomplishing this is by having FOP be (1) extremely fast and optimized; (2) extremely accurate; and (3) extremely focused on (1) and (2) above. Yep, I target (3) with my comments. Anyway, if FOP is unable to attract more developers it will never reach 1.0. Making a nice framework for others to create a FOP-like product is not as big a concern for me. I want to create FOP, not something to be used for creating a FOP. It is a concern for me. I believe that a lot of components that originated in FOP can be very interesting to use outside FOP. That's why it may make sense to talk about separating things off of FOP to make them available to a new audience and therefore heightening the possibility to attract new developers. FOP can profit from that, too. The XSL-FO layout engine is the main concern for this project. Everything around it (PDF lib, SVG support, font parsers etc.) is only infrastructure plus goodies. Jeremias Maerki
Re: [VOTE] Two changes to 1.0 branch
On 28.10.2003 14:40:29 Victor Mote wrote: Jeremias Maerki wrote: For example, we could easily make Peter Herweg a committer for the RTF libraries and renderer, but there is some hesitation (even on my part, who thinks Peter does good work) to turn him loose in layout until we know more about him, which takes time. In the meantime both he and we must work more slowly. Normally, you don't just go and mess around in other people's code if you don't know what you're doing. I think it's a relatively weak point to deny someone the committership only because of that. If Peter is able to handle the RTF output I don't see any problem allowing him to do that. If he grows into the other parts, so much better. Even I have never messed around in layout, yet. This seems to argue against having regulated commit access at all. IOW, on this same principle, everyone could/should be a FOP committer. Or, perhaps every Apache committer should be a committer on all projects. I doubt that is what you mean, but I guess ... I don't know what you *do* mean. No, it's not what I mean. I'm strongly for commit access per project and for having to earn it. Peter is one of the few who submitted more than just one patch in the past year. Since we're looking for new people wanting to contribute Java code he's the closest thing to that right now. You yourself started with documentation and now you're deep down in Java code. I'm not against regulated commit access, I'm talking about creating an incentive for people to join. Serious people. I believe that FOP was too restrictive in choosing its committers but that's easily explained I think: There used to be quite a lot of them. But they all went away for whatever reasons. The point is that if all of us had to be proficient on all Apache projects before being given commit access to any/all of them, it would take a long time to grow new committers. That is why FOP's monolithism is a drawback. Also, even if you haven't messed around in layout yet, you have discussed and voted on (IIRC) layout-related issues. There is an expectation that committers will have a feel for the project as a whole, and be able to contribute ideas. Yeah, but you should also be allowed to grow into these things. It probably sounds like I am crusading for something here, but I am not. I didn't think so. Jeremias's original comments about FOP's monolithism rang true in my ears. Hearing no other proposed solutions to the problem, and seeing that mine is deprecated, I humbly acknowledge that it is an unsolvable problem, or perhaps no problem at all. That doesn't bring us forward. We've only heard three opinions so far. We've got 430 subscribers to this mailing list and not only committers are allowed to express their opinions. Then there's also the people that actually do things and the others who only talk most of the times (like me lately). Well, there are the others who never say anything but that's the ones who don't have any fun at all. And you have to filter all that's being said, because you can never convey all your thoughts to the mailing list just the way you have them in your brain. We've got the big problem that we normally can't sit together and talk it out face to face. It would be much more productive and a lot less tiring. This is no unsolvable problem. We just have to find the best way which may also lie in between opinions. One way may just be not to do anything at all right now or another to let Glen put his no-nonsense proposal to action until there is enough energy to do really clean up the whole thing. Let's not all get frustrated. It's enough if I am having to do Delphi 50% of my time lately. Have fun coding, do what you can. Jeremias Maerki (who blabbers to much)
DO NOT REPLY [Bug 24195] New: - [PATCH] RTF: added support for nested blocks, inlines and several text attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24195. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24195 [PATCH] RTF: added support for nested blocks, inlines and several text attributes Summary: [PATCH] RTF: added support for nested blocks, inlines and several text attributes Product: Fop Version: all Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, i'd like to submit the attached patch and modules. They add support for blocks (also nested), inlines (also nested), underlined, italic, space-before/-after. Sorry, this is a quite large patch. I could not keep it small. Thanks and kind regards Peter Herweg
DO NOT REPLY [Bug 24195] - [PATCH] RTF: added support for nested blocks, inlines and several text attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24195. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24195 [PATCH] RTF: added support for nested blocks, inlines and several text attributes --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 23:04 --- Created an attachment (id=8788) patch file
DO NOT REPLY [Bug 24195] - [PATCH] RTF: added support for nested blocks, inlines and several text attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24195. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24195 [PATCH] RTF: added support for nested blocks, inlines and several text attributes --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 23:05 --- Created an attachment (id=8790) new module (to be placed into org.apache.fop.rtf.rtflib.rtfdoc)
DO NOT REPLY [Bug 24195] - [PATCH] RTF: added support for nested blocks, inlines and several text attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24195. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24195 [PATCH] RTF: added support for nested blocks, inlines and several text attributes --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 23:06 --- Created an attachment (id=8792) new module (to be placed into org.apache.fop.rtf.renderer)
DO NOT REPLY [Bug 24171] - [PATCH] 1st Attempt at Whole Site PDF
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171 [PATCH] 1st Attempt at Whole Site PDF --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 23:36 --- Forrest is one of the simplest applications to run locally--the Forrest Team did a great job with a very simple (4 or 5 command) CLI. A real joy to work with. So please test locally first. Just install Forrest, go into the FOP root directory, and just type Forrest. It will read the forrest file in the root and start regenerating all the files for you locally.
DO NOT REPLY [Bug 24171] - [PATCH] 1st Attempt at Whole Site PDF
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24171 [PATCH] 1st Attempt at Whole Site PDF --- Additional Comments From [EMAIL PROTECTED] 2003-10-29 00:22 --- Thanks! I'll check it out!
