RE: 0.20.5 release
Hi, Sorry to drop in... Just ignore me if you don't see any relevance. In any case, don't bother answering me. Considering that tables are currently the only mean to control pagination, all my documents have a tendency to include lots of tables (and they all start with a TOC). I believe I'm not alone. I would say that any improvement in the memory usage associated with tables, IMHO, is kind of critical. BTW, there are currently 8 proposed patches in Bugzilla. Most of them look to me quite simple and inoquous, and 4 of them are marked as Enhamcements for version 0.20.5 (there is also an older one for version 0.20.3). It would be nice if one of you guys could take a look at those patches and consider them before issuing the final 0.20.5 release. Congratulations to you all on an excellent job, you are doing, Ricardo Amador -Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 6:16 PM To: [EMAIL PROTECTED] Subject: 0.20.5 release Ok, RC3a seems to be rather stable and the changes since then look non-critical to me. What about doing the release now (read: next days) (and maybe 0.20.5a later if we get more hyphenation patterns back) Or should we make the changes proposed by Jörg (improved memory usage with tables - see http://marc.theaimsgroup.com/?l=fop-devm=105399053227758 ) which would require another release candidate. Comments please! Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Eclipse Ant SerializeHyphPattern failure
Jeremias,
Done. The hyphenation works now. What's the story with the
documentation targets now that we are using forrest? Can they be removed?
Peter
Jeremias Maerki wrote:
Hmm, I've given up running Ant under Eclipse. Gave me too much of a
headache and it works well for me outside of Eclipse.
But I think the trick is to use ${basedir} instead of . in build.xml
because Eclipse has to set the base directory so everything is ok. I
have done some other changes locally that I cannot commit, yet, because
I'm blocked on an issue. So I can't commit my build.xml. Can you do it,
please?
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Nomination of Glen Mazza as committer
Jeremias, Please forward off the following: Thanks, Glen Full Name: Glen Mazza Preferred Userid: gmazza Forwarding email address: [EMAIL PROTECTED] Karma: just xml-fop --- Jeremias Maerki [EMAIL PROTECTED] wrote: Can do. Here's the new account request form that we need to fill: New account request form: To: [EMAIL PROTECTED] Cc: pmc@project.apache.org, [EMAIL PROTECTED] Subject: Apache account request Full name:... Preferred userid: ... Forwarding email address: ... Requested karma: project[/subproject] ... [Vote: link to mail archive for PMC bookkeeping] On 18.06.2003 10:21:42 Christian Geisert wrote: Clearly enough +1 and no -1, congratulations Glen! According to http://www.apache.org/dev/pmc.html the account request should be handled by the PMC - so Jeremias or Peter would you please take care of this? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: 0.20.5 release
I would agree to Ricardo. We're using tables for inventory lists containing about 500 pages. The memory situation in that reports is really critical and we cannot force the users to set filters. On the other hand: to us it doesn't matter if this enhancement comes with 0.20.5 or with a later version (0.20.5a ?), which has of course to be decided by the developers and will possibly delay refactoring. Thomas Sporbeck - 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: [VOTE] Nomination of Glen Mazza as committer
Glen, the request is away. An important thing for you to do is to sign and submit the Contributor's Agreement. You can find it here: http://incubator.apache.org/drafts/newcommitters.html along with important additional information. As soon as your account is created you will need to set up the SSH tunnel for CVS access. If you have trouble, just yell! Welcome aboard! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [RTF] Jfor integration
Bertrand Delacretaz wrote: If you're going to work on the RTFHandler I'd be happy to commit the relevant jfor sources (the RTF library I assume) to the FOP codebase with appropriate package name changes. Yes, I think the RTF libs are the only parts that are needed. I don't want to mislead anyone into thinking I'm making a big commitment here -- it will probably be a little here and a little there. As Jeremias mentions, it might be better if I do it myself so that the legal stuff is clear. I should be able to do it between today and tomorrow. The idea of using jfor in binary form at first was to avoid having to maintain two RTF libraries - but if you're going for it, then the time might be right to actually move the code here. Again, go for it is too strong. However, I think integrating the libraries is a necessary prerequisite for any real progress. .. Some of the source files contain non-ASCII characters (see main/JForVersionInfo.java, line 67, for example), but are encoded as ASCII (instead of UTF-8), so the IDE was choking... Are .java files meant to be encoded in UTF-8? I didn't know that. Java source is Unicode, and I don't think the encoding would matter, but UTF-8 makes the most sense as most of the source is ASCII. And it could be that most tools don't care, but I know that JBuilder does. ...dropping in the Apache license (looks like no problem), no problem indeed and some style issues Do you mean code writing style like brace positions and stuff, or deeper code structure issues? I'm talking about the superficial stuff, $Log$ being the most obvious, and there may be some that checkstyle doesn't like. As far as the code structure, what I saw was clean and easily understandable. The only real trouble I had was finding ATTR_ constants, and I may very well be using the wrong ones (but they work). I had the RTF standard in hand as I was working through it, so I was able to reverse-engineer some of it by looking at the strings that the jfor constants were using. So I might try to document or otherwise clarify some of that stuff in the code. On the paragraph shading that I was messing with, I tried dropping the RTF codes directly in, and something downstream (probably in the actual document creating) seemed to be filtering out or ignoring them, which is why I was going to try to follow the code through that process in the debugger. It may be that some of that is documented in that downstream location. So, if there is some doc on the RTF libs, especially a mapping of what attributes are used with each RTF object, and which of the overloaded methods to use with each, that would be extremely useful. It seems like the wiki said to look at how the conversion tools used them, but that didn't seem to help much. Does it make sense in the long run for the jfor libs to be a separate project? It seems like it should have wider appeal than just for FOP, although FOP is probably a good home for it for now. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20923] New: - Render PCL controls using XSL template
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20923 Render PCL controls using XSL template Summary: Render PCL controls using XSL template Product: Fop Version: all Platform: Other OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have to use PCL commands in my PDF and PS outputs to control printer trays. Last 2 pages of my output should print from Tray2 and rest of the doucment should print from Tray1. The following are my PCL Command suggested by my printer vendor. To select Tray1 - ESCl8H To select Tray2 - ESCl1H The above control sequence is working file from an ordinary text file. I am able to select print trays and print accordingly. I have the following sample xsl template where I have these escape sequences !-- The below codings has to be tested for Tray Selection Bug -- fo:block break-before=page/fo:block fo:blocklt;ESCgt;amp;l1HThis should print From Tray 2/fo:block fo:block break-before=page/fo:block fo:blocklt;ESCgt;amp;l8HThis should print From Tray 1/fo:block fo:block break-before=page/fo:block !-- The above codings has to be modified for our Bug -- When I implement this, I am getting all my controls literally printing from the default tray. I am seriously thinking, whether the implementation of Escape sequence is correct or not. Any thoughts?.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20923] - Render PCL controls using XSL template
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20923 Render PCL controls using XSL template [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |Medium - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Glen Mazza wrote: Well, the public API has to have some way to control the whole show. You don't mean that literally--e.g.., a servlet programmer does not need useThisRenderer() and attachAreaTree() functions in a public API. (i.e., the public (embedded) API would be a strict subset of the functions available to the supervising octopus running the show) I am not sure what Jeremias meant, but yes, the API needs to at least indirectly control all of the major decisions. In my vision of the API, the servlet programmer would not need useThisRenderer(), but would need something like setOutputType(OUTPUT_PDF), which would ultimately cause the correct renderer to be selected. More likely, it would be set in a constructor. Here is some simplified sample startup code: session = new Session; document = session.addDocument(inputFile); document.addRenderType(RENDER_PDF, LAYOUT_SIMPLE, outputFile1); document.addRenderType(RENDER_POSTSCRIPT, LAYOUT_SIMPLE, outputFile2); document.addRenderType(RENDER_PDF, LAYOUT_CLASSIC, outputFile3); document.addRenderType(RENDER_PRINT); document.process() -OR- session.process() // if you want session to manage a queue of documents From a big-picture control standpoint: Document = FOTree RenderContext = AreaTree RenderType = Renderer The document.addRenderType() also builds any RenderContext objects that are needed, three in this example (the first two can share the same AreaTree, each of the others requires a different one). When document.process() is run, it looks at the RenderContext objects to determine whether an FO Tree needs to be built In this case it does (and yes, it should be in a different package). It can then loop through the RenderContext objects to see what if any layout work needs to be done, and build an Area Tree based on the output type and the selected LayoutStrategy. Each RenderContext object will then loop through the RenderTypes which are attached to it to fire up Renderers. So in the example above, the same AreaTree will be used to spit out the first two RenderTypes before trying to build the AreaTree needed for the CLASSIC layout. Of course, there are a number of configuration options available as well, all of which can be attached to the appopriate object by a servlet programmer. The actual using of those options is in other objects (and indeed, should be in other packages), but the /control/ mechanism can live in these four classes. (I have left eager/patient processing out of this example, but control should be returned to the Document object at the end of each PageSequence to see if eager processing needs to fire off some layout and rendering work before continuing with parsing. I am not entirely sure whether eager/patient processing is totally a function of the LayoutStrategy, or whether some LayoutStrategies can tolerate either, which would make it need to be configurable). This will automatically lead to a little octopus if the code is in ...fop or ...fop.api. But no problem with another package. For my discussion, apps=api (they're both supervising octopi). (Although I'm sure your package would be orders-of-magnitude cleaner and simpler!) FOP is more a pipeline to me: APPs package (CLI, TRAX/XSLTInputHandler, Avalonized API, Victor's ideas) -- FOTreeBuilder/Layout/Area Tree creation -- Rendering. Uh, thanks for that one. It's a very nice show why the current apps package is a mess. I agree with you that the apps package is hideous--but a pipeline may cleanup nearly all of it, providing it enforces the rules I mentioned earlier: a.) The only access between apps/api and the rest of the packages is via FOTreeBuilder and its three functions. b.) FOP is designed such that FOTreeBuilder *can* be directly instantiated via a servlet (even if we don't allow it). c.) Once so instantiated, no code within apps/api packages can be referenced. Via these rules, look at what gets removed from apps: (a) structure and layout handler are gone (those are past the FOTreeBuilder) (b) AWTStarter and PrintStarter are gone (those processing decisions are either handled by FOTreeBuilder or something that it delegates to.) (c) App class has *no* knowledge of renderers, element mappings, area trees, structure handlers. (d) Business logic is kept with each object, and not shared in multiple places. IMO FOTreeBuilder should just expose three functions (perhaps another one for logging): It's best to talk about lifestyle primarily and leave the lifecycle (instantiation, logging, configuration, initialization) to a different discussion. Helps keeping the focus, I believe. Excellent! We can leave that distraction out of the discussion. (Although they, in addition to threading issues, *do* appear to strengthen your argument on the need for a supervising class.) 1.)
Re: startup refactoring
Victor Mote wrote: In my vision of the API, the servlet programmer would not need useThisRenderer(), but would need something like setOutputType(OUTPUT_PDF), which would ultimately cause the correct renderer to be selected. This has already been discussed up and down. There is still the problem that renderers may need a lot of renderer specific confiuguration data. Take for example PDF encryption. I don't think it is a good idea to always pass this in some generic way through the Driver (or whatever the replacement) to the renderer. The other problem is the output. There are renderers writing to a byte stream, there is the AWT and the print renderer which don't write to a stream like object at all, there may be renderers like an SVG renderer which write a SAX event stream. Again, I don't think the output should always be passed through the driver. It seems quite natural to solve these problems by using separate renderer objects processor = new FOProcessor() // configure processor renderer = new PDFRenderer(output); // configure renderer processor.setRenderer(renderer); If there is no complicated configuration (use all defaults) you can still write with another constructor processor = new FOProcessor(); processor.format(input,new PDFRenderer(output)); which should be easy enough to servlet programmers. Note that TrAX uses a similar pattern, with Source and Result abstracting a variety of input and output mechanisms to the XSLT processor. [big snip] Discussing the API may be fun, but IMO fixing bugs like the broken text justification should get some attention too. The best API is useless if the code inside doesn't work. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20923] - Render PCL controls using XSL template
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20923 Render PCL controls using XSL template [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-19 20:40 --- Printer control commands cannot be passed through regular content in XSLFO, almost by definition. Apart from this, your understanding how printer controls look like is seriously wrong, as well as your understanding about printer tray selection mechanisms in PDF and PostScript. There are some possiblities to postprocess FOP output to achieve printer tray selection, but this is non-trivial stuff. Please don't use bugzilla to ask questions, there is a fop-user list for this purpose. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
victor quote [Responding to Jeremias here] Or, better yet IMO, into a RenderType object that is a child or grandchild of the Document, so that there can be multiple RenderTypes for the same Document. /victor quote I can understand enhancements for logging and threading, but multiple RenderTypes for the same Document appears to be Cocoon's department, not ours. We're at a level below that, very similar to Xalan: Xalan input: xml document, xslt stylesheet Xalan output: document FOP input: xml (xsl-fo namespace) document, render type FOP output: document Given that our Area tree is renderer-specific, and since the area tree creation is tightly bound to fo tree creation--I think any internal implementation we would have of multiple rendering types would just involve running FOP once for each rendering type. If so, perhaps this is best left with Cocoon. Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Errr...this came across as harsher-sounding than I would have liked. If the API has some convenient ways for the user to specify multiple output types for a single xsl-fo stream, that should be fine. Glen --- Glen Mazza [EMAIL PROTECTED] wrote: victor quote [Responding to Jeremias here] Or, better yet IMO, into a RenderType object that is a child or grandchild of the Document, so that there can be multiple RenderTypes for the same Document. /victor quote I can understand enhancements for logging and threading, but multiple RenderTypes for the same Document appears to be Cocoon's department, not ours. We're at a level below that, very similar to Xalan: Xalan input: xml document, xslt stylesheet Xalan output: document FOP input: xml (xsl-fo namespace) document, render type FOP output: document Given that our Area tree is renderer-specific, and since the area tree creation is tightly bound to fo tree creation--I think any internal implementation we would have of multiple rendering types would just involve running FOP once for each rendering type. If so, perhaps this is best left with Cocoon. Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
