DO NOT REPLY [Bug 25080] New: - typo in README
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=25080. 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=25080 typo in README Summary: typo in README Product: Fop Version: 0.20.5 Platform: All URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=220151 OS/Version: All Status: NEW Severity: Minor Priority: Other Component: documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The README file has the URL http:/xml.apache.org/fop rather than http://xml.apache.org/fop; The bug has been reported by Kevin M. Rosenberg. Thanks, Arnaud.
cvs commit: xml-fop README
vmote 2003/11/29 06:39:46 Modified:.README Log: fix typo in README; see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25080 Revision ChangesPath 1.16 +1 -1 xml-fop/README Index: README === RCS file: /home/cvs/xml-fop/README,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- README30 Nov 2002 08:54:25 - 1.15 +++ README29 Nov 2003 14:39:46 - 1.16 @@ -8,7 +8,7 @@ directly on screen. FOP is part of Apache's XML project. The homepage of FOP is -http:/xml.apache.org/fop +http://xml.apache.org/fop HTML-Documentation can be found in the subdirectory xml-fop/docs/html-docs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop README
vmote 2003/11/29 06:49:32 Modified:.Tag: fop-0_20_2-maintain README Log: fix typo in README; see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25080 Revision ChangesPath No revision No revision 1.14.4.3 +9 -9 xml-fop/README Index: README === RCS file: /home/cvs/xml-fop/README,v retrieving revision 1.14.4.2 retrieving revision 1.14.4.3 diff -u -r1.14.4.2 -r1.14.4.3 --- README10 Dec 2002 10:06:35 - 1.14.4.2 +++ README29 Nov 2003 14:49:32 - 1.14.4.3 @@ -3,14 +3,14 @@ What is FOP? FOP is the world's first print formatter driven by XSL formatting objects. It is a Java application that reads a formatting object -tree conforming to the XSL-FO Version 1.0 W3C Recommendation and -then turns it into a PDF document or allows you to preview it -directly on screen. - -FOP is part of Apache's XML project. The homepage of FOP is -http:/xml.apache.org/fop +tree conforming to the XSL-FO Version 1.0 W3C Recommendation and +then turns it into a PDF document or allows you to preview it +directly on screen. -HTML-Documentation can be found in the subdirectory build/site +FOP is part of Apache's XML project. The homepage of FOP is +http://xml.apache.org/fop + +HTML-Documentation can be found in the subdirectory build/site The names of the committers of this project and what the developers are working on can be found in the file STATUS in root. @@ -19,12 +19,12 @@ Please report bugs to bugzilla at http://nagoya.apache.org/bugzilla/ -Discussion of Fop takes place in [EMAIL PROTECTED] (subscribe at +Discussion of Fop takes place in [EMAIL PROTECTED] (subscribe at [EMAIL PROTECTED]) User questions should be sent to [EMAIL PROTECTED] Archives are available at: http://marc.theaimsgroup.com -Before you post any questions, please have a look at the FAQ at +Before you post any questions, please have a look at the FAQ at build/site/faq.html (or http://xml.apache.org/fop/faq.html for latest version) Another FAQ is available at: http://www.owal.co.uk/cgi-bin/fopfaq.cgi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25080] - typo in README
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=25080. 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=25080 typo in README [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-29 14:51 --- Fixed in trunk and maintenance branches. Thanks, Arnaud.
Properties Implementation and Canonical Mappings
In the interest of contributing (instead of just trashing) to the proposed implementation, I wrote a simple Perl script to get some counts out of a real-world XSL-FO file. Input: The XSL-FO file produced from a DocBook file I have left from a dormant project. The perl program counts the number of properties in the source file. PDF size: 130 Pages // some users have a lot more FO file size: 1.2M bytes Properties: 22,815 Unique prop names: 89 // bounded by the spec Unique prop values: 2,227 // bounded by the real world Note that storing the property name and value refs supplied to the Property constructor will use 45,620 strings. If the Property implementation employs canonical mapping to ensure that only one copy of each unique string is stored, then just over 2,300 strings are required. The property strings are given to the Property object constructor by some path beginning with a SAX parser. It is reasonable to assume that the SAX parser loses refs to most of these strings and that the Property implementation retains the only references to these String objects. How big are String Objects ? At least 16 bytes plus storage for characters. What does this save us ? Probably only about 1,600,000 bytes for this file. CPU cost of creating strings is probably similar to cost of checking string table for a copy. What does it buy for us ? Bounds a source of current Order(n) memory growth. It gets us in the habit of using another good technique. I am all ready thinking along the lines of: The property lists for these FO's are usually generated by programs and will be the repeated many times. Perhaps we could use larger, faster working Property Lists consolidated with Canonical Mappings to save both time and space. I am thinking again along the lines of handling properties more like C++ virtual function table (vTable). This object is larger than Peter's ordered Property array, but would be faster. That's a reason C++ has fast virtual function dispatching. -- John Austin [EMAIL PROTECTED]
Re: Properties Implementation and Canonical Mappings
John Austin wrote: In the interest of contributing (instead of just trashing) to the proposed implementation, I wrote a simple Perl script to get some counts out of a real-world XSL-FO file. Input: The XSL-FO file produced from a DocBook file I have left from a dormant project. The perl program counts the number of properties in the source file. PDF size: 130 Pages // some users have a lot more FO file size: 1.2M bytes Properties: 22,815 Unique prop names: 89 // bounded by the spec Unique prop values: 2,227 // bounded by the real world Note that storing the property name and value refs supplied to the Property constructor will use 45,620 strings. If the Property implementation employs canonical mapping to ensure that only one copy of each unique string is stored, then just over 2,300 strings are required. The property strings are given to the Property object constructor by some path beginning with a SAX parser. It is reasonable to assume that the SAX parser loses refs to most of these strings and that the Property implementation retains the only references to these String objects. How big are String Objects ? At least 16 bytes plus storage for characters. What does this save us ? Probably only about 1,600,000 bytes for this file. CPU cost of creating strings is probably similar to cost of checking string table for a copy. What does it buy for us ? Bounds a source of current Order(n) memory growth. It gets us in the habit of using another good technique. I am all ready thinking along the lines of: The property lists for these FO's are usually generated by programs and will be the repeated many times. Perhaps we could use larger, faster working Property Lists consolidated with Canonical Mappings to save both time and space. I am thinking again along the lines of handling properties more like C++ virtual function table (vTable). This object is larger than Peter's ordered Property array, but would be faster. That's a reason C++ has fast virtual function dispatching.
Re: Properties Implementation and Canonical Mappings
Darn, racall the last post. John Austin wrote: Note that storing the property name and value refs supplied to the Property constructor will use 45,620 strings. If the Property implementation employs canonical mapping to ensure that only one copy of each unique string is stored, then just over 2,300 strings are required. Have a look at String.intern() J.Pietschmann
Re: Properties Implementation and Canonical Mappings
On Sat, 2003-11-29 at 16:35, J.Pietschmann wrote: Darn, racall the last post. John Austin wrote: Note that storing the property name and value refs supplied to the Property constructor will use 45,620 strings. If the Property implementation employs canonical mapping to ensure that only one copy of each unique string is stored, then just over 2,300 strings are required. Have a look at String.intern() Bruce Eckel said not to trust it for some reason. I have 2nd Ed of Thinking in Java and the online one is 3rd Ed so I haven't found chapter and verse for this yet. The only 'bad thing' said about it that I could find quickly was: http://mindprod.com/jgloss/gotchas.html The other good thing we can do is compare these string refs for equality. J.Pietschmann -- John Austin [EMAIL PROTECTED]
Traits again
Victor Mote wrote: Glen Mazza wrote: ... (2.) Just as an FYI, as to the issue of whether the FO's themselves have traits--from our previous discussion, you were saying that elements have attributes, FOs have properties and Area Tree elements have traits, I believe. That fact is confirmed in the second paragraph of the Ch. 3 of the spec[1]. However, somewhat confusingly, if you look at the second, third, and fourth diagrams in 1.1.2, Formatting[2], the spec also refers to traits as the refined/finished properties of the refined formatting object tree. So in some cases, they do consider traits to be both at the finished FO tree and the area tree. [1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice3.html#fo-jc-intro [2] http://www.w3.org/TR/2001/REC-xsl-20011015/slice1.html#section-N74 2-Formatting I don't think I had noticed this before. It looks like the standard *does* consider the refined properties to be traits. Since a refined value in the FO Tree should be the same as the value used in the Area Tree, that makes some sense. There is not a simple correspondence between properties and traits in all cases. See my table http://xml.apache.org/fop/design/alt.design/traits.html for a summary of traits. I can't recall whether it is complete, but I scoured the Rec for references, and put what I could find in there. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
