Re: Good job! / Re: Integration of TIFFRenderer in FOP
Le 9 mars 05, à 01:12, Glen Mazza a écrit : ...[Thanks also to Bertrand for sending Renaud our way. This is the second quality developer--Peter Herweg being the other--that we have gotten from him since I've been on this project.].. You're welcome - and you don't even know how many people I sent your way that did not make it ;-) (just kidding - I'm happy to contribute, even if it's just helping convince people to jump in) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Merry Christmas everyone!
Le 23 déc. 04, à 20:56, Glen Mazza a écrit : ...(OK, think I got everybody... ;-) Thanks Glen...actually to go the full i18n route, here's a special one for Jeremias: Jöni wnachte! and Peter: Merry Christmas Mate! I reckon! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Good news: Jeremias has been elected as an ASF member!
Hi FOP people, I have the great pleasure to announce that Jeremias Maerki has been elected as an ASF member at the last member's meeting during ApacheCon. I'm sure you will agree that this is well deserved, given all the energy that Jeremias has been pouring tirelessly in FOP, Batik, the XML federation and probably many things here that I don't know about. /me happy ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: XML Graphics: board concerns
Le 24 sept. 04, à 02:54, Glen Mazza a écrit : ...Ummm, wasn't Peter Herweg (whom Bertrand recommended) the FOP committer who brought JFOR into FOP, and the one who has maintained it for us since then?.. This part is not very relevant to the current discussion I think, but: I don't have a very good memory either...in your case I would recommend a good dose of mailing list archives before going to bed...maybe add some jfor.org bedtime reading ;-) Please don't rewrite history. And if you want to follow the jfor to FOP evolution in detail you're forgetting Victor Mote as well. ...I'd like Finn Bock to be added to the PMC before we consider adding inactive committers... Please be careful how you use the word inactive. I suspect this is targeted at me, in which case it is very right as I have done very little for FOP in actual code, but have you looked at the mountains of work that Keiron has done here earlier? I find dismissing him because he's *currently* inactive, without consideration for his former work, inappropriate (I was going to say unrespectful even). To sum up my position: I think the XML Graphics thing is a good idea, and connections to Cocoon are certainly good as well. As I said to Jeremias, I cannot promise much in terms of actual code contributions to the projects at this point, but if I can help by making connections between the projects I'm happy to do it. -Bertrand
Re: XML Graphics: board concerns
Following Glen Mazza's comments, I realize he's meant to be on the XML Graphics PMC as well (IIUC). In this case I think I prefer not to be part of the PMC. This deserves some explanation: I find it very hard to communicate efficiently in email with Glen, this morning for example it took me more than half an hour to reply to his false statements about jfor while trying to avoid a flame war. This is not the first time this happens, so it's probably not the last either. So, I think it would be too hard for me to sit on a PMC with Glen, I'm afraid it would use too much of my energy as it's so hard for me to communicate with him. Sorry for not realizing this earlier - the logical thing is probably for me to turn down the offer at this point, to avoid future problems which might hinder the PMC's progress. I suspect other people have a hard time coping with Glen's way of communicating here, but I won't talk for them - this is only about myself. Thanks for your understanding. -Bertrand
Re: XML Graphics: board concerns
Le 20 sept. 04, à 21:59, Jeremias Maerki a écrit : ...If one of the two would like to take the chair position I'd gladly restart a vote on that part... I'm happy with Jeremias (IIUC) being the proposed chairman, I don't want (or deserve by the way;-) the position. -Bertrand
Re: [VOTE] Luca Furini for Committer
Le 14 sept. 04, à 20:47, Simon Pepping a écrit : I propose that we make Luca Furini a member of the FOP team... +1 from a (very) inactive committer - having new people on board is Good News! -Bertrand
Re: Cocoon appears to be switching to 1.4
Le Mercredi, 3 mars 2004, à 10:27 Europe/Zurich, Chris Bowditch a écrit : Glen Mazza wrote: They're currently voting on the Cocoon side[1] to set 1.4 as the minimum JDK for their next 2.2 release. So far it looks good for approval. I'm not so sure it does, look at the 3rd mail in the thread: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107813002510299w=2 and this sparks off a debate about how many users still require 1.3, etc You're right, this is only being discussed at the moment. And if the switch to 1.4 happens, it will only be (AFAIK) with the Cocoon 2.2 release, for which there is not set date at the moment. Also, there is a push to keep the requirement at 1.3 for the Cocoon core, leaving blocks free to require either 1.3 or 1.4. So it might be better not to let this influence the FOP decision. -Bertrand
apologies to Nikolai Grigoriev? (was: Just a small question...)
executive summary: ARE YOU GUYS CRAZY? Le Jeudi, 5 fév 2004, à 21:28 Europe/Zurich, Nikolai Grigoriev a écrit : I realize I was wrong when I answered to this forum - I could not expect my words to be interpreted this way. Please disregard my previous message; I also unsubscribe from the list, to make you feel sure I don't induce anyone into wrongdoing. ... I'm pissed (not my usual language but cannot find a better word) at the discussion which caused this to happen. People, look at the archives: Nikolai has been kind enough to give input and share his thoughts here several times, even if it meant disclosing some information about RenderX at times. Thanks Nikolai. Now he's being accused of trying to inject proprietary information into FOP - this is plain surrealistic. I though RESPECT was a given on these lists but apparently it is not for everybody. In my opinion public apologies are due to Nikolai. Whether he chooses to stay or go is his choice, but letting him go without a word would be another lack of respect. Nothing personal against anyone - everyone does mistakes at times, the question is whether you try to fix them (or rather, fix what's left) and learn from them. I tried to refrain from mixing in this as I'm not contributing to FOP currently, but this is too much. I still care for this project and hate to see such things happen. -Bertrand
Re: [VOTE] Andreas L. Delmelle for committer
Le Dimanche, 28 déc 2003, à 15:38 Europe/Zurich, Jeremias Maerki a écrit : In recognition for his contributions to this project I'd like to propose Andreas L. Delmelle as a FOP committer. He's active on both dev and user mailing lists for over 6 months now. He's actively helping out on the user mailing list and shows interest in FOP development. Provided he accepts the nomination, I'd like to have him on the boat. IIUC Andreas has declined the offer based on Glen's -1, but anyway here's my +1 To show my support: If Andreas shows committment to the project he can IMHO be a committer without necessarily having to commit code to CVS. -Bertrand
Re: [VOTE] Clay Leeds for committer
Le Dimanche, 28 déc 2003, à 15:38 Europe/Zurich, Jeremias Maerki a écrit : In recognition for his contributions to this project I'd like to propose Web Maestro Clay Leeds as a FOP committer. He's active on both dev and user mailing lists for at least 1 year now. He's actively helping out on the user mailing list and as our favourite nit-picker :-) he was instrumental in improving our website. Provided he accepts the nomination, I'd like to have him on the boat. +1 -Bertrand
Re: [VOTE] Chris Bowditch for Committer
Le Dimanche, 28 déc 2003, à 15:38 Europe/Zurich, Jeremias Maerki a écrit : In recognition for his contributions to this project I'd like to propose Chris Bowditch as a FOP committer. He's active on both dev and user mailing lists for at least 18 months now. He's actively helping out on the user mailing list and shows interest in FOP development. Provided he accepts the nomination, I'd like to have him on the boat. +1 -Bertrand
Re: [VOTE] Finn Bock for Committer
Le Dimanche, 21 déc 2003, à 22:53 Europe/Zurich, Glen Mazza a écrit : ...Therefore, I'm happy to nominate Finn Bock for committer--here's my +1. Seems like no one has voted on this yet? Must be this Christmas thing... Here's my +1 -Bertrand
Re: [VOTE] Peter Herweg for committer (WAS: problem applying latest RTF patch)
Le Lundi, 24 nov 2003, à 23:03 Europe/Zurich, Victor Mote a écrit : Glen Mazza wrote: [Incidentally, this someone else can be Peter himself at this stage...I'd like to see a little bit more FOP-DEV/-USER ML communication from him, however the quality quantity of his patches have been very good. I'm open for making him committer should others also feel this way at this time.] Although currently inactive, I'm particularly happy to cast my +1 on this one. Thanks Peter for all the work you already did integrating/improving jfor! -Bertrand
Re: [proposal] Peter Herweg as a FOP committer
Le Vendredi, 12 sep 2003, à 20:51 Europe/Zurich, Glen Mazza a écrit : ...Thanks for taking the time to clarify your ideas on this issue. You're welcome - and in retrospect mine *was* a crazy idea indeed. This written communication thing again - had we been together around a table this would have been solved in three minutes ;-) -Bertrand
[proposal] Peter Herweg as a FOP committer
Hi FOPpers, I'm making this a proposal instead of directly a vote, as there are two unusual things here: I've been recently (and rightly) moved to inactive committer status, and it hasn't been a long time since Peter submitted his patches. The reason I'm proposing him is that Peter is willing to work on the RTF renderer, which he needs for his job where he's doing reporting stuff in RTF and PDF. He's been a committer in jfor since this summer, and has commited some very useful patches and corrections. If no one objects, I'll move this to a proper vote so that Peter can start working efficiently on the RTF stuff as soon as possible. -Bertrand
Re: [proposal] Peter Herweg as a FOP committer
Hi Glen, I must say I'm very surprised at your response: not the -1 which I can accept, but the response below where you don't seem to have understood my aim, and the arrogance of which I dislike a lot. Thanks Jeremias, Victor and J.Pietschmann for your support, you seem to have gotten the idea. I feel FOP is very much in need of active committers, and my definition of committer goes further than someone who commits code to CVS. Even though inactive codewise, I try do my best and actually lift my finger when I can do something for the project, in the strict limits that I have to impose myself due to a chronically overstuffed schedule. I've known Peter (virtually) for a few weeks and I have a good impression of him and his code. Earlier this week he told me that he had some free time and was willing to work on the FOP RTF stuff, which seemed worth of encouragement to me. What better encouragement than quickly becoming a committer? I know perfectly that there are (largely unwritten) rules about when someone can be proposed as a committer, and my proposal didn't respect all of them. Hence a [proposal] and note a [vote]. Maybe this should have been called [wild idead] instead. I'd have no problem with a please wait for some more stuff from Peter answer, but it is hard to take your aggressive tone. I don't want to comment on all your points, they are mostly your opinions. I will comment on those that might make a difference for the project, though. ...Committership is a months-long-process, and I'll need to see contributions from your individual named well past those of Chris, Clay or Andreas before we consider such a move. FYI, he's at about 1% of them right now I haven't followed in detail what Chris, Clay or Andreas have done, but if they're contributing more or less actively to FOP, why not propose them as committers? Might motivate them to do even more. ...Maybe if you had decided to lift a finger for the project and *apply* his patches your proposal would have carried more weight... This I can understand. My idea was that maybe Peter would be able to commit his own patch, as his first job. ...You just insulted the entire FOP team--committers and contributors--with your ridiculous suggestion... You have the right to find my suggestion ridiculous, but I don't think it is insulting for the entire team. If *you* feel insulted then accept my apologies, it was not my goal in any way, again just trying to help the project. Sorry if I didn't explain my objectives clearly enough, but everyone has the right to ask for clarification - and, if you allow me some old man advice, it is usually good to do when you think something is wrong, before getting the cannons out. ...It would probably be best for the project for you to keep yourself inactive I guess this is for the active committers to decide . Ciao, Bertrand --- Bertrand Delacretaz [EMAIL PROTECTED] wrote: Hi FOPpers, I'm making this a proposal instead of directly a vote, as there are two unusual things here: I've been recently (and rightly) moved to inactive committer status, and it hasn't been a long time since Peter submitted his patches. The reason I'm proposing him is that Peter is willing to work on the RTF renderer, which he needs for his job where he's doing reporting stuff in RTF and PDF. He's been a committer in jfor since this summer, and has commited some very useful patches and corrections. If no one objects, I'll move this to a proper vote so that Peter can start working efficiently on the RTF stuff as soon as possible. -Bertrand __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- Bertrand Delacretaz independent consultant, Lausanne, Switzerland http://cvs.apache.org/~bdelacretaz/
Re: Place committers on inactive list?
Le Mardi, 2 sep 2003, à 03:33 Europe/Zurich, Glen Mazza a écrit : ...Perhaps Karen, Arved and Bertrand should be added to the inactive list... No problem for me, I'd actually feel better being listed as inactive! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Just a stupid question ... =P
Le Vendredi, 11 juil 2003, à 18:50 Europe/Zurich, [EMAIL PROTECTED] a écrit : ...But we hav to generate a big catalog (more than 1 000 pages) and FOP throws a OutOfMemoryException after 700~800 pages (depends on the number of images integrated) Most probably, making more memory available to the JVM that runs FOP would solve your problem. With Sun's JVMs this is done by adding -Xmx to the JVM command line, for example -Xmx 512m to make the JVM use 512 megabytes max. -- Bertrand Delacretaz independent consultant, Lausanne, Switzerland http://cvs.apache.org/~bdelacretaz/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Just a stupid question ... =P
Le Samedi, 12 juil 2003, à 10:27 Europe/Zurich, Jeremias Maerki a écrit : lots-of-good-stuff-snipped/ ...If you think this is a stupid bug, then my all means sit down and try to fix it +1, I could not agree more ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RTF] jfor progress
Hi Victor, Thanks for your work! ...I *really* like the approach of having the independent package, and recommend that we use the same approach for other StructureRenderers, including MIF Yes, the StructureRenderer interface nicely decouples these renderers from the rest of FOP. Maybe a new build target that creates a standalone fop-rtflib.jar would be good? I'd still keep rtflib in the main fop.jar, but offer a standalone rtflib in addition. Note that the interest for a MIF renderer is probably lower than it was before, as newer versions of FrameMaker can import XML directly and combine it with (homegrown) style mappings. ...1. How much does the API need to be protected? Are we pretty free to change it as we see fit, or will that mess up existing jfor users too much? ... It is hard to say, although there have been several thousand downloads of jfor since it was created, the feedback from users is comparatively very small so we don't have a precise idea of how many people are doing what. I know some people are using the RTF API directly, but have no idea how many. I think you can go ahead with API changes that improve the library or are required for refactoring (see below comments about RtfText). ...Specifically, I am tempted to move some of the constants (alignment and indentation for example) in RtfText to RtfParagraph for a more intuitive interface Makes sense. An alternative would be to define constants in interfaces (RtfAlignConstants, RtfParaConstants etc) to group them, and have the classes that use them implement these interfaces to make the values directly available. This would be more compatible with the existing API I think. ...what do you think of the idea of building a Border object with those axes as properties... Sounds good. IIRC this border stuff has been contributed in small bits and pieces to jfor, with no real design, so some refactoring is welcome. ...I'm guessing there are some other concepts that will benefit from such an approach as well Yes, you've probably seen code that is too linear and could benefit from better object design. ...have changed RtfParagraph.writeRtfPrefix() to write the text attributes as well as the paragraph attribute If one can still set text attributes on individual text runs inside a paragraph as well, then fine. I'm not happy with the current design of RtfText embedded in RtfParagraph - although this maps well to the XSL-FO model (elements), it does not map well to the RTF model (text runs I think, but still somewhat mysterious after all these years ;-). This causes problem in jfor where nested paragraphs and inlines are sometimes output in the wrong order. I think a flatter design of the RtfText vs. RtfParagraph model would help. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [FW:] RE: 0.20.5 release
Le Mardi, 8 juil 2003, à 10:14 Europe/Zurich, Thomas Sporbeck a écrit : ...It might be a fundamental decision if FOP is a kind of toolbox for developers or if it should be an out of the box-product for nearly everyone - I think there's so much good ideas in it that everyone should be able to use it I might be wrong, but I think most users of FOP are using it server-side, where resources (especially memory) are more readily available. This might explain your problems, I think little energy has been spent to optimize FOP's memory requirements. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: .cvsignore
Le Dimanche, 6 juil 2003, à 03:32 Europe/Zurich, Peter B. West a écrit : ...Speaking from blissful ignorance, I would speculate that the entries in .cvsignore must be ordinary files, not directories. CVS is going to navigate the tree anyway, but .cvsignore tells it what to do with the files it finds in each directory According to the CVS FAQ (http://www.loria.fr/cgi-bin/molli/ fom.cgi?_highlightWords=cvsignorefile=271) this is not the case, directories are indeed ignored. ...J.Pietschmann wrote: Hi, the .cvsignore features a quite prominent build entry. However, Eclipse thinks there is s lot of uncommitted stuff in this directory, which I find annoying. Isn't it supposed to ignore this?... it is - the .cvsignore from the current CVS works fine here with command-line CVS, build is ignored. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Java source encoding (was Re: [RTF] Jfor integration)
Le Vendredi, 4 juil 2003, à 21:12 Europe/Zurich, J.Pietschmann a écrit : Bertrand Delacretaz wrote: Sure - it is by accident that comments in the jfor source code contains non-ASCII chars (in people's names IIRC). OOps, I didn't think about that. We could What I meant is that I think (or rather hope) people are ok to have their names spelled slightly wrong in source files. I don't think it's worth the hassle to worry about encodings just to write contributors names. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Java source encoding (was Re: [RTF] Jfor integration)
Le Jeudi, 3 juil 2003, à 21:16 Europe/Zurich, J.Pietschmann a écrit : ...And, uh, comment language is *english*, guys :-) Sure - it is by accident that comments in the jfor source code contains non-ASCII chars (in people's names IIRC). No problem in removing the accents! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RTF] Jfor integration
...Do you mind if I rework that a bit so that the standard header is intact, and then add the additional credits for the jfor team below?... No problem - I didn't know that checkstyle cared for this as well. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RTF] Jfor integration
Le Mardi, 24 juin 2003, à 20:27 Europe/Zurich, Victor Mote a écrit : 1. org.jfor.jfor.interfaces (see rtf/rtflib/rtfdoc/IRtfTableContainer.java, line 56, for example) 2. org.jfor.jfor.tools (see rtf/rtflib/rtfdoc/RtfExternalGraphic.java, line 62, for example) obviously these are needed - sorry about that, I have added them now. I'm just fixing the licenses now, but the files are there already. I saw some references to members of the converter package as well, but those looked like optional things that can be commented out. that's right, there shouldn't be dependencies in this direction, these will need to be refactored if they are needed. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: Structure renderers area trees (Re: startup refactoring)
Le Lundi, 23 juin 2003, à 10:35 Europe/Zurich, J.U. Anderegg a écrit : ... How do you plan to handle RTF styles? In jfor we defined an extension to XSL-FO (the jfor-style attribute) to control RTF styles. Another way would be to recognize sets of attribute values in the input XSL-FO and map them to RTF styles. I think some form of extension is needed as (AFAIK) the concept of styles does not exist in XSL-FO, as it is meant for printed output. If you import XML in the newest versions of FrameMaker for example, you have to define a kind of style map which recognizes specific constructions in the XML and assigns styles to them. This might also be an option, use a second input file that tells FOP which (MIF or RTF) styles to assign when certain patterns are recognized in the input. ...Is it difficult to transform tables and lists? Not too much, but when we developed jfor we targeted it at RTF 1.5 which as no support for nested tables, so we had to fake them using joined cells (as older versions of Word did). Other than that, the tables and lists structures of XSL-FO map nicely to RTF. Possible problems are relative dimensions, for example it might be hard in RTF to say that a table must take 60% of the page height. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: AW: Structure renderers area trees (Re: startup refactoring)
Le Lundi, 23 juin 2003, à 12:08 Europe/Zurich, J.U. Anderegg a écrit : Bertrand Delacretaz wrote: ...In jfor we defined an extension to XSL-FO (the jfor-style attribute) to control RTF styles (1) This is not a FOP extension, but rather a fundamental change of the XSL-FO language, which does not know stlye sheets. What I called extension applies to XSL-FO, or rather to the input documents handled by jfor, which use the jfor-style attribute in addition to standard XSL-FO. You're right that this is not a FOP extension. This can be implemented cleanly with namespaces, so as not to pollute the XSL-FO input, something like fo:block font-size=12pt style:name=someRtfStyle Meaning that the style names are decorations to the input document. ...(2) I wrote a few weeks ago this and it is still my idea, how FOP should store properties: Apply the principles of relational databases to eliminate redundancies: set up tables of unique/used fonts, strokes, colors, ... and have the objects reference table entries Sounds reasonable, but I don't know enough about the current properties code to comment on this. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers area trees (Re: startup refactoring)
Le Dimanche, 22 juin 2003, à 21:15 Europe/Zurich, Arnd Beißner a écrit : ...Before we're getting too philosophical, let me say that we're now talking two different issues: 1. Is it possible to develop a conforming XSL:FO implementation that produces RTF or MIF or similar ouput? Probably not, XSL-FO is clearly meant for page output and RTF and MIF (unless abused in strange ways) are document formats, not page formats. 2. Are there really two different groups of output formats and does it really make sense to support both in one tool (FOP) There are definitely two groups, and I agree with you that All of the stuff needed for FO-RTF or FO-MIF conversion is pretty straightforward stuff The whole point of the StructureHandler interface is to be able to reuse FOP's frontend for structure-based renderers. The impact of StructureHandler on the standard FOP output formats (PDF mostly) is minor, but it allows the FOP pipeline to branch cleanly, after the parsing and attributes resolution, to generate either structure-based or page-based formats. Besides sharing code, the advantage in RTF and similar output formats being developed as part of FOP is the community: one project with more audience instead of several, each with a smaller audience. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RTF] Jfor integration
Hi Victor, I have committed the classes from the jfor RTF library under org.apache.fop.rtf.rtflib. They don't compile out of the box, so I disabled their compilation in build.xml for now, didn't have time to look further. The next step would be to get them to compile, have the RTFHandler use them and remove jfor.jar from the lib directory. You will probably find dependencies to other parts of jfor, let me know if you need more classes (but hopefully most of those dependencies are not 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... fine - we'll see what happens! ...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... yes, idea for example uses a configurable file encoding. ...if there is some doc on the RTF libs, there is none ATM. ...t seems like the wiki said to look at how the conversion tools used them, but that didn't seem to help much. Feel free to ask if you have questions. There is also the testdocs package some parts of the RTF library. 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. I think FOP is a good start. It would be easy to create a separate rtflib.jar if needed. By creating another project we would lose the FOP community, it is certainly better at this point to strengthen it by adding new features to FOP. What's sorely missing IMHO is a way to validate the generated RTF other than by crashing word processors. If you hear about an RTF validator or an RTF parser grammar it would be a welcome improvement. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RTF] Jfor integration
Hi Victor, 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. 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. .. 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. ...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? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Nomination of Glen Mazza as committer
Le Lundi, 16 juin 2003, à 02:12 Europe/Zurich, Victor Mote a écrit : ...However, I think it is appropriate to nominate Glen Mazza for committer status +1, welcome! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Conversion from src/org.. to src/java/org..
Le Vendredi, 7 mars 2003, à 17:39 Europe/Zurich, Jeremias Maerki a écrit : ...My main motivations for the move as such: - Easier handling of FOP in IDEs - Best practices confirmance - Finish what we (I) started +0.5, the IDE thing might be useful. As an option, we can also agree to do the same in the maintenance branch, -0, I don't see a need here. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Integration of Peter's work
Peter B. West wrote: . . . What will be interesting here is the possibility of defining a set of structure events for integration with the structure renderers like RTF, and I hope we can have some fruitful discussions with Bertrand on this. Looks promising, let me know where to look when the time is right. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
JforIntegrationInFop - background and guidelines
Hi FOP team, Due to popular demand (well, two people anyway), I have written this at the Wiki: http://nagoya.apache.org/wiki/apachewiki.cgi?JforIntegrationInFop It explains my (hopefully our) motivations for integrating jfor into FOP, and how we could proceed on this. I'll be off for skiing (assuming snow comes) for a few days, so even quieter than usual. -- Bertrand Delacretaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, Cocoon, FOP, mentoring/teaching/coding. blogspace http://www.codeconsult.ch/bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FOP wiki pages moved
As there is now an official Apache wiki [1], I moved the pages that were on my server to http://nagoya.apache.org/wiki/apachewiki.cgi?FOPProjectPages Please do any further work on them there. They still need some cleanup after moving, I'll do it in January unless someone finds time to do it before. -Bertrand [1] as announced on community@ - thanks Andy Oliver! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Happy Holidays
Happy Holidays team - I've been very quiet lately but this is *definitely* a good crowd, I wish I could spend more time here! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
On Sunday 01 December 2002 22:26, Oleg Tkachenko wrote: . . . J.Pietschmann wrote: I think we should leverage final more often in FOP. At http://codeconsult.ch/wiki/index.php/FopDevelopersStyleGuide we've got +2 vs -2 on this point, so taking into acount your opinion it's +3 vs -2 now. I think the +2 vs -2 that you mention refer to declaring variables in the inner scope, not precisely to using final or not. This thing about final is really minor IMHO, I think it's a good practice and should be mentioned as such, but I wouldn't make any checks on it. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP Servlet, contrib stuff and tutorial
On Wednesday 27 November 2002 09:36, Keiron Liddle wrote: On Tue, 2002-11-26 at 13:53, Jeremias Maerki wrote: . . . Problems that need to be addressed: - All Java sources need to be checked easily before a release (do they compile, do they work?). Could ant call help out here? No extra build.sh or build.bat. . . . The ant ant task can easily call an external build.xml. The cvs task allows sources to be checked out (but AFAIK requires command-line CVS to be installed on Windows systems). -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
On Thursday 21 November 2002 17:16, Jeremias Maerki wrote: . . . The MUST part is very small and establishes some hard rules. I'll try to do the final layout in XML in a way that takes this into consideration. ok, cool! . . . By the way, due to common desire I added a few lines on exception handling and a few other items that I found were agreed upon in recent discussion. I added note 4 to propose a different/additional way of saying that exceptions are important. I'd put this stuff about exceptions as a subsection in the MUSTS, this so much more important than brace placement ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
On Thursday 21 November 2002 17:31, Oleg Tkachenko wrote: . . . final String myString = (String)myListIterator.next(); . . . How do you think, is this final specifier only a style oriented or it have some performance benefit also? I don't know about performance, but I use it all the time anyway as it makes intentions clearer and can save the day by preventing someone from messing up with the variable value. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Victor as committer
On Wednesday 20 November 2002 10:23, Keiron Liddle wrote: Plenty of eagerness shown already and I am sure he will do lots more for the project. Yes, agreed, here's my +1 -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (update)
On Wednesday 20 November 2002 15:15, Jeremias Maerki wrote: . . .I've finally finished the first draft for our style guide... Thanks! I voted -1 on most TBD stuff, braces and spaces are not really important IMHO and I think it's good that the style guide stays as small as possible. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Alt-Design status: XML handling
Great work Peter!
It makes a lot of sense to use higher-level than SAX events, and thanks for
explaining this so clearly.
If you allow me a suggestion regarding the structure of the code: maybe using
some table-driven stuff instead of the many if statements in
FoSimplePageMaster would be more readable?
Something like:
class EventHandler
{
EventHandler(String regionName,boolean discardSpace,boolean required)
...
}
/** table of event handlers that must be applied, in order */
EventHandler [] handlers = {
new EventHandler(FObjectNames.REGION_BODY,true,true),
new EventHandler(FObjectNames.REGION_BEFORE,true,false)
};
...then, in FoSimplePageMaster(...) loop over handlers and let them process
the events.
I don't know if this applies in general but it might be clearer to read and
less risky to modify.
-Bertrand
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Victor as committer (votes from non-commiters)
On Wednesday 20 November 2002 20:11, Rhett Aultman wrote: I thought everyone was allowed to use a vote to express their opinion. If I've gravely mistaken this, then I'll stop voting. I *think* it is so, that everyone is welcome to express their opinion. But as a mostly inactive committer I'm not the one to decide. Indicating this when voting helps, something like: VOTE: should FOP be rewritten in Forth? -1 (from a non-committer) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
On Friday 15 November 2002 09:30, Keiron Liddle wrote: . . .(does anyone even know what I am talking about) Not much on my side as the whole layout thing is still a mystery to me (because I have no experience in computing layouts and never took the time to study this part the code in detail). Anyway I'll try to put my 2 cents in... From your description, I get a feeling that a separate BreaksManager class might be needed, i.e. it might be better making this break stuff modular instead of making the layout managers more complex. I told you...just 2 cents ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [OT] Apache committers meeting in german-speaking area
On Friday 15 November 2002 10:02, Jeremias Maerki wrote: . . .There was the idea to organize a meeting among Apache committers next year in the german-speaking part of the world . . . I might be interested too, depending on where and when. I am subscribed to party@. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Oleg for committer
On Thursday 07 November 2002 09:23, Keiron Liddle wrote: Hi Developers, I suggest we have a vote for Oleg to be a committer. If Oleg accepts then he can get on with making FOP great! +1 - welcome! -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, Cocoon, FOP, mentoring/teaching/coding. blogspace http://www.codeconsult.ch/bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another Bugzilla URL
On Thursday 07 November 2002 10:09, Victor Mote wrote: . . . BTW, I haven't found any doc on the mozilla site to help in building these URLs. If anyone knows of some, I would be grateful. . . . I don't think there's any other way than studying what the bugzilla query form sends when you submit it, maybe trying to remove parameters that have no effect to keep the URLs short. Bugzilla allows queries to be saved (per-user at least), you might be able to create a named query with the appropriate parameters and call it from a URL by giving only the query name (but I didn't try it). This would prevent those URLs from being too long, which might cause them to be broken by old browsers. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
On Wednesday 06 November 2002 09:55, Jeremias Maerki wrote: . . . fo:external-graphic src=url(http://localhost/mydynamicimage) xmlns:fop=http://xml.apache.org/fop; fop:disable-caching=true/ . . . There are some fox: extensions already IIRC (never used them though, but http://xml.apache.org/fop/extensions.html says so), so I think new ones should be created in a consistent way. I'm ok with such extensions (we use similar things in jfor), just would like to make sure that there is only one extension mechanism. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
On Wednesday 06 November 2002 12:31, Keiron Liddle wrote: . . . What sort of jfor extensions are there, what do they do? We have jfor:style to define RTF styles (similar to CSS classes in concept) on the generated RTF elements. A concept that does not exist in XSL-FO as it doesn't make sense when generating printable documents. And also jfor:cmd to set options for the jfor processor, currently used for special tricks/hacks for keep-with stuff. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: forrest is coming?
On Wednesday 06 November 2002 10:03, Keiron Liddle wrote: . . . Lots more to do but I think it is a good start. Great job indeed! I've also been looking at Forrest more closely recently, already very usable and looks even more promising. Need to brighten up or change the logo. Maybe we should have a competition. Good idea, make sure you announce it on fop-users too if you decide to do it. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: feature request queue
On Wednesday 06 November 2002 14:58, Oleg Tkachenko wrote: . . . Patch queue looks very good, and what about introducing one more queue for feature requests? . . . I think these can be identified by the severity=enhancement field of bugzilla issues, isn't that sufficient? Maybe this must be documented on http://xml.apache.org/fop/bugs.html, adding a comment make sure to set severity=enhancement if you're entering a feature request? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
On Wednesday 06 November 2002 16:18, Jeremias Maerki wrote: . . . would you mind using the interface instead of the implementation where possible? big +1. The only drawback is when you need to clone Collections, but the benefits far outweigh this I think. Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FOP developer's style guide? (Was: interface instead of implementation)
On Wednesday 06 November 2002 16:31, Rhett Aultman wrote: . . . Maybe we should seriously consider a FOP developer coding standard and start writing it down and putting it on the site. I'd offer to help with that. . . . How about using a wiki page (web page where everyone can very easily write and edit) to work together on a draft style guide. including links to existing guides so we don't reinvent the wheel? If I get some +1s on this I'll setup the page and publish its address here. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP developer's style guide? (Was: interface instead of implementation)
Wow, that's a quick vote... I have setup the page at http://codeconsult.ch/wiki/index.php/FopDevelopersStyleGuide with a most basic style guide skeleton. I have to run now, but feel free to work on it. Make sure you keep copies of what you write, I cannot guarantee backups on this server yet. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line ending chaos in our codebase
On Monday 04 November 2002 23:53, Peter B. West wrote: . . .I don't know the mechanism for handling line-end differences on entry into a CVS repository on a unix box. . . . AFAIK as long as the binary file flag is not set, CVS takes care of line endings by itself when a file is checked out (http://www.loria.fr/~molli/cvs/doc/cvs_9.html#SEC76), converting them to what's appropriate for the platform. Funny things can happen if people checkout files on a unix box and edit them from a windows box, but most windows editors handle this correctly. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line ending chaos in our codebase
On Monday 04 November 2002 17:02, Jeremias Maerki wrote: . . .Does anyone have a good idea how to... 2. enforce correct line endings? Using the commitinfo administrative file, scripts can be configured in CVS to run when a file is committed, at which point you could detect the problem. I'm not sure if it's worth the effort though. When such a problem is found, you could also study file revisions to find out who created the problem and tell people to fix their environment. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches (how about fop 2)
On Saturday 02 November 2002 10:35, Victor Mote wrote: . . .I would also recommend that, in the above case, we actually put the code into two different projects. . . . +1, I like the idea. How about moving the new code (HEAD) to a separate (xml-fop2) CVS project to clarify things, and maybe name the new version fop 2 instead of 1.0x? Although the current version is 0.20.x, it *is* used in production at a number of sites, so going directly to version 2.x for a mostly new codebase makes sense IMHO. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches
On Friday 01 November 2002 16:51, Keiron Liddle wrote: . . .Maybe the simplest is to move the old layout to the trunk, get that working and put the new layout in a branch. But it needs to be agreed upon. . . . It would be great if the layout engine could be factored out as a component with a clean interface, so as to be able to switch between current engine, not perfect but usable, and new engine, not finished but testable. I have a feeling that working on the layout engine requires fairly specialized skills, whereas other parts of the code are more general in nature (logging, Driver, config, Avalonizing, etc.). IMHO the layout engine is the most risky component of FOP, so a good candidate for a component with a thin interface. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[FYI] jfor integration jumpstarted...
I have added jfor-0.7.1.jar and its license to the lib subdirectory, and created a first version of an RTFHandler that outputs (very rough) RTF documents using the existing jfor RTF library [1]. build.sh examples now generates RTF documents, assuming the following is set in build-local.properties in the directory that contains build.xml: # output format for ant examples build.property.examples.mime.type = rtf I probably won't work on this over the weekend (I'll be building the music room instead ;-), so if anyone wants to have a shot at improving it, go for it! Examples of how to use the jfor RTF library can be found in the org.jfor.jfor.converter package of jfor, see www.jfor.org. -Bertrand [1] as already discussed here, this is done so as to avoid having to maintain two RTF libraries until FOP is better than jfor at generating RTF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fopping 1-12 to Jan-Dec
On Monday 28 October 2002 11:18, Guy D'haenens wrote: WHAT'S THIS? I DIDN'T WRITE THIS MESSAGE! I think the from: address is such that it is being rewritten by some part of your mail system before delivery, it happened here too. If you look at http://marc.theaimsgroup.com/?l=fop-devm=103579950332696w=2 you'll see that the from: address is different of what you got. Don't feed the trolls... -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Where to start for an RTF renderer (was: New Developer Sugges tion)
Hi Scott, . . .anyone who wants to do it will not offend me by going ahead and doing it without me. . . . We haven't had too many volunteers lately in this area, so this shouldn't be a problem. Just make sure to send your patches early, without waiting for your enhancements to be finished. This will help coordinating your work with that of other developers. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
Hi Scott, On Wednesday 09 October 2002 16:20, Sauyet, Scott (OTS-HAR) wrote: Does anyone have a suggestion about something I could look at fixing / enhancing which is not mission-critical, but which might give me a chance to look at a fair bit of the code? The integration of jfor (www.jfor.org) as a structure renderer for RTF documents is still waiting for someone to jump in. If you have good java skills and want to tackle this one we can certainly help you find your way. But note that this part of FOP is not at all related to PDF layout, fonts, etc., it's a fairly different way of rendering documents. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Where to start for an RTF renderer (was: New Developer Suggestion)
Hi Scott, On Wednesday 09 October 2002 17:15, Sauyet, Scott (OTS-HAR) wrote: . . . So is integrating other renderers something that the group would eventually like to do? . . . Yes, we've been talking about structure-based renderers (like RTF and MIF) vs. layout-based ones (PDF being the focal point) for some time. The following messages might shed some light on this: http://marc.theaimsgroup.com/?l=fop-devm=102742684000426w=2 http://marc.theaimsgroup.com/?l=fop-devm=102795797014083w=2 . . . As of today, I know nothing about PDF syntax and little about RTF. I figure I'm going to have to learn both. I understand FO fairly well, and I speak Java fairly fluently. What do you think is first priority? . . . As Jeremias said, you're the one who decides what you'd like to work on. I'm personally biased towards the RTF renderer because that's the part I know best, so here are some starting points if you're interested in studying this in more detail and hopefully jumping in. You won't need much RTF knowledge to start with as the jfor RTF library will generate it for you, and no PDF knowledge at all since this RTF renderer will bypass the layout and PDF generation stages completely. Starting points: 1) org/apache/fop/apps/StructureHandler is the base class that receives structure events from the FO tree while the input XSL-FO is being parsed. The main class of the RTF renderer will inherit from this class to transform the events into an RTF document. 2) Package org/apache/fop/mif is an example of how to build a structure-based renderer similar to what the RTF renderer (org/apache/fop/rtf) will be. 3) jfor (www.jfor.org) is currently a separate project that converts XSL-FO to RTF directly, but could take advantage of FOP's much better handling of XSL-FO properties, hence the plan of replacing jfor by a FOP RTF renderer. 4) My suggestion is to first use the RTF library from jfor in binary form, by including jfor's jar in the FOP distribution, to create the RTF document from the StructureHandler events. The current jfor code does a similar thing where the jfor Converter (jfor/jfor/converter/Converter) uses SAX events to drive the jfor RTF library. Later, when FOP becomes better than jfor at generating RTF, we can move the jfor RTF library code into the FOP codebase. I'd like this to happen in a second stage to avoid having to maintain two RTF libraries while both projects coexist. Hope this helps - feel free to ask any additional questions! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FO to RTF
On Friday 26 July 2002 20:05, J.U. Anderegg wrote: . . . RTF is the format of yesterday: better generate MicroSoft Office XML or Open Office XML. Depends on what you're aiming for. RTF is a terrible format, yes, but at least it allows documents to be opened by a fair number of wordprocessors. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: FO to RTF
Hi Peter, I tentatively suggested using XSLT to generate RTF a little while ago, but I had no idea whether it was feasible. The main question would seem to be: is RTF a text-only format or a binary format? Can anyone answer that one for us? AFAIK, everything in RTF can be expressed with text-only characters, and it would certainly be possible to convert XSL-FO to RTF using XSLT. Our choice to use java for the jfor converter was based on better availability of programming and debugging tools. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FO to RTF (new jfor license)
Hello, On Friday 26 July 2002 10:20, Mulet, Jordi wrote: . . . We have started to experiment with jfor (FO-RTF) and we don't know the best path to follow and if there are plans to integrate jfor in FOP as a RTF renderer. . . . Note that the jfor license was recently changed to allow it to an ASF-compatible one, see www.jfor.org for more info. This allows jfor to be distributed with ASF projects. This means that the RTF library part of jfor can be used in binary form as a back-end for FOP (StructureHandler) to generate RTF, without having to maintain two RTF libraries (which would be the case if the jfor RTF code was moved to the FOP codebase). I think this will ease the transition from jfor to FOP for RTF generation, until FOP 1.x is released. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence short or long
On Wednesday 26 June 2002 22:42, Jeremias Maerki wrote: . . . We have the short form but it seems like we have to switch (back?) to the long form. . . . I agree, Stefano's message [1] in the thread you mention makes it clear, . . .the ASF board, to avoid confusion, wants everybody to stick with the full license until the new license is out. . . -Bertrand [1] http://marc.theaimsgroup.com/?l=avalon-devm=102511331724304w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: For once Good news and a thank you
Hi Jochen, Would it be thinkable for you to share examples of your XSL-FO documents, as good examples of what works well in FOP? The question of which constructs to use to get good performance come often, so I think it would be a worthwile addition to the project. If needed, I can send you a piece of java code that obfuscates the text of XML files by replacing all words with others from a list, so that the confidentiality of your data would be preserved. Please let us know what you think! -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
StringWarper - obfuscates XML files (was: For once Good news and a thank you)
On Thursday 13 June 2002 14:51, Ralph LaChance wrote: ooo, I could use that ! You'll find it at http://codeconsult.ch/download/string-warper/string-warper-2002-06-13.zip There's a build.xml for ant, target test runs a self-test. Actually I should have said a piece of java hacking. You'll see that it's dead simple, doesn't even use a proper parser. Which means it might *destroy* some XML files depending on the constructs used. Please let me know if you make it better (wellthatsnothard)! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fop and JDK1.2 (using ant copy tasks to select implementations)
On Tuesday 11 June 2002 08:22, Jeremias Maerki wrote: . . . 2. Try to build up the support for version dependant code for the next release. . . . Note that this is fairly easy to do using filtering in ant copy tasks and package names containing identifiers. For example: package A contains interfaces, abstract classes and factories as needed package A.jdk12 contains 1.2 implementations package A.jdk13 contains 1.3 implementations The ant copy task (copying source files to an intermediate directory before compiling) can then filter source files based on package names, in order to select and compile the right classes. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fop and JDK1.2 (using ant copy tasks to select implementations)
On Tuesday 11 June 2002 14:43, Rhett Aultman wrote: . . . Rather than relying on Ant, I'd say a runtime detection of VM demographics (version, vendor, etc) would be in order, which could then allow a classloader to select the correct classes to instantiate. . . . I like your idea a lot - hopefully it won't be too complicated to implement, but there might be cases where you actually have classes that do not compile on some VM version. If that's the case, multiple JDKs might be needed to compile FOP completely, and we must make sure that single-VM compilation remains possible. So we might need to combine both approaches in the end. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fop and JDK1.2
On Monday 10 June 2002 17:06, Christian Geisert wrote: . . . 1) Declare that Fop needs JDK1.3 Could cause confusion with Cocoon users - Cocoon requires JDK1.2. 2) Remove truetype font support from AWT viewer +0 3) Compile Fop with JDK1.3 (which will be done anyway) and state in the release notes that compiling with JDK1.2 and using truetype fonts in the AWT viewer does not work. +1 If I understand correctly, a version compiled with 1.3 would run ok on 1.2 except for these truetype fonts? Then fine. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure Handlers - RTF Renderer
Hi Peter, Sorry for taking so long, week's been hectic around here. . . . I think you will still have attribute resolution problems. Remember that some attributes are only going to be resolved during the layout. I understand that some attributes cannot be resolved at the parsing stage, and as Keiron mentioned, there will need to be a way to transfer them with all the relevant information. The implications for RTF are not that clear for me though (mostly because jfor is currently sooo weak about attributes, AND I never worked on a print-type renderer) - I think I need to be able to play with actual code to better understand the issues. AFAIK Keiron is working on a first shot StructureHandler which should help me jump in. . . . It seems to me that the general solution would involve the definition of a structure api, taking account of the layout dependencies. . . . I agree, but again the whole picture is not clear enough in my mind yet to be able to specifiy these dependencies. I suggest that we wait for Keiron's skeleton code, on which we build a rough RTF converter which will help us (me at least ;-) understand the issues on concrete examples. We should then be able to define a set of XSL-FO documents that show different use-cases for attribute resolution. . . . You may already have documented the structure transformations needed for FO-RTF. If so, it would be a very good idea to include them in the NEW DESIGN documentation. . . . Unfortunately not - what jfor currently does is 1-to-1 mapping of basic attributes like font sizes, bold, italic, etc. so there's not much to be said. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure Handlers - RTF Renderer
Hi Keiron, . . . We should be able to set common objects like the logging and config on the structure handler itself. But the context idea could be useful for other objects that it may need to access. . . . ok, It wasn't clear for me either what would go into the context object, but it is certainly better that passing the FO object directly. . . . I'm not sure about the best way to do things like the table columns. It would be simpler if it could do a start table after it has all the table columns rather than needing to get each table column individually through method calls. . . . Would this scenario be easy to implement? startTable startRow (maybe after all FOs for the row have been parsed) startCell (maybe after all FOs for the cell have been parsed) start/end stuff for cell contents endCell more start/endCell endRow more start/endRow endTable or do you mean just one startTable with row/columns contained in the FO? I'd prefer many event calls, as the StructureHandler wouldn't need to know as much about FOs in this case. Conceptually (and this might be useful for concrete stuff like testing too), I think the StructureHandler needs to be able to rebuild the XSL-FO structure with as little code as possible. Maybe (if easier to implement or to avoid slowing down PDF rendering) this event generation can be done by an intermediate component that decodes the FOs and generates detailed events? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties
On Wednesday 01 May 2002 18:19, Peter B. West wrote: Does the near-silence on this one signify consent? I don't know enough about this to give meaningful advice, so in my case yes, silence means consent. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Lest we forget (please use REPLY!)
On Friday 26 April 2002 08:09, Bertrand Delacretaz wrote: This probably helps: http://www.anzacday.org.au/ sorry for the noise - I didn't see that the question had long been answered. PLEASE everybody use reply-to when replying to mailing lists messages. With the right mail client, it allows discussions threads to stay together. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Lest we forget
This probably helps: http://www.anzacday.org.au/ -Bertrand On Friday 26 April 2002 00:38, Martin Stricker wrote: Peter B. West wrote: Age shall not weary them, nor the years contemn. At the going down of the sun, and in the morning, We shall remember them. Lest we forget. Anzac Day 25th April 2002 Could you please explain this e-mail? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Vote] New committers: Peter West, Joerg Pietschmann?
On Thursday 11 April 2002 12:16, you wrote: I propose that we offer Peter West and Joerg Pietschmann to become committers. +1 for both! (Although officially a committer I have done nothing concrete yet, so I hope my vote counts ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Area tree - renderer (pr.fo for structure renderers)
On Saturday 16 March 2002 14:52, Peter B. West wrote: . . . The last stage of the FOP process translates one page description (the area tree) into another (the input to the target renderer.) ok So why would anyone want to interpose another translation step into this tightly coupled arrangement? Who knows? . . . For page-based renderers where FOP has to compute the layout (like for PDF output), I don't see a need for another translation step either. IMHO asking who knows is usually a sign that a feature is not needed *at this stage of development*... OTOH, for structure-based renderers like RTF and MIF, I think the only parts of FOP that are reusable are the first two stages: parsing and property resolution (apart from infrastructure like logging, config, etc. which might come from Avalon in the future?). Last week we had a talk about using XML to communicate between FOP pipeline components, but for me this currently would only make sense between the property resolver and structure renderers components. The deal is being able to reuse FOP's property resolution (p.res) in different contexts. I think the following usage scenarios could greatly benefit from reusing FOP's front-end (parser + p.res). In the following I call pr.fo an XSL-FO document where all properties (fonts, sizes, etc.) are explicitely written, for example when inherited from parents: a) XSL-FO to RTF conversion: FOP parser - FOP p.res - pr.fo - jfor converter b) XSL-FO to MIF conversion FOP parser - FOP p.res - pr.fo - yet-to-write XML-to-MIF converter c) automated testing of first FOP stages FOP parser - FOP p.res - pr.fo - XML testing tool Keeping in mind that RTF and MIF are formats where the page layout is left to the client software to compute (word processor or FrameMaker), keeping these converters independent of FOP instead of integrating them has several advantages: b) Helps keep FOP focused on its main task: generating great PDF from XSL-FO documents c) If FOP is ever rewritten in another language for performance, these converters, being much less compute-intensive, can stay in java and keep the same interface to the FOP components that they use d) assuming I want to write a MIF converter, basing it on XSL-FO input instead of on a FOP API allows me to easily include MIF-specific constructs for applications where XSL-FO conformance is not needed but precise control of the generated MIF is (often a requirement for MIF when producing half-finished documents that are typographically reviewed before printing). In conclusion, I think an interface based on XML documents (possibly this pr.fo discussed above) is the best choice to use between the FOP property resolution stage and the structure renderers like RTF and MIF renderers. OTOH I agree that using XML between the layout and rendering stages doesn't make sense at this stage of FOP development. Due to many other commitments, I don't have time right now (sorry, I know you're getting used to hear this) to implement this pr.fo interface, but if we agree on its usefulness I'll put this high on my list and hopefully give it a shot in the next few weeks... -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Area tree - renderer (pr.fo for structure renderers)
On Monday 18 March 2002 13:37, Peter B. West wrote: . . . Bertrand Delacretaz wrote: In conclusion, I think an interface based on XML documents (possibly this pr.fo discussed above) is the best choice to use between the FOP property resolution stage and the structure renderers like RTF and MIF renderers. The big problem is in defining the p.res step. How far do you need to go with this? If you require all of the relative lengths resolved, e.g., you'll have to wait until the layout is done. The properties are only finalised as the area tree is being constructed. It's one of the things that makes this all so frustrating. ok I see. I'll try to play with this for RTF rendering based on jfor, to get a feel for how hard/useful this is. In case of jfor, what is needed is mostly property inheritance, for which AFAIK rules are well defined in FOP. I guess relative lengths will probably stay relative in the RTF code, but I'll have to play with it to be positive about this. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Area tree - renderer (pr.fo for structure renderers)
Hi Peter, On Monday 18 March 2002 22:06, Peter B. West wrote: . . . There's another gotcha - markers. The properties in markers are resolved relative to the retrieve-marker invocation point. . . . Thanks - I'll keep this in mind when I get to play with this stuff.. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:00, Nicola Ken Barozzi wrote: . . . 1. FopParser parses and validates the input XSL-FO document Not needed if using Cocoon as a pipeline. . . . Right, but it's so easy that we might as well keep it for easier testing. . . . What I would like to see, is that FOP stops discussing about the logging, resolving, pipelineing and stuff and starts to focus on the core functionality. . . . Yes, but IMHO resolving (in the sense of resolving FO object properties like I think is meant by FOP) is part of the core functionality. I'm talking about computing presentation attributes for child elements based on their parent's attributes. . . . This can big opportunity also for other projects to collaborate in the rendering. JFor, for example (I don't remember who maintains it ;-P) . . That's me by the way ;-) (but I haven't done much lately) -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:19, Keiron Liddle wrote: . . . Firstly the Area Tree is unavoidable. We must have a place to do the layout and to store the page information. . . . Unavoidable for Layout rendering, isn't it? I thought structure-based rendering wouldn't need the area tree. . . . For the FOTree to structure document it is a different issue, that I hope we will solve one day. Maybe sax events could be used here. . . . How hard would it be to render the FOTree in XSL-FO (based on SAX events) with all possible attributes resolved? Speaking specifically about the jfor RTF converter, this would allow it to be used as a FOP renderer without needing as much code changes as an API-based integration. Might be a little slower but much more flexible. This would allow the parser and property resolver (is that the right term?) components of FOP to be reused by jfor and future structure-based renderers. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote: . . . Hmmm... AFAIK FO is about layout, not semantical structure. Bold is just Bold, and not emphasis or strong. Maybe I don't get the point. Could you elaborate more please? . . . The term structure renderer (as you could find by searching the list archive probably ;-) is used here for yet-to-be renderers that don't do any layout by themselves. If you're generating RTF or MIF formats, for example, you usually don't need to know on which page a given FO element will go, you leave this to the word processor or desktop publishing program that will use the generated document. So these renderers will be plugged in right after the parsing and property resolution stages, before the layout stage. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote: . . . I think that a SAXrenderer could be the solution. SAX is based on calling a method when a tag begin-content-end is reached. It can be used to communicate the Area Tree to the renderer in a clean way, whith a standard interface. . . . Won't work I think, print-based layout (as opposed to structure-based) requires two-way communication between the layout engine and the renderer (to compute the width text runs, for example). -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Hi Peter, Aside from my low opinion of SAX for process coupling, there should be no need for communication back from the renderer. . . . cool - I thought the Area Tree code needed to know about font metrics and the like, but if this communication is one-way all the better. Regarding SAX events, I really meant that for structure renderers. What I envision (in the context of RTF rendering through jfor) is the possibility of using the FOP front-end only to resolve XSL-FO properties, like an XSL-FO preprocessor if you want. That's for this preprocessor-to-StructureRenderer interface that I think using XML makes sense, for loose coupling of the StructureRenderers which would then not necessarily be part of the FOP code base. If we agree that XML is good for this, I think generating this XML through SAX events allows the preprocessor component to be efficiently integrated in Cocoon (for example) later on, without having to serialize and reparse the XML. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote: . . . - FOP uses iText as a PDF generation library - . . . Maybe the following scenario could help making FOP more pipeline-oriented, making it easier to plug in various renderers, layout engines, debugging tools, etc. I'm just making up component names, hopefully understandable 1. FopParser parses and validates the input XSL-FO document 2. FopPropertyResolver does its job, attributes inheritance, etc. Then two options: 3a. FopLayoutEngine (existing code, API-coupled as now) computes layout and produces PDF 3b. *or* FopFoDumper dumps the result in XML (or SAX events) using the XSL-FO vocabulary but with all attributes explicity specified (as far as possible, I know there are some issues here). After 3b, various XSLT transforms and/or XML-to-something converters can be plugged in using the well-defined and loosely-coupled SAX/XML interface. I think using XML/SAX to interface between future pipeline components (ParsingAndPropertyResolving - Layout - Serialization) opens up much more options than using java APIs for this, and could help keep FOP small and focused. If using Cocoon, being able to just resolve properties and pass the result on to various transforms opens up new horizons for XSL-FO processing. At the other end of the pipeline, what about an XML-to-MIF converter, for example, much more generally useful than a tightly-coupled MIF renderer for FOP. Implementing 3b should be fairly easy (isn't that a serialization of the FOTree?), and we can go from here to reuse important parts of FOP as individual components. How does this sound? -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: remove html-docs dir?
On Monday 18 February 2002 10:54, Keiron Liddle wrote: Can I remove everything under docs/html-docs. +1 because it will force the builds to have up to date information -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Integrating Tree into FO tree handling
On Sunday 17 February 2002 06:07, Peter B. West wrote: . . . FOTree maintains the property stacks with the initial value, current value and history of the properties being defined on elements of the FO Tree. It also implements Runnable, and its run() method is the source of the FoTreeBuilder thread. On construction, it is given a SyncedCircularBuffer by means of which it receives event notification from the parser. . . . Would this SyncedCircularBuffer help in propagating the events downstream from FoTreeBuilder to StructureRenderers? Or is is already implemented so in some experimental branch of the code? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tool to create XSL:FO without stylesheet from Java?
On Friday 15 February 2002 15:47, Roland wrote: does anyone have a good tool to create an XSL:FO file without the use of a stylesheet? You might want to look at jdom (www.jdom.org), a very nice DOM manipulation library for java. Saxon (http://users.iclway.co.uk/mhkay/saxon) is also a good choice for this. And if you do a search on google with jdom saxon xml you'll find a few more such libraries. The reason I want to do this is because I think XSLT is very complicated. IMHO XSLT is worth learning - the combination of XSLT with java is killer for working with XML. -- -- Bertrand Delacrétaz, www.codeconsult.ch -- web technologies consultant - OO, Java, XML, C++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML Parsing [2] (RTF document header)
On Monday 11 February 2002 10:19, Keiron Liddle wrote: . . . At the end of a page sequence we know that all pages in the page sequence can be rendered without being effected by any further XML. Note that this won't be the case with RTF: AFAIK an RTF document has to contain a document header with font tables, tables of list formats etc. This header has to come at the beginning of the document but most of the information (notably information about list formats) it contains won't be available until much later in the document. This is a problem if we want to generate RTF on the fly, and we don't have a solution for this in jfor yet, we just keep the RTF document in memory until it is complete. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: StructureEvents concept
On Thursday 07 February 2002 12:15, Keiron Liddle wrote: . . . Do we need to have this completely separate method of reading the fo tree (layout managers is the other) when both do some similar things. I'm not sure, I just can't picture how it should work at the moment. Right - let me try to reformulate what we need to be able to create an RTF document. If this is already covered by the current layout manager interface, then it's fine. We need: - start and end of document yes - start and end of page sequence yes (mapped to an RTF document section) - resolved properties yes - static areas yes, for RTF they should at best come right after the start of the page sequence - add info after end of block level object: block, table, list etc. yes, for RTF we need both start and end events for most such constructs: table cells, list items, etc. So I think what you suggest maps well with the requirements of an RTF render (or other structure-based renderers). Where should I look in the current code to start playing with this? layoutmgr package? - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: StructureEvents concept
On Friday 08 February 2002 01:58, Peter B. West wrote: Bernard, (That's Bertrand by the way ;-) What sort of structure does rtf exhibit? Is it a page-based structure, or is it divided, like xslfo, into page definitions and flows? This is a critical difference as far as the design goes. From what you say below, it seems to rely on a flow-based model. In the sense of not being mapped to printed pages directly (unless hard page-breaks are used), RTF is flow-based, not page-based. An RTF document is broken out in sections which are very similar to page-sequences in concept. The pagination is done by the RTF reader (usually a word processor) when it renders the document to screen or print. Constructs like tables, lists etc. are flow-based but need to be closed, kind of like the nested elements of an XML document. I think RTF maps well to XSL-FO documents in terms of structure. What has been hard in our past efforts to write an RTF renderer was that FOP didn't provide end events (or we didn't find out how it did) for tables, lists and other elements, for which the RTF render needs to generate element-closing codes. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Seeking Comments on Status of Project
On Thursday 07 February 2002 03:57, Arved Sandstrom wrote: . . . If you do some code and want to see it added to the main or maintenance branches, then the onus is on one or more committers to explain why it's a bad idea, but there must be a good reason. . . . To make sure there is no confusion about this, could someone clarify (once more I guess) what exactly the main and maintenance branches are, and how to get the source code for both of them? - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Seeking Comments on Status of Project
On Tuesday 05 February 2002 23:25, Peter B. West wrote: . . . I think that most people need some encouragement to take the plunge in murky waters. I agree, make sense with the various offers for help that came up in the last few weeks. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: keep-with-next?
(by the way your message was crossposted to fop-user, please avoid this as it makes it very hard to follow discussions) On Wednesday 30 January 2002 20:21, David Wood wrote: I am a Java coder and know my way around the standard. I volunteer to try to fix this, if someone who is more familiar with FOP's internals can tell me where to look... I cannot help you much, but here's at least a reply to your offer ;-) AFAIK getting keep-with... stuff to work requires serious redesign, which is currently going on (Keiron and Karen?), but apparently fairly slowly. Keiron would probably be the one to answer you, but in his last message (Jan.14th I think) he indicated that he'd be away for some time. I have no idea when he will be back, maybe someone knows more? -- -- Bertrand Delacrétaz, www.codeconsult.ch -- web technologies consultant - OO, Java, XML, C++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: refocusing fop-dev and fop-user?
On Friday 25 January 2002 10:26, Jens von Pilgrim wrote: . . . On http://xml.apache.org/mail.html is only the fop-dev listed - is there also a user list? This is probably the cause - AFAIK fop-user is alive and kicking, just not listed in the proper places. Can anyone clarify the situation and/or make sure fop-user is listed in the right places? - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
