Re: API discussion (revived)
On Sun, 21 Aug 2005 02:29 pm, Jeremias Maerki wrote: The API discussion thread around 2005-08-03 trailed off. I'd like to revive it again because I feel that is something that needs to be done. Anybody against moving the CLI to a org.apache.fop.cli package? For command line applications I like it short and sweet, e.g. org.apache.fop.Fop would be fine with me. The current CommandLineOptions could go into org.apache.fop.cli. The only issue I see when doing this is that FOP's API then still resides in the org.apache.fop.apps package which is sort of unintuitive then. apps would suggest a command-line application IMO but we're then only talking about an API. In the end it comes back to the discussion about the API. Is the API ok like it is? Is it in the right package? I agree, it is an unintuitive package name. I am not philosophically against having the command line application and the exposed API in the same package. But certainly not in the same class. What about moving the API part from the current org.apache.fop.apps.Fop into org.apache.fop.FOProcessor? We've already broken API compatibility so changing packages (I'm thinking think about org.apach.fop, removing apps) shouldn't be a big deal before the first release. As long as we don't do anything that prevents from creating a wrapper org.apache.fop.apps.Driver class for those who like backwards compatibility -:). Anybody against my adding support for selecting the renderer by the use of the MIME type (in addition to the current integer constants) and adding a renderer discovery (similar to FOP extensions and what I recently added for the XMLHandlerRegistry)? On the other side, maybe we should really take the time to write up a short specification for the API and to have that voted on. After all, this is the main entry point into FOP. If anybody could take the lead on this, I'd be very grateful as I have my hands full enough already. I can still do it myself, if really nobody can be found to do it. But I'd really not do all that stuff in a lonely rider fashion. Only looking a structural aspect and not the details of the API we have options like: a) Don't do anything leave it as it is as it avoids quite a bit of refactoring work and redoing all the examples, etc.. b) Move all command line stuff into org.apache.fop.cli including the application and move all API stuff into org.apache.fop.api. c) Move the command line application to org.apache.fop, move anything required just to support the command line app to org.apache.fop.cli. Also move all API classes, i.e. all classes exposed to users wanting to embed FOP up one level to org.apache.fop. Make sure that the command line application is in a different class than the main API class, i.e. don't overload Fop.java. d) Do some mix of b) and c), e.g. move command line app to org.apache.fop and move the API to org.apache.fop.api. In all cases but a) the org.apache.fop.apps package will disappear. Jeremias Maerki Manuel
Re: API discussion (revived)
On 21.08.2005 09:08:48 Manuel Mall wrote: On Sun, 21 Aug 2005 02:29 pm, Jeremias Maerki wrote: The API discussion thread around 2005-08-03 trailed off. I'd like to revive it again because I feel that is something that needs to be done. Anybody against moving the CLI to a org.apache.fop.cli package? For command line applications I like it short and sweet, e.g. org.apache.fop.Fop would be fine with me. The current CommandLineOptions could go into org.apache.fop.cli. Do you mean splitting up the code for the CLI in two different packages? Hmm. I'd prefer to have org.apache.fop.cli.Main as main class, just like I did in Barcode4J. The only issue I see when doing this is that FOP's API then still resides in the org.apache.fop.apps package which is sort of unintuitive then. apps would suggest a command-line application IMO but we're then only talking about an API. In the end it comes back to the discussion about the API. Is the API ok like it is? Is it in the right package? I agree, it is an unintuitive package name. I am not philosophically against having the command line application and the exposed API in the same package. But certainly not in the same class. What about moving the API part from the current org.apache.fop.apps.Fop into org.apache.fop.FOProcessor? Would be ok for me. We've already broken API compatibility so changing packages (I'm thinking think about org.apach.fop, removing apps) shouldn't be a big deal before the first release. As long as we don't do anything that prevents from creating a wrapper org.apache.fop.apps.Driver class for those who like backwards compatibility -:). It might even be easier to provide the wrapper since the new API is not in the same package anymore. Anybody against my adding support for selecting the renderer by the use of the MIME type (in addition to the current integer constants) and adding a renderer discovery (similar to FOP extensions and what I recently added for the XMLHandlerRegistry)? On the other side, maybe we should really take the time to write up a short specification for the API and to have that voted on. After all, this is the main entry point into FOP. If anybody could take the lead on this, I'd be very grateful as I have my hands full enough already. I can still do it myself, if really nobody can be found to do it. But I'd really not do all that stuff in a lonely rider fashion. Only looking a structural aspect and not the details of the API we have options like: a) Don't do anything leave it as it is as it avoids quite a bit of refactoring work and redoing all the examples, etc.. Not an option IMO. This is too important. And the work necessary is negligible. b) Move all command line stuff into org.apache.fop.cli including the application and move all API stuff into org.apache.fop.api. That's a possibility. c) Move the command line application to org.apache.fop, move anything required just to support the command line app to org.apache.fop.cli. Also move all API classes, i.e. all classes exposed to users wanting to embed FOP up one level to org.apache.fop. Make sure that the command line application is in a different class than the main API class, i.e. don't overload Fop.java. As I hinted above I wouldn't like the splitting up of code belonging together. d) Do some mix of b) and c), e.g. move command line app to org.apache.fop and move the API to org.apache.fop.api. In all cases but a) the org.apache.fop.apps package will disappear. e) (my preference) Move the API to org.apache fop and the CLI to org.apache.fop.cli (including the Main class). Jeremias Maerki
DO NOT REPLY [Bug 36224] - [PATCH] Support for CCITTFaxDecode filter (TIFF images) in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36224. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36224 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-21 18:49 --- Applied. Thanks a lot for the patch. It looked very good. It should be possible to write a JUnit test case to check for the caching problem you think could be around. I haven't tested for that one, yet. As a side note: Direct CCITT support could also be added to the PostScript renderer as it supports this filter, too. Probably quite easy now. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Assimilating PDF and PS output
On Sat, Aug 20, 2005 at 08:56:09PM +0200, Jeremias Maerki wrote: I'm currently working on the PS renderer and as part of that I tried to factor out more common code between the PDF and PS renderers. As a result of that I already have some of the more important features (borders and viewports) working locally. But this meant switching the PS renderer's own coordinate system from millipoints to points because PDF works in points. At the moment I'm looking at what this means for PSGraphics2D which still operates on millipoints. I think I should change that, too. I don't think this should have any negative effects on anybody, since the output will still look the same. Do I maybe miss The layout system works with millipoints. Is this discrepancy between areas and renderers not an endless source of errors and confusion? Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Block content in inline content
What the hell is unfortunate about having a better idea? If that helps make the code simpler and more easily understandable that's cool. And it sounds like it does. I simply had to fix the problem somehow because I want to get the first release out as soon as possible. And I was very happy that you already provided me with something to start with (that doesn't happen for the first time. Hey Luca!). It doesn't have to be (and can't be) perfect in this short time. So I'm perfectly happy if you look at this again when you have time. On 21.08.2005 20:58:36 Simon Pepping wrote: Thanks for solving bug 36248, total number of pages with empty block :ClassCastException in KnuthInlineBox. Unfortunately perhaps, I think I have a better idea for handling block content in inline content, specifically in InlineLM. For each block Knuth element that InlineLM receives from a BlockLevel child LM, it should insert a complete one-line paragraph into its return list. This paragraph consists of a KnuthBox, a KnuthGlue with infinite stretchability, and a negative infinite penalty. In this way InlineLM would hide the block content from the other LMs, which is appropriate. This also solves the problem that getNextKnuthElements does not really return the same type of object for BlockLevel and InlineLevel LMs. It allows us almost to go back to the old code in LineLM. The only difference is that the return list may contain multiple paragraphs, whose end is signalled by a negative infinite penalty. Even this is not really necessary, but I think it is more efficient than returning to LineLM at the end of each paragraph. I have not investigated how InlineLM would do the conversion from block elements to a paragraph and back, but I do not see a huge problem there. If no one else does it before me, I will try to work out this idea, but not until several weeks from now. Sorry for not thinking of this rather obvious solution earlier. It would have saved some work. Jeremias Maerki
Re: API discussion (revived)
Jeremias Maerki wrote: We've already broken API compatibility so changing packages (I'm thinking think about org.apach.fop, removing apps) shouldn't be a big deal before the first release. I guess people would be more upset about FOPException moving to a new package than any other API change. It might be worth a try though. On the other side, maybe we should really take the time to write up a short specification for the API and to have that voted on. What's wrong with the spec in the Wiki? J.Pietschmann
Re: Assimilating PDF and PS output
Well, PDF and PostScript initially start with points, not with millipoints. So you have to choose between one of the two coordinate systems. I chose points because it generates smaller output files as the millipoint coordinate system created too many zeros. I don't think this will cause confusion. It's only a factor of 1000 which is easily handled in out brains. Had I chosen millipoints for both, I think we might have had a problem in PDF with font sizes. I dimly remember a related problem in PDFGraphics2D. But at any rate it's good to have the same output coordinate system for both PDF and PS because now you can easily compare the values in a text editor, provided you know how to disable the encoding filters for PDF. :-) Another point is that the Graphics2D implementations don't depend on the coordinate system of the layout engine at all. There, SVG dictates mostly what's coming in. What makes the code a little more complicated (/1000f everywhere) in the renderers makes it easier in the Graphics2D implementations. On 21.08.2005 20:41:41 Simon Pepping wrote: On Sat, Aug 20, 2005 at 08:56:09PM +0200, Jeremias Maerki wrote: I'm currently working on the PS renderer and as part of that I tried to factor out more common code between the PDF and PS renderers. As a result of that I already have some of the more important features (borders and viewports) working locally. But this meant switching the PS renderer's own coordinate system from millipoints to points because PDF works in points. At the moment I'm looking at what this means for PSGraphics2D which still operates on millipoints. I think I should change that, too. I don't think this should have any negative effects on anybody, since the output will still look the same. Do I maybe miss The layout system works with millipoints. Is this discrepancy between areas and renderers not an endless source of errors and confusion? Jeremias Maerki
Re: StAX, JAXP 1.4
Peter B. West wrote: Fopsters, Some of you may be aware of the activity going on around StAX. Java 1.6 (Mustang) was to have included JAXP 1.4, but that looks to be on hold until Dolphin. However, StAX will be part of it, and soon enough, SAX will be a dim memory. Yeah, right. I give this claim about as much credence as I gave the claims that schemas were going to replace DTDs. StAX isn't as disastrously bad as schemas were, but it certainly hasn't justified the hype either. So far I've seen approximately no evidence that it provides any noticeable improvements over SAX. Some people find StAX easier to use the SAX for some use cases, but not all. I suspect Sun never saw the performance improvements they were hoping for from StAX which is why they're now off and running up another wrong path called Fast Infoset. (I was just looking at some 3rd party performance numbers on that this morning, and guess what? It isn't working out either.) I don't think SAX is the ultimate in XML performance, but I suspect even a factor of two improvement over SAX is going to require something a lot more radical than StAX. -- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
