Re: Meeting Bertrand
Jeremias Maerki wrote: So far, I've met Bertrand and Jörg. No surprise as they live within about 120km of my place. :-) It's really interesting what difference it makes to have someone directly in front of you. Too bad, Skype still doesn't have video conferencing support. Anyone already using a video conference application? Hardware and bandwidth available here. That would be a good work-around until we have cheap hypersonic travel. Still hoping for beaming to become available What about IRC? And it looks like there will be an ApacheCon Europe .. in 2005 in Stuttgart. Christian
Re: Meeting Bertrand
On 15.07.2004 18:02:34 Christian Geisert wrote: What about IRC? It has the same problems as e-mail when it comes to interpreting messages. I'm using ICQ and MSN a lot, but that's not what I'm after here. And it looks like there will be an ApacheCon Europe .. in 2005 in Stuttgart. That's very good news. Where did you hear that? Jeremias Maerki
Re: Combined the AreaTree and FOTreeHandler (was: Re: cvs commit: etc.)
Glen, Thanks for your lengthy reply. It makes more sense now. Although I keep the feeling that this change brings the FO tree building and area tree building modules closer together than I would prefer. On Tue, Jul 13, 2004 at 04:20:16PM -0700, Glen Mazza wrote: AreaTreeHandler throws SAXExceptions. This is a parser based exception type. Indeed--needs them just as much as MIFHandler and RTFHandler do. This parser based exception penetrates the app rather deeply. It would be better if here all traces of the particular FO file input method would have vanished. Also, in merging the two I was able to remove a lot of code that dealt with communication between the two--moving out this administrative code dropped the combined size by about a third (IIRC 500265LOC before, 465LOC after.) It does help in comprehension. Communication may be a means of separating parts of an app from each other. And often it is worth the extra lines of code. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: cvs commit: xml-fop/examples/embedding/java/embedding ExampleFO2PDF.java
Because, IMO, it allows the user to use the same pattern for virtually everything: 1. Create a TransformerFactory 2. Create a Transformer and optionally use a stylesheet 3. Specify the Source (DOM, stream, file, SAX) 4. Specify the Result (DOM, stream, file, SAX) 5. Start the transformation. I use the JAXP part for XML parsing almost never because I can do most with this pattern. During my work I realized that most people don't even know about this pattern. They save the FO as a file or as a DOM and then send it to FOP. Very inefficient. Using the one API approach we can teach our users a few handy things with which they can do whatever they need: - Serializing a DOM to a file - Transforming an XML file to HTML - Creating a PDF from a Java object - you name it. Of course, in some situation you will need to learn a few additional things like using the TransformerHandler for pipelining multiple XSL transformations. But most of the things can be done using the Transformer. On 15.07.2004 20:52:23 Simon Pepping wrote: On Wed, Jul 14, 2004 at 10:42:29PM -, [EMAIL PROTECTED] wrote: gmazza 2004/07/14 15:42:29 Modified:examples/embedding/java/embedding ExampleFO2PDF.java Log: Updated FO-PDF example to use JAXP. +// Setup JAXP using identity transformer +TransformerFactory factory = TransformerFactory.newInstance(); +Transformer transformer = factory.newTransformer(); // identity transformer + +// Setup input for XSLT transformation +Source src = new StreamSource(fo); +// Resulting SAX events (the generated FO) must be piped through to FOP +Result res = new SAXResult(driver.getContentHandler()); + +// Start XSLT transformation and FOP processing +transformer.transform(src, res); This is as much JAXP: Driver.run: render(FOFileHandler.createParser(), source); FOFileHandler.createParser: SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setNamespaceAware(true); return factory.newSAXParser().getXMLReader(); Why is having a transformer object in between better? Jeremias Maerki
Re: FOray 0.1 release
Making these parts into separate components is in line with what I have in mind when can talk about a shared repository between Batik and FOP. I hope I can take a good look into what you did later. From a quick look, however, I wasn't very pleased that you propose to use a lot of statics in the FontServer. I would prefer to have the possibility to define multiple configurations in a heavy server environment without having to go through the pains to separate multiple environments using classloader magic. The system fonts are ok like this, of course, but not the user-defined. Just my opinion. Concerning the PDF library, I suggest you start from the PDF lib in CVS HEAD instead of using the maintenance branch, even if it means that the API may be a bit different. I've invested a considerable amount of time to make the whole thing better. Things such as encryption are much more cleanly solved. When the XML Graphics project is set up I hope we can soon talk about the details of my ideas. I'd love to have you with us to work on the shared components. On 13.07.2004 22:40:43 Victor Mote wrote: FOP Devs: I am pleased to announce the release of FOray 0.1 alpha 1. This release is only useful to FOP developers. Some useful information about the release can be found in these places: http://foray.sourceforge.net/module/font/index.html http://foray.sourceforge.net/module/font/release.html Since it is developers-only, I have not prepared any downloadable packages. You will need to use CVS to get the code. This is available here: http://sourceforge.net/cvs/?group_id=109663 Probably the most efficient way to proceed is for Chris to do the initial evaluation work. I can support him off-line, and probably will need to add some doc as a result of his work. Then any others who wish to look at it will have an easier time. To cleanly get Fonts isolated, I had to isolate PDF, and to isolate PDF, I had to isolate Graphics. So there are actually three FOray modules at the moment (plus Common). Please remember that this release is a no-feature release, but is intended to address architectural issues only. The main purposes of the release are 1) to try to find out whether anything has broken, and 2) to get comments on the general design. Implied within FOray itself is a desire on my part to start getting code released again. I realize that there are several views of how best to get that done, and that FOray might be viewed as a distraction by some. If that is the prevailing view, and FOP has no desire to release this code under any circumstances, then you can save Chris a lot of trouble by reaffirming the status quo now. This will put the burden on FOray to start releasing essentially a competing product, which I am not eager to do. (This may happen eventually anyway if I have time to pursue the modular design that I think is important, but it is just as likely that a FOP 1.0 release will make such an effort unnecessary). As a friend of FOP I have opinions on what you should do, but my role here is different, and I will try to remain neutral, providing information when needed. I'm really just a guy trying to get some work done -- if it helps you, good; if not, that is OK too. Please let me know if there is anything I can do to help. Victor Mote Jeremias Maerki
Re: cvs commit: xml-fop/examples/embedding/java/embedding ExampleFO2PDF.java
Thanks, Simon--I didn't think of this way of solving the problem--I just modified Jeremias' previous DOM example. However, I placed the method below temporarily in the example and committed it before returning to the Transformer version. This way, we have a working example should we ever need to document this style (perhaps on a web page, so users are at least aware of it) in the future. Glen --- Simon Pepping [EMAIL PROTECTED] wrote: This is as much JAXP: Driver.run: render(FOFileHandler.createParser(), source); FOFileHandler.createParser: SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setNamespaceAware(true); return factory.newSAXParser().getXMLReader(); Why is having a transformer object in between better? Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: cvs commit: xml-fop/examples/embedding/java/embedding ExampleFO2PDF.java
Sounds good. --- Jeremias Maerki [EMAIL PROTECTED] wrote: Because, IMO, it allows the user to use the same pattern for virtually everything: 1. Create a TransformerFactory 2. Create a Transformer and optionally use a stylesheet 3. Specify the Source (DOM, stream, file, SAX) 4. Specify the Result (DOM, stream, file, SAX) 5. Start the transformation. snip/ Using the one API approach we can teach our users a few handy things with which they can do whatever they need: - Serializing a DOM to a file - Transforming an XML file to HTML - Creating a PDF from a Java object - you name it. snip/
