DO NOT REPLY [Bug 25248] New: - XSL Parameter passing
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=25248. 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=25248 XSL Parameter passing Summary: XSL Parameter passing Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I would be very helpful, if Apache FOP could handle XSL parameters (like XALAN's -PARAM attribute). I have some stylesheets with params, I'd like to process directly calling FOP without double handling (Transforming the XSL Stylesheet with XALAN first and pass the result to FOP): ?xml version=1.0 encoding=UTF-8? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:n1=http://www.agere.com/qm/process; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsl:param name=base.dir select='.'/ xsl:param name=logo select=concat($base.dir,'/','agere_logo.jpg')/ ... The primitive call/usage could be something like this (copied from XALAN syntax): java org.apache.fop.apps.Fop -xml xmlfile.xml -xsl xslfile.xsl -pdf pdffile.pdf -param base.dir C:/base/dir
Re: Java 2D code generator
--- Chris Williams [EMAIL PROTECTED] wrote: I was wondering if within Batik there was a code generator to convert SVG documents into java 2d code (actual code, not rendered). I know SVGCanvas2D will render it, but i am looking to generate the actual code, so i can package that up. Any ideas? Yes, ask the Batik-Users list. Glen __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
RE: [VOTE] Properties API
Peter B. West wrote: Yes, this is the real issue. Only one of the real issues, I'm afraid. OK, what are the others? The thorns that immediately stick in my finger are The topic at hand is what API is needed for the FO Tree to be able to pass property values to its clients. 1) markers I have a pretty well-developed idea of how to implement the FO tree building side of this in alt.design. It involves static-content-specific changes to the current FO tree building algorithm, and a slight generalization of the SyncedFoXmlEventsBuffer class to allow events to be read from a variety of sources. In a word, grafting. OK, I have addressed this. 2) Area tree dependencies for FO expressions. Basically, length calculations involving percentages. OK, I proposed passing the relevant Area to the get method. 2a) Handling the expressions. This can all be done within the FO Tree. 2b) Designing the interaction between the FO builder and the Area tree builder. OK. I proposed the following, which you have not addressed: from-previous-posting Your experience and insight on this issue are extremely important. If Areas know how to find their FOTree heritage as well as their AreaTree heritage, can you think of any concept that is missing to do Property resolution, assuming that the relevant Area is passed to the get method on the FOTree side? /from-previous-posting 3) Layout look-ahead and backtracking. Closely related to 2b. AFACT, these would become simply re-getting the value from the FO Tree, passing a new Area as a parameter. 4) Managing the association out-of-line areas (footnotes and floats) with the FONode/Area in which it was defined and the higher-level areas (e.g. before-float-reference-area, footnote-reference-area, main-reference-area) which are juggled as a result of the lower-level contents. Is this not just a specialized case for the general case #2 above? Victor Mote
cvs commit: xml-fop/src/documentation/resources/images logo2.svg
vmote 2003/12/05 11:13:06 Added: src/documentation/resources/images logo2.svg Log: add svg image for new FOP logo Revision ChangesPath 1.1 xml-fop/src/documentation/resources/images/logo2.svg http://cvs.apache.org/viewcvs/xml-fop/src/documentation/resources/images/logo2.svg?rev=1.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP logo update
Victor Mote wrote: Clay Leeds wrote: I was unable to make much progress on this topic. I am unable to get SVG and/or vector versions of the logo. We do, however, have a JPG version. Thanks for your efforts here. I'll work on creating an svg version. I just checked in src/documentation/resources/images/logo2.svg, which is the first pass at an svg version of the new logo. Please let me know if you have any comments, even if you think that it is OK as is. I know some wanted to tweak it, and this is probably not a perfect image of the original design anyway. Also, does it make sense to check in the Adobe Illustrator file that was used to create it? That might make editing it easier. Victor Mote
Re: [VOTE] Properties API
Peter B. West wrote: 4) Managing the association out-of-line areas (footnotes and floats) with the FONode/Area in which it was defined and the higher-level areas (e.g. before-float-reference-area, footnote-reference-area, main-reference-area) which are juggled as a result of the lower-level contents. Footnotes are basically float-after areas. Both float before and footnotes are not much of a problem except for multi column layout (and, well, in tables). In multi-column layouts, the equal width of the column should allow reassigning content after decreasing column height without doing a complete re-layout. Side floats, of course, are a real pain, especially if you want to do conflict resolution properly. J.Pietschmann
Re: FOP logo update
Victor Mote wrote: Clay Leeds wrote: I was unable to make much progress on this topic. I am unable to get SVG and/or vector versions of the logo. We do, however, have a JPG version. Thanks for your efforts here. I'll work on creating an svg version. I just checked in src/documentation/resources/images/logo2.svg, which is the first pass at an svg version of the new logo. Please let me know if you have any comments, even if you think that it is OK as is. I know some wanted to tweak it, and this is probably not a perfect image of the original design anyway. Also, does it make sense to check in the Adobe Illustrator file that was used to create it? That might make editing it easier. Victor Mote I think it makes sense to check in the Illustrator file used to create the file. I'll check it out and let you know what I think. Web Maestro Clay
Re: [VOTE] Properties API
J.Pietschmann wrote: Footnotes are basically float-after areas. Both float before and footnotes are not much of a problem except for multi column layout (and, well, in tables). In multi-column layouts, the equal width of the column should allow reassigning content after decreasing column height without doing a complete re-layout. Side floats, of course, are a real pain, especially if you want to do conflict resolution properly. I'm still attached to my proposed footnote processing method as described in the alt.design notes. http://xml.apache.org/fop/design/alt.design/footnotes.html I'm looking at extending it to cope with footnotes in tables within columns. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [VOTE] Properties API
Victor Mote wrote: Peter B. West wrote: ... The topic at hand is what API is needed for the FO Tree to be able to pass property values to its clients. Ok. The trouble is that the relationship between FO Tree and Area Tree is, for me, still very much an unresolved question. When we start talking about these things, I go back to thinking about the details of the interaction between FO Nodes and Areas in the Area Tree. Isn't part of your rationale in this get method to provide for the feedback of FO data to the Areas? At what points do you see the method being invoked? 1) markers I have a pretty well-developed idea of how to implement the FO tree building side of this in alt.design. It involves static-content-specific changes to the current FO tree building algorithm, and a slight generalization of the SyncedFoXmlEventsBuffer class to allow events to be read from a variety of sources. In a word, grafting. OK, I have addressed this. We do have very different grafting methodologies. 2) Area tree dependencies for FO expressions. Basically, length calculations involving percentages. OK, I proposed passing the relevant Area to the get method. Is this happening when an area is looking for information about its generating FO? 2a) Handling the expressions. This can all be done within the FO Tree. But, if I understand you correctly, only with reference to the Area Tree (via the passing of Area parameters in the get method.) 2b) Designing the interaction between the FO builder and the Area tree builder. OK. I proposed the following, which you have not addressed: from-previous-posting Your experience and insight on this issue are extremely important. If Areas know how to find their FOTree heritage as well as their AreaTree heritage, can you think of any concept that is missing to do Property resolution, assuming that the relevant Area is passed to the get method on the FOTree side? /from-previous-posting This seems to me to be begging the question to some extent. Rather than the Areas knowing how to find their FOTree heritage, isn't it necessary for the FOs to be able to find the AreaTree ancestry of the Areas that the FOs are generating? Isn't that what passing the relevant area in the get is all about? At the same time, however, it does get us thinking about the precise nature of this interaction. 3) Layout look-ahead and backtracking. Closely related to 2b. AFACT, these would become simply re-getting the value from the FO Tree, passing a new Area as a parameter. 4) Managing the association out-of-line areas (footnotes and floats) with the FONode/Area in which it was defined and the higher-level areas (e.g. before-float-reference-area, footnote-reference-area, main-reference-area) which are juggled as a result of the lower-level contents. Is this not just a specialized case for the general case #2 above? Very specialized. These things can force re-layout of the existing page, and can even ramify to previous pages, as we move towards a more intelligent layout strategy. There are two problematical aspects: Layout look-ahead, to determine layout errors (e.g. footnote overflow, last page), and Layout lookahead to determine actual dimensions (auto table layout.) Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
