cvs commit: xml-fop/src/documentation/content/xdocs resources.xml
keiron 2002/11/19 00:13:10 Modified:src/documentation/content/xdocs resources.xml Log: 1. Adds links to the Eyebrowse mail list archives. 2. Adds help and unsubscribe email addresses for the fop-user fop-dev lists. 3. Rewrote/rearranged some of the verbiage for better structure. Submitted By: [EMAIL PROTECTED] (Victor Mote) Revision ChangesPath 1.3 +120 -38 xml-fop/src/documentation/content/xdocs/resources.xml Index: resources.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/resources.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- resources.xml 19 Nov 2002 07:57:27 - 1.2 +++ resources.xml 19 Nov 2002 08:13:10 - 1.3 @@ -8,74 +8,156 @@ titleResources/title subtitleResources useful for developing and using FOP/subtitle /header - body - section titleFOP Relevant Specifications and Links/title section titleMailing Lists (and archives)/title +p +For the Apache mailing lists, see +link href=http://xml.apache.org/mail.html;Apache XML Mailing Lists/link +for detailed subscription information. +/p section titleFOP User Mailing List/title +p +Use this forum to discuss topics of interest to FOP users. +After reviewing the FOP documentation and searching the +archives (see below), use this forum to ask questions about +how to download, install, configure, and use FOP. Please do +emnot /emuse this forum for general XSL-FO, XSLT, or PDF questions. +/p ul -liSend a mail to link href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/link - to subscribe (use link href=mailto:[EMAIL PROTECTED]; - [EMAIL PROTECTED]/link for digest). - This is where user specific topics are discussed. For detailed instructions on the subscription, see - link href=http://xml.apache.org/mail.html;Apache XML Mailing Lists/link./li - liThe Mailing list ARChives (MARC) at the AIMS group: - link href=http://marc.theaimsgroup.com/?l=fop-useramp;r=1amp;w=2;fop-user/link -(searchable)/li -lilink href=http://xml.apache.org/mail/fop-user/;Apache archive of [EMAIL PROTECTED]/link/li +li +To review the archives, you have several options: + ul +li +The link href=http://marc.theaimsgroup.com/?l=fop-useramp;r=1amp;w=2;Mailing list ARChives /link (MARC) at the AIMS group (search). +/li +li +The link href=http://nagoya.apache.org/eyebrowse/SummarizeList?[EMAIL PROTECTED];Apache Eyebrowse/link archive (search, list by date, author, subject, or thread). +/li +li +The link href=http://xml.apache.org/mail/fop-user;Apache Mailing List archive/link (gzip files). +/li + /ul +/li +li +To subscribe (digest only): Send email to link href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/link. +/li +li +To subscribe fully: Send email to link href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/link. +/li +li +For standard help: Send email to link href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/link. +/li +li +To unsubscribe: Send email to link href=[EMAIL PROTECTED][EMAIL PROTECTED]/link. +/li /ul /section section titleFOP Developer Mailing List/title + p +Use this forum to discuss topics related to FOP development, +including patch submissions, bug reports, and design issues. + /p ul -liSend a mail to link href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/link - to subscribe. (use link href=mailto:[EMAIL PROTECTED]; - [EMAIL PROTECTED]/link for digest). - For detailed instructions on the subscription, see - link href=http://xml.apache.org/mail.html;Apache XML Mailing Lists/link./li - liThe Mailing list ARChives (MARC) at the AIMS group: - link href=http://marc.theaimsgroup.com/?l=fop-devamp;r=1amp;w=2;fop-dev/link (searchable) +li +To review the archives, you have several options: + ul +liThe link href=http://marc.theaimsgroup.com/?l=fop-devamp;r=1amp;w=2;Mailing list ARChives/link (MARC) at the AIMS group (search). +/li +li +The link href=http://nagoya.apache.org/eyebrowse/SummarizeList?[EMAIL PROTECTED];Apache Eyebrowse/link archive (search, list by date, author, subject, or thread). +/li +li +The link
DO NOT REPLY [Bug 14637] - fo:retrieve-marker is confused by 2-columns reports
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=14637. 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=14637 fo:retrieve-marker is confused by 2-columns reports --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 08:17 --- Ok, it's rather subtle bug, just wait for 0.20.5 (it's a matter of days now) and check it out. Feel free to reopen the bug then. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Sun xsl formatter being donated to open source
On Tue, 2002-11-19 at 09:18, Oleg Tkachenko wrote: Hello there! Nikolai Grigoriev discovered new xsl formatter becoming open source ;) http://www.xmlconference.org/xmlusa/2002/thursday.asp#vp5 Comments? Does anybody plan to participate xml 2002? Some people even suggest it's Apache where Sun want to donate it to. So why would they do it in that order. Why not donate resources to develop. I haven't heard anything so we'll see what happens. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14569] - basic-link problem
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=14569. 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=14569 basic-link problem --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 08:32 --- Please, provide you fo document as *attachment*, not as plain text within a description. Your example was screwed up by hyphenations, I'm unable to fix 22 page document by hands. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6147] - TTFReader can't handle TradeGothic fonts
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=6147. 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=6147 TTFReader can't handle TradeGothic fonts [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 09:39 --- It's my understanding this is fixed in cvs. Anyway to check it out I need th efont file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs status.xml
keiron 2002/11/19 01:40:03 Modified:src/documentation/content/xdocs status.xml Log: updated data Revision ChangesPath 1.4 +28 -43xml-fop/src/documentation/content/xdocs/status.xml Index: status.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/status.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- status.xml19 Nov 2002 07:57:27 - 1.3 +++ status.xml19 Nov 2002 09:40:03 - 1.4 @@ -13,7 +13,7 @@ body section titleStatus/title -p[last updated 10th June 2002]/p +p[last updated 20th November 2002]/p figure width=585 height=175 src=images/track.png alt=Planning and branches of FOP development / p This is the development status of FOP. A branch has been created for @@ -25,20 +25,6 @@ section titleDevelopment Status/title p -Volunteers needed for:/p -ul -liconfiguration implementation/li -liimplement formatting objects and properties/li -liAWT/Swing viewer design and implementation/li -lidocumentation/li -liMIF output/li -/ul -p -... and plenty of other areas. See the link href=todo.htmltodo/link -list for more details. -See this link href=dev/status.htmlStatus/link for more information. -/p -p Development for 1.0DR1 is addressing the design issues for layout and performance. The new design focusing on making it possible to be conformant to the spec and be able to handle large documents. The development effort @@ -55,7 +41,7 @@ /p pstrongBinaries/strong/p table - trtdfop.jar/tdtd1,966 kb/td/tr + trtdfop.jar/tdtd1,962 kb/td/tr trtdhyphention (in fop.jar)/tdtd717 kb/td/tr trtdbatik.jar/tdtd2,164 kb/td/tr trtdbsf.jar/tdtd106 kb/td/tr @@ -65,30 +51,29 @@ pstrongLines of code/strong using find . -iname *.java | xargs cat | wc -l/p table - trtdorg.apache.fop.*/tdtd67076/td/tr - trtdorg.apache.fop.fo.*/tdtd15257 (23%)/td/tr - trtdorg.apache.fop.layoutmgr.*/tdtd4537 (7%)/td/tr - trtdorg.apache.fop.area.*/tdtd2314 (3.5%)/td/tr - trtdorg.apache.fop.render.*/tdtd6474 (10%)/td/tr - trtdorg.apache.fop.pdf.*/tdtd8113 (12%)/td/tr + trtdorg.apache.fop.*/tdtd67479/td/tr + trtdorg.apache.fop.fo.*/tdtd13186 (20%)/td/tr + trtdorg.apache.fop.layoutmgr.*/tdtd7913 (12%)/td/tr + trtdorg.apache.fop.area.*/tdtd3722 (5.5%)/td/tr + trtdorg.apache.fop.render.*/tdtd8210 (12%)/td/tr + trtdorg.apache.fop.pdf.*/tdtd9481 (14%)/td/tr /table pstrongFiles/strong using find . -iname *.java | wc -l/p table - trtdorg.apache.fop.*/tdtd462/td/tr - trtdorg.apache.fop.fo.*/tdtd127 (27%)/td/tr - trtdorg.apache.fop.layoutmgr.*/tdtd28 (6%)/td/tr - trtdorg.apache.fop.area.*/tdtd36 (8%)/td/tr - trtdorg.apache.fop.render.*/tdtd35 (8%)/td/tr + trtdorg.apache.fop.*/tdtd442/td/tr + trtdorg.apache.fop.fo.*/tdtd125 (28%)/td/tr + trtdorg.apache.fop.layoutmgr.*/tdtd35 (8%)/td/tr + trtdorg.apache.fop.area.*/tdtd37 (8%)/td/tr + trtdorg.apache.fop.render.*/tdtd39 (9%)/td/tr /table - /section section titleMaintenance Status/title p -Latest maintenance release was FOP 0.20.3 on 4th March 2002. +Latest maintenance release was FOP 0.20.5 on 24th November 2002. See link href=relnotes.htmlrelease notes/link for more details. Releases will be made periodically to address minor bugs and compatibility. @@ -96,31 +81,31 @@ pstrongBinaries/strong/p table - trtdfop.jar/tdtd1,695 kb/td/tr + trtdfop.jar/tdtd1,992 kb/td/tr trtdhyphention (in fop.jar)/tdtd746 kb/td/tr - trtdbatik.jar/tdtd2,164 kb/td/tr + trtdbatik.jar/tdtd2,119 kb/td/tr trtdbsf.jar/tdtd106 kb/td/tr - trtdxalan.jar/tdtd906 kb/td/tr - trtdxercesImpl.jar/tdtd1,729 kb/td/tr - trtdxml-apis.jar/tdtd108 kb/td/tr + trtdxalan.jar/tdtd1,007 kb/td/tr + trtdxercesImpl.jar/tdtd813 kb/td/tr + trtdxml-apis.jar/tdtd112 kb/td/tr /table pstrongLines of code/strong using find . -iname *.java | xargs cat | wc -l/p table - trtdorg.apache.fop.*/tdtd69131/td/tr - trtdorg.apache.fop.fo.*/tdtd14916 (22%)/td/tr - trtdorg.apache.fop.layout.*/tdtd7108 (10%)/td/tr - trtdorg.apache.fop.render.*/tdtd15840 (23%)/td/tr - trtdorg.apache.fop.pdf.*/tdtd7883 (11%)/td/tr + trtdorg.apache.fop.*/tdtd69610/td/tr + trtdorg.apache.fop.fo.*/tdtd14660 (21%)/td/tr + trtdorg.apache.fop.layout.*/tdtd7154 (10%)/td/tr + trtdorg.apache.fop.render.*/tdtd16260 (23%)/td/tr + trtdorg.apache.fop.pdf.*/tdtd7938 (11%)/td/tr /table pstrongFiles/strong using find . -iname *.java | wc
RE: Getting breaks: revisited
On Sat, 2002-11-16 at 09:21, Rhett Aultman wrote: It seems to me that there are (at least) two approaches: 1. A leaf on the tree says I am here, put me somewhere on a page, or 2. A higher-level node (page-sequence) says I have some space here, send me something to fill it. 3. 1 + 2. Thinking that you can do 1. in isolation is, well, brain-dead. On the other hand, how does 2. handle auto table layout? The columns cannot be dimensioned at the very top until the last information about requirements is in from the very bottom. Then the decision is taken at the top, and percolates all the way back down again. I agree that there's a combination of both approaches are necessary, but I'm not sure how 1 handles auto table layout all that much better. I did just wake up over an on-call issue, so maybe it's grogginess, but wouldn't auto-layout either way require reading the whole table first to divine column widths? I will concede that, under option 2, it's not clear if the table will fit in the proffered space until after the entire table is processed, meaning that a purely 2 system is doing a LOT of looking ahead, just to keep up with itself. Is this the handicap of the second option you're referring to? Under the first option, the table can take care of itself, then demand to be placed somewhere, which has the benefit of less looking down the road but the deficit that there may not be room for it anywhere. What if, instead, two passes were taken? The first pass would be for trying to find space for all of the objects with hard-and-fast space and size needs, and then the second pass would place objects that are more malleable. By taking two passes, it'd be possible to first divine the size of auto-layout tables, for example. Like I said...it's late and I was roused from bed, so I may have not really thought about this as much as I should, but this is brainstorming... If possible I think we should try to avoid making multiple passes since it can lead to loops etc. The table layout auto will need at least two passes but this should be possible using the layout managers. The general concept of layout managers is that a layout manager deals with the breaks that the child layout managers create. So that it can group together breaks when there is a keep together and only return one break to the parent LM which is allowed against the keeps. This can then be extended to the situation where it needs to break within that keep, it will return the best available break. The parent can then deal with it appropriately. I think the idea is sound but there are some implementation questions about dealing with keep with previous and other situations. Now the real problems. What happens for footnotes. A footnote takes space from the main reference area. So we need some way of calculating the remaining space given a potential footnote and the inline area (or line) that adds the footnote. Do we pass the information all the way to the top and then get an answer or is there some other way that the calculation can be achieved where it is needed. Before you say thats simple, just subtract it from the body bpd, well what happens if the footnote is inside a page column. The height that the columns require needs to be calculated by balancing the columns with the currently available areas, then you find the space remaining with the footnote. There are alos situations where the footnote is added where the whole block must be added. Then it must wait until the block is complete before saying if the block and footnote can fit. Sometimes it needs to make a calculation with an abritrary ancestor other times it needs to hold until another ancestor finds a valid break before know if it will fit. So how do we deal with all these things without making it really slow and complicated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8635] - FOP replace japanese chars into # on Linux
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=8635. 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=8635 FOP replace japanese chars into # on Linux [EMAIL PROTECTED] changed: What|Removed |Added Summary|FOP replace japanese chars |FOP replace japanese chars |into # on Linux |into # on Linux --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 10:12 --- Are you sure the font has glyphs for ascii characters? Anyway we should resolve it somehow. Attach font ttf file here if it's not too big (or alternatively send it to me privately) and I'll try to figure out what's going on wrong. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12421] - Strange fo:leader behavior
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=12421. 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=12421 Strange fo:leader behavior [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 11:34 --- *** This bug has been marked as a duplicate of 7490 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7490] - fo:leader pushes words out of line
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=7490. 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=7490 fo:leader pushes words out of line [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 11:34 --- *** Bug 12421 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop status.xml
keiron 2002/11/19 04:12:29 Modified:.status.xml Log: updated for doc and other changes added Oleg Revision ChangesPath 1.15 +42 -17xml-fop/status.xml Index: status.xml === RCS file: /home/cvs/xml-fop/status.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- status.xml6 Nov 2002 16:25:17 - 1.14 +++ status.xml19 Nov 2002 12:12:29 - 1.15 @@ -10,6 +10,7 @@ person name=Jeremias Maerki email=[EMAIL PROTECTED] id=JM/ person name=Joerg Pietschmann email=[EMAIL PROTECTED] id=JP/ person name=Arved Sandstrom email=[EMAIL PROTECTED] id=AS/ + person name=Oleg Tkachenko email=[EMAIL PROTECTED] id=OT/ person name=Peter B. West email=[EMAIL PROTECTED] id=PBW/ !-- @@ -29,9 +30,16 @@ todo actions priority=high action context=code dev=open - Sort out page sequence details and page numbering. + From branch: char encoding for pdf output. /action action context=code dev=open + From branch: delete output file if error occured. +/action +action context=code dev=open + From branch: add CCITT TIFF file support for embedding in pdf. +/action + +action context=code dev=open Add markers to page when areas added. When an area is added that is created by an FO that contains markers then the markers can also be added. There are four types of positions @@ -42,18 +50,6 @@ When doing the static areas the markers will need to be available for retrieving. The marker can then be layed out as normal. /action -action context=code dev=KLL - Implement table layout. - The table layout will use the same technique as the block layout. It - will locate suitable breaks between rows or inside rows until table - finished or end of bpd reached. -/action -action context=code dev=open - Implement list layout. - The list layout like the table layout will be looking for suitable - breaks from the child objects. The it will add the appropriate areas to - the area tree. -/action action context=code dev=open Implement spacing between blocks and the adjustment to actual height when adding areas. @@ -72,9 +68,6 @@ the footnote area. /action action context=code dev=open - Implement border and background for block and inline areas. -/action -action context=code dev=open Implement floats. A float adds an anchor inline or block area to the parent and a block is added to the nearest reference area. The @@ -117,6 +110,38 @@ changes release version=? date=2002 +action context=docs dev=KLL type=update +due-to=Victor Mote due-to-email=[EMAIL PROTECTED] + Added links to the Eyebrowse mail list archives. + Added help and unsubscribe email addresses for the fop-user + amp; fop-dev lists. + Rewrote/rearranged some of the verbiage for better structure. +/action +action context=docs dev=KLL type=update +due-to=Victor Mote due-to-email=[EMAIL PROTECTED] + Valid URIs for all xdoc DTD declarations. + Some minor changes for xdoc documents that were discovered to be invalid + after the DTD declarations were fixed. + Changed tabs.xml so that the 2nd tab on our site will now read Redesign + instead of dev. +/action +action context=docs dev=KLL type=update +due-to=Victor Mote due-to-email=[EMAIL PROTECTED] + Better links to Bugzilla. + Reorganized content into a checklist. +/action +action context=code dev=KLL type=update + Added support for markers in fo tree. Markers added when valid + to proper fo objects. +/action +action context=docs dev=KLL type=update +due-to=Victor Mote due-to-email=[EMAIL PROTECTED] + Added compliance document showing table of fop compliance. +/action +action context=code dev=KLL type=update +due-to=Stephan Neuhaus due-to-email=[EMAIL PROTECTED] + From branch: fixed jpeg icc profile error with acrobat 5. +/action action context=code dev=KLL type=update due-to=Oleg Tkachenko due-to-email=[EMAIL PROTECTED] Awt viewer improvements - uses java PropertyResourceBundle @@ -194,7 +219,7 @@ values for the end character. Handles unsupported non-unicode cmap better. Added logging. /action -action context=code dev=JP type=new +action context=code dev=JP type=update Add static areas to page The static areas will need to be handled in a similar way to the flow except the bpd is
DO NOT REPLY [Bug 12268] - FOP 0.20.4 cause PDF buffer append for each rendering.
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=12268. 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=12268 FOP 0.20.4 cause PDF buffer append for each rendering. --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 12:14 --- Sounds too bizarre. How come 'out' buffer accumulates results? ByteArrayOutputStream out = new ByteArrayOutputStream(); driver.reset(); driver.setInputSource(inputSource); //Make sure here out buffer is empty. driver.setOutputStream(out); driver.run(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/lib xercesImpl-2.2.1.jar xercesImpl-2.2.0.jar
jeremias2002/11/19 05:33:22 Added: lib Tag: fop-0_20_2-maintain xercesImpl-2.2.1.jar Removed: lib Tag: fop-0_20_2-maintain xercesImpl-2.2.0.jar Log: Upgrade to Xerces 2.2.1 (bugfix release) Revision ChangesPath No revision No revision 1.1.2.1 +2998 -0 xml-fop/lib/Attic/xercesImpl-2.2.1.jar Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/contrib/servlet build.sh build.bat
jeremias2002/11/19 05:33:54 Modified:contrib/servlet Tag: fop-0_20_2-maintain build.sh build.bat Log: Adjust classpath Revision ChangesPath No revision No revision 1.1.2.5 +1 -1 xml-fop/contrib/servlet/build.sh Index: build.sh === RCS file: /home/cvs/xml-fop/contrib/servlet/build.sh,v retrieving revision 1.1.2.4 retrieving revision 1.1.2.5 diff -u -r1.1.2.4 -r1.1.2.5 --- build.sh 11 Nov 2002 10:22:34 - 1.1.2.4 +++ build.sh 19 Nov 2002 13:33:54 - 1.1.2.5 @@ -16,7 +16,7 @@ LOCALCLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/classes.zip LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/ant-1.5.1.jar LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xml-apis.jar -LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xercesImpl-2.2.0.jar +LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xercesImpl-2.2.1.jar LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xalan-2.4.1.jar ANT_HOME=$LIBDIR 1.1.2.5 +1 -1 xml-fop/contrib/servlet/build.bat Index: build.bat === RCS file: /home/cvs/xml-fop/contrib/servlet/build.bat,v retrieving revision 1.1.2.4 retrieving revision 1.1.2.5 diff -u -r1.1.2.4 -r1.1.2.5 --- build.bat 11 Nov 2002 10:22:34 - 1.1.2.4 +++ build.bat 19 Nov 2002 13:33:54 - 1.1.2.5 @@ -9,7 +9,7 @@ set LOCALCLASSPATH=%JAVA_HOME%\lib\tools.jar;%JAVA_HOME%\lib\classes.zip set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\ant-1.5.1.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xml-apis.jar -set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xercesImpl-2.2.0.jar +set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xercesImpl-2.2.1.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xalan-2.4.1.jar set ANT_HOME=%LIBDIR% - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/examples runtests.sh runtests.bat
jeremias2002/11/19 05:34:08 Modified:docs/examples Tag: fop-0_20_2-maintain runtests.sh runtests.bat Log: Adjust classpath Revision ChangesPath No revision No revision 1.8.2.9 +1 -1 xml-fop/docs/examples/runtests.sh Index: runtests.sh === RCS file: /home/cvs/xml-fop/docs/examples/runtests.sh,v retrieving revision 1.8.2.8 retrieving revision 1.8.2.9 diff -u -r1.8.2.8 -r1.8.2.9 --- runtests.sh 18 Nov 2002 14:37:45 - 1.8.2.8 +++ runtests.sh 19 Nov 2002 13:34:08 - 1.8.2.9 @@ -29,7 +29,7 @@ LOCALCLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/classes.zip LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/ant-1.5.1.jar LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xml-apis.jar -LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xercesImpl-2.2.0.jar +LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xercesImpl-2.2.1.jar LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xalan-2.4.1.jar LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/batik.jar LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/avalon-framework-cvs-20020806.jar 1.11.2.9 +1 -1 xml-fop/docs/examples/runtests.bat Index: runtests.bat === RCS file: /home/cvs/xml-fop/docs/examples/runtests.bat,v retrieving revision 1.11.2.8 retrieving revision 1.11.2.9 diff -u -r1.11.2.8 -r1.11.2.9 --- runtests.bat 18 Nov 2002 14:37:45 - 1.11.2.8 +++ runtests.bat 19 Nov 2002 13:34:08 - 1.11.2.9 @@ -10,7 +10,7 @@ set LOCALCLASSPATH=%JAVA_HOME%\lib\tools.jar;%JAVA_HOME%\lib\classes.zip set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\ant-1.5.1.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xml-apis.jar -set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xercesImpl-2.2.0.jar +set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xercesImpl-2.2.1.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xalan-2.4.1.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\batik.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\avalon-framework-cvs-20020806.jar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop fop.bat build.xml build.sh build.bat
jeremias2002/11/19 05:42:55
Modified:.Tag: fop-0_20_2-maintain fop.bat build.xml build.sh
build.bat
Log:
Adjust classpath
Reduced the classpath in build.bat/sh to a minimum for easier maintenance.
Revision ChangesPath
No revision
No revision
1.4.2.7 +14 -1 xml-fop/fop.bat
Index: fop.bat
===
RCS file: /home/cvs/xml-fop/fop.bat,v
retrieving revision 1.4.2.6
retrieving revision 1.4.2.7
diff -u -r1.4.2.6 -r1.4.2.7
--- fop.bat 18 Nov 2002 21:04:58 - 1.4.2.6
+++ fop.bat 19 Nov 2002 13:42:55 - 1.4.2.7
@@ -1 +1,14 @@
-java -cp
build\fop.jar;lib\batik.jar;lib\xalan-2.4.1.jar;lib\xercesImpl-2.2.0.jar;lib\xml-apis.jar;lib\avalon-framework-cvs-20020806.jar;lib\logkit-1.0.jar;lib\jimi-1.0.jar
org.apache.fop.apps.Fop %1 %2 %3 %4 %5 %6 %7 %8
\ No newline at end of file
+@ECHO OFF
+
+set LIBDIR=lib
+set LOCALCLASSPATH=build/fop.jar
+set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xml-apis.jar
+set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xercesImpl-2.2.1.jar
+set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xalan-2.4.1.jar
+set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\batik.jar
+set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\avalon-framework-cvs-20020806.jar
+set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\bsf.jar
+set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jimi-1.0.jar
+set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jai_core.jar
+set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jai_codec.jar
+java -cp %LOCALCLASSPATH% org.apache.fop.apps.Fop %1 %2 %3 %4 %5 %6 %7 %8
\ No newline at end of file
1.44.2.28 +15 -9 xml-fop/build.xml
Index: build.xml
===
RCS file: /home/cvs/xml-fop/build.xml,v
retrieving revision 1.44.2.27
retrieving revision 1.44.2.28
diff -u -r1.44.2.27 -r1.44.2.28
--- build.xml 18 Nov 2002 14:37:45 - 1.44.2.27
+++ build.xml 19 Nov 2002 13:42:55 - 1.44.2.28
@@ -136,15 +136,15 @@
/fileset
fileset dir=${basedir} id=dist.bin.lib
-include name=lib/xercesImpl-2.0.1.jar/
+include name=lib/xerces*.jar/
include name=lib/xerces.LICENSE.txt/
include name=lib/xml-apis.jar/
include name=lib/xml-apis.README.txt/
-include name=lib/xalan-2.3.1.jar/
+include name=lib/xalan*.jar/
include name=lib/xalan.LICENSE.txt/
include name=lib/batik.jar/
include name=lib/batik.LICENSE.txt/
-include name=lib/avalon-framework-cvs-20020806.jar/
+include name=lib/avalon-framework*.jar/
include name=lib/avalon.LICENSE.txt/
include name=lib/readme/
/fileset
@@ -172,7 +172,11 @@
!--include name=stylebook*.jar/--
include name=xalan*.jar/
include name=xerces*.jar/
- include name=xml-apis*.jar/
+ include name=xml-apis.jar/
+ include name=avalon-framework*.jar/
+ include name=batik*.jar/
+ include name=jimi*.jar/
+ include name=jai*.jar/
/fileset
/path
@@ -295,10 +299,10 @@
/target
target name=init-avail
-available property=jimi.present classname=com.sun.jimi.core.Jimi/
-available property=jai.present classname=javax.media.jai.JAI/
+available property=jimi.present classname=com.sun.jimi.core.Jimi
classpathref=libs-build-classpath/
+available property=jai.present classname=javax.media.jai.JAI
classpathref=libs-build-classpath/
-available property=trax.present classname=javax.xml.transform.Transformer/
+available property=trax.present classname=javax.xml.transform.Transformer
classpathref=libs-build-classpath/
available property=jdk14.present classname=java.lang.CharSequence/
/target
@@ -539,7 +543,9 @@
debug=${debug}
deprecation=${deprecation}
optimize=${optimize}
- excludes=**/*${ignore_this},${jimi}/
+ excludes=**/*${ignore_this},${jimi}
+ classpath refid=libs-build-classpath/
+/javac
/target
!-- === --
@@ -553,7 +559,7 @@
/path
taskdef name=serHyph
classname=org.apache.fop.tools.anttasks.SerializeHyphPattern
classpathref=hyph-classpath/
serHyph includes=*.xml
- sourceDir=./hyph
+ sourceDir=${hyph.dir}
targetDir=${build.dest}/hyph /
/target
1.15.2.13 +1 -7 xml-fop/build.sh
Index: build.sh
===
RCS file: /home/cvs/xml-fop/build.sh,v
retrieving revision 1.15.2.12
retrieving revision 1.15.2.13
diff -u -r1.15.2.12 -r1.15.2.13
--- build.sh 18 Nov 2002 14:37:45 - 1.15.2.12
+++
cvs commit: xml-fop CHANGES
jeremias2002/11/19 05:57:47 Modified:.Tag: fop-0_20_2-maintain CHANGES Log: Update changes Revision ChangesPath No revision No revision 1.10.2.28 +9 -6 xml-fop/CHANGES Index: CHANGES === RCS file: /home/cvs/xml-fop/CHANGES,v retrieving revision 1.10.2.27 retrieving revision 1.10.2.28 diff -u -r1.10.2.27 -r1.10.2.28 --- CHANGES 18 Nov 2002 14:37:44 - 1.10.2.27 +++ CHANGES 19 Nov 2002 13:57:47 - 1.10.2.28 @@ -1,29 +1,32 @@ == Done since 0.20.4 release +- Update to Xerces 2.2.1 (Jeremias Maerki) +- Fixed EOFException in TTFReader (Bug #14576) + Submitted by: Bernard D'Have [EMAIL PROTECTED] - Added support for CCITT Group 4 encoded TIFF files Made JAI support dynamic (no recompile needed anymore) Submitted by: Manuel Mall [EMAIL PROTECTED] (see bug #13866) - Fixed problem with jpegs with icc profile and acrobat reader 5 (Bug #11301) Submitted by: Stephan Neuhaus [EMAIL PROTECTED] -- Fix bug in LinkSet.mergeLinks() (ArrayOutOfBoundsException when number of +- Fix bug in LinkSet.mergeLinks() (ArrayOutOfBoundsException when number of rects is zero) (Jeremias Maerki) - Removed the necessity for a buildtools.jar (Jeremias Maerki) - Updated several JARs: Ant 1.5.1, Xerces 2.2.0, Xalan 2.4.1 (Jeremias Maerki) - Fixed some multi-threading issues (NPEs) Submitted by: Joachim Unger [EMAIL PROTECTED] - Improved registration of ImageReader implementations (Jeremias Maerki) -- Refactored baseDir stuff. Internally most code has been changed to work on - URLs instead of filenames. The baseDir property is evaluated to a baseURL +- Refactored baseDir stuff. Internally most code has been changed to work on + URLs instead of filenames. The baseDir property is evaluated to a baseURL which can be accessed through Configuration.getBaseURL() (Jeremias Maerki) -- Added a fontBaseDir property (similar to baseDir) which represents a base - dir/URL for fonts. If this property isn't set, a fallback is made to +- Added a fontBaseDir property (similar to baseDir) which represents a base + dir/URL for fonts. If this property isn't set, a fallback is made to baseDir. (Jeremias Maerki) - Fixed some javadoc warnings Submitted by: Victor Mote [EMAIL PROTECTED] - Added translation for GoToPageDialog and update for czech translations Submitted by: Michal Buchtik [EMAIL PROTECTED] -- background properties for all regions + regions precedence support +- background properties for all regions + regions precedence support (Oleg Tkachenko) - TXTRenderer output encoding (Oleg Tkachenko) - border-spacing support (Oleg Tkachenko) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14679] New: - Pluggable renderers
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=14679. 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=14679 Pluggable renderers Summary: Pluggable renderers Product: Fop Version: all Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Playing around with gcj the other day, I noticed fop is not gcj-compatible (yet) due to its AWT renderer that requires swing classes. Not having studied the redesign code in detail, I'd like to propose (if not already part of the master plan) to source out the renderers in small modules so that not only limitations in the Java VM can be avoided :-) but also to follow the KISS principle when your use case only requires PDF (or RTF or ...) output. Another idea (from a ./configure make install background) would be to have options --enable-pdf, --enable-ps, --enable-rtf Co. to the build process that determine which renderers are to be included. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
Keiron Liddle wrote: On Sat, 2002-11-16 at 09:21, Rhett Aultman wrote: It seems to me that there are (at least) two approaches: 1. A leaf on the tree says I am here, put me somewhere on a page, or 2. A higher-level node (page-sequence) says I have some space here, send me something to fill it. 3. 1 + 2. Thinking that you can do 1. in isolation is, well, brain-dead. On the other hand, how does 2. handle auto table layout? The columns cannot be dimensioned at the very top until the last information about requirements is in from the very bottom. Then the decision is taken at the top, and percolates all the way back down again. I agree that there's a combination of both approaches are necessary, but I'm not sure how 1 handles auto table layout all that much better. I did just wake up over an on-call issue, so maybe it's grogginess, but wouldn't auto-layout either way require reading the whole table first to divine column widths? I will concede that, under option 2, it's not clear if the table will fit in the proffered space until after the entire table is processed, meaning that a purely 2 system is doing a LOT of looking ahead, just to keep up with itself. Is this the handicap of the second option you're referring to? Under the first option, the table can take care of itself, then demand to be placed somewhere, which has the benefit of less looking down the road but the deficit that there may not be room for it anywhere. What if, instead, two passes were taken? The first pass would be for trying to find space for all of the objects with hard-and-fast space and size needs, and then the second pass would place objects that are more malleable. By taking two passes, it'd be possible to first divine the size of auto-layout tables, for example. Like I said...it's late and I was roused from bed, so I may have not really thought about this as much as I should, but this is brainstorming... If possible I think we should try to avoid making multiple passes since it can lead to loops etc. The table layout auto will need at least two passes but this should be possible using the layout managers. Is that a should be or an is? Given your recent concerns about the rapidly increasing complexity of your design, do you have a feasible solution for auto layout? Multiple passes - in some sense - are unavoidable. This is most obvious in the case of auto layout, as described in the CSS documentation which is the actual reference for this stuff. The general concept of layout managers is that a layout manager deals with the breaks that the child layout managers create. So that it can group together breaks when there is a keep together and only return one break to the parent LM which is allowed against the keeps. This can then be extended to the situation where it needs to break within that keep, it will return the best available break. The parent can then deal with it appropriately. I think the idea is sound but there are some implementation questions about dealing with keep with previous and other situations. Now the real problems. What happens for footnotes. A footnote takes space from the main reference area. So we need some way of calculating the remaining space given a potential footnote and the inline area (or line) that adds the footnote. Do we pass the information all the way to the top and then get an answer or is there some other way that the calculation can be achieved where it is needed. Before you say thats simple, just subtract it from the body bpd, well what happens if the footnote is inside a page column. The height that the columns require needs to be calculated by balancing the columns with the currently available areas, then you find the space remaining with the footnote. There are alos situations where the footnote is added where the whole block must be added. Then it must wait until the block is complete before saying if the block and footnote can fit. Sometimes it needs to make a calculation with an abritrary ancestor other times it needs to hold until another ancestor finds a valid break before know if it will fit. You have, of course, read my notes on this topic. If, by some mischance, you have not, you'll find them in the alt.design section of the web page. When you get around to migrating it to forrest, that is. When is that likely to be, by the way? So how do we deal with all these things without making it really slow and complicated. I would suggest just getting it working. If that ever happens, 1) I will be pleasantly surprised 2) you can then worry about making it faster. If it doesn't happen, then, when I have finished my work on properties, I will design and implement the layout engine, and it *will* work. Before then, however, the whole exercise may have been rendered academic by Sun. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go?
Re: Sun xsl formatter being donated to open source
Keiron Liddle wrote: On Tue, 2002-11-19 at 09:18, Oleg Tkachenko wrote: Hello there! Nikolai Grigoriev discovered new xsl formatter becoming open source ;) http://www.xmlconference.org/xmlusa/2002/thursday.asp#vp5 Comments? Does anybody plan to participate xml 2002? Some people even suggest it's Apache where Sun want to donate it to. So why would they do it in that order. Why not donate resources to develop. I haven't heard anything so we'll see what happens. None of us have. But Tony lurks on this list, so he should be able to tell us. I must say that if Sun have been working on this for some time, with the intention of going OS, I am going to be very pissed off with them for not announcing it earlier. On the other hand, there may have been a bunfight within Sun about whether or not to release the source, in which case some folks at Sun should be congratulated. Are you there, Tony? Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Xerces 2.2.1
Jeremias, I'm glad to see that you have upgraded Xerces to 2.2.1. I just discovered that 2.2.0 was badly broken when my code fell over after I had upgraded to that release. Unfortunately I had also made a number of code changes at the same time (bad practice), so it took a while to work out what was going on. This may fix some problems that have been attributed to Xalan. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Sun xsl formatter being donated to open source
Keiron Liddle wrote: On Tue, 2002-11-19 at 09:18, Oleg Tkachenko wrote: Hello there! Nikolai Grigoriev discovered new xsl formatter becoming open source ;) http://www.xmlconference.org/xmlusa/2002/thursday.asp#vp5 Comments? Does anybody plan to participate xml 2002? Some people even suggest it's Apache where Sun want to donate it to. So why would they do it in that order. Why not donate resources to develop. I haven't heard anything so we'll see what happens. I spoke with Tony Graham of Sun, who will be speaking on this at XML 2002. He said he was not at liberty to discuss it all in advance of the conference--apparently they are working out the final legal details of the release or something to that effect. Cheers, Eliot -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Xerces 2.2.1
Hi Peter I should have done that earlier because about at the same time I updated to Xerces 2.2.0, Xerces 2.2.1 was published and I knew it was a bugfix release. On 19.11.2002 15:18:45 Peter B. West wrote: I'm glad to see that you have upgraded Xerces to 2.2.1. I just discovered that 2.2.0 was badly broken when my code fell over after I had upgraded to that release. Unfortunately I had also made a number of code changes at the same time (bad practice), so it took a while to work out what was going on. This may fix some problems that have been attributed to Xalan. Which, if I may ask? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
On Tue, 2002-11-19 at 15:07, Peter B. West wrote: If possible I think we should try to avoid making multiple passes since it can lead to loops etc. The table layout auto will need at least two passes but this should be possible using the layout managers. Is that a should be or an is? Given your recent concerns about the rapidly increasing complexity of your design, do you have a feasible solution for auto layout? There is no is until it starts working, I haven't tried to do it yet. You have, of course, read my notes on this topic. If, by some mischance, you have not, you'll find them in the alt.design section of the web page. When you get around to migrating it to forrest, that is. When is that likely to be, by the way? Yes I have read it, but it doesn't exactly explain the specifics. Also doing certain things for each line area, yes it could work, no I don't like the possible results. Well there is no one stopping you from migrating them. So how do we deal with all these things without making it really slow and complicated. I would suggest just getting it working. If that ever happens, 1) I will be pleasantly surprised 2) you can then worry about making it faster. I could just do it, special cases can use special techniques provided it doesn't effect normal cases too much. If it doesn't happen, then, when I have finished my work on properties, I will design and implement the layout engine, and it *will* work. Before then, however, the whole exercise may have been rendered academic by Sun. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Sample FO Documents
As I mentioned in another forum, I have a fairly comprehensive set of samples, both contrived and realistic, that are available to any implemmentors. I'd be happy to provide these to the FOP team--just let me know who to send them to or where to upload them. These have been developed both as demos of using FO to do multi-language composition of technical manuals and as samples in service of a new FO course we're developing. The downside for FOP is that these examples were developed initially using XSL Formatter, which is the most feature complete implementation. That means that the samples and demos have not been tailored to work w/in FOP's current limitations. Cheers, Eliot -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
Keiron Liddle wrote: On Tue, 2002-11-19 at 15:07, Peter B. West wrote: If possible I think we should try to avoid making multiple passes since it can lead to loops etc. The table layout auto will need at least two passes but this should be possible using the layout managers. Is that a should be or an is? Given your recent concerns about the rapidly increasing complexity of your design, do you have a feasible solution for auto layout? There is no is until it starts working, I haven't tried to do it yet. There is no possible when it starts working. You have, of course, read my notes on this topic. If, by some mischance, you have not, you'll find them in the alt.design section of the web page. When you get around to migrating it to forrest, that is. When is that likely to be, by the way? Yes I have read it, but it doesn't exactly explain the specifics. Also doing certain things for each line area, yes it could work, no I don't like the possible results. Well there is no one stopping you from migrating them. You broke it; you fix it. So how do we deal with all these things without making it really slow and complicated. I would suggest just getting it working. If that ever happens, 1) I will be pleasantly surprised 2) you can then worry about making it faster. I could just do it, special cases can use special techniques provided it doesn't effect normal cases too much. In my view, and here we differ, auto layout is not a special case. It is the litmus test of the design. I believe that the design can and should be such that the easy cases are special, simplified, cases of the general solution. If it doesn't happen, then, when I have finished my work on properties, I will design and implement the layout engine, and it *will* work. Before then, however, the whole exercise may have been rendered academic by Sun. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
Respone below. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 5:06 AM To: FOP Subject: RE: Getting breaks: revisited On Sat, 2002-11-16 at 09:21, Rhett Aultman wrote: What if, instead, two passes were taken? The first pass would be for trying to find space for all of the objects with hard-and-fast space and size needs, and then the second pass would place objects that are more malleable. By taking two passes, it'd be possible to first divine the size of auto-layout tables, for example. Like I said...it's late and I was roused from bed, so I may have not really thought about this as much as I should, but this is brainstorming... If possible I think we should try to avoid making multiple passes since it can lead to loops etc. The table layout auto will need at least two passes but this should be possible using the layout managers. I'm not sure how writing the thing to make two passes is more loop prone than making one pass, especially if each pass performs a different function. For example, what if the first pass was designed only to gather information about the proposed layout options and the second pass was the actual process of layout, getting the opportunity to make its decisions from on high with total knowlege? The general concept of layout managers is that a layout manager deals with the breaks that the child layout managers create. So that it can group together breaks when there is a keep together and only return one break to the parent LM which is allowed against the keeps. Yes, and I think that the system works pretty well for a lot of situations. I'm not suggesting that it get chucked to the weeds. A question this begs, though, is that is this design going to take us the whole way through? In your own email here you bring up two cases where a LM's decisions have to be dependant upon more than just its own children. What happens for footnotes. A footnote takes space from the main reference area. So we need some way of calculating the remaining space given a potential footnote and the inline area (or line) that adds the footnote. Do we pass the information all the way to the top and then get an answer or is there some other way that the calculation can be achieved where it is needed. Before you say thats simple, just subtract it from the body bpd, well what happens if the footnote is inside a page column. The height that the columns require needs to be calculated by balancing the columns with the currently available areas, then you find the space remaining with the footnote. This is what I meant, too, when I said that there are cases where the concern does not behave in perfect, unidirectional tree-like fashion, which tells me that there's design considerations to make, and maybe going outside of the box and thinking of the current tree of LMs as one part of the solution is indicated. So how do we deal with all these things without making it really slow and complicated. Keeping it from getting complicated is definitely important, but I'm willing to accept slow in the name of also getting correct. Also, this may seem like an issue only to me, but I our next layout system must be free of infinite loops. It is essential that enterprise users know their Tomcat or jBoss servers are not going to have to be restarted if some guy makes a screwup in his Servlet or MBean and accidentally triggers a special case in FOP that leads to a layout loop. A process for recognizing when a constraint must be lifted in order to ensure the document processes is necessary, and I think it was Victor (though maybe Peter...) who pointed out that such a process leads to another problem- if you lift a constraint in one place, you have effects on the layout of the entire document, too. In order to handle this problem, the entire layout system needs the ability to not only spot the issue but to select the best resolution for it and then layout according to that decision. I've spent a lot of mental energy over the last several days trying to come up with a solution, and the only one I've come up with thus far involves creating a tree of alternative layout choices. For an ideal document, there really isn't a tree. For less-than-ideal ones, there would be a branch of the tree at every place a violation occurs, and there decisions would branch off with possibilities of how to resolve the problem. If a decision creates even more woes, its branch would get deeper and deeper. Finding the ideal set of choices to make in resolving an issue then becomes a matter of simply finding the shortest branch in a tree. This is, in many ways, in parallel with the LayoutPlan approach previously mentioned. But, to do this, they layout system needs to start out with a certain base set of knowlege about the layout of the document, and to me this implies that multiple passes are needed. Maybe only one final layout pass
RE: Getting breaks: revisited
Response below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Getting breaks: revisited Keiron Liddle wrote: I could just do it, special cases can use special techniques provided it doesn't effect normal cases too much. In my view, and here we differ, auto layout is not a special case. It is the litmus test of the design. I believe that the design can and should be such that the easy cases are special, simplified, cases of the general solution. I would have to agree. If fighting complexity is the concern, the special techniques for special cases code must be kept to an absolute minimum. Special case code pretty much generates complexity on its own. Something like auto layout of tables should be treated as part of the general layout solution, if for no reason other than the fact that nearly everyone who makes a table in FO is going to want to use auto layout (or, in the case of newcomers, defaults to it). If table auto layout seems to be falling under the heading of special case under the current design, it may be a clue that the design needs to be rethought. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3430] - Running Head Missing Line at the first 3 pages
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=3430. 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=3430 Running Head Missing Line at the first 3 pages [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 16:09 --- Looks fine using 0.20.4, even last forced page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14657] - [PATCH] Awt measuring/rendering problems
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=14657. 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=14657 [PATCH] Awt measuring/rendering problems [EMAIL PROTECTED] changed: What|Removed |Added Summary|[PATCH] Awt |[PATCH] Awt |measuring/rendering problems|measuring/rendering problems --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 16:22 --- Ralph, could you please add the patch as attachment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11709] - NullPointerException from PDFXObject.output()
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=11709. 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=11709 NullPointerException from PDFXObject.output() [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 16:29 --- Which fop version are you talking about? Anyway, thread-safe problems fixed already in cvs. Try cvs version (or just wait few days till 0.20.5 is out) and if it doesn't help, feel free to reopen the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13450] - FOP0.20.4 embedded rendering throws exception
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=13450. 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=13450 FOP0.20.4 embedded rendering throws exception --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 16:46 --- Well, Batik is upgraded up to 1.5b4, does it help? Jeremias, if you still have example FO file, check it out if it works now, please. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
rendering SVG Graphic exported from staroffice 6
Hello, I tried to include some svg graphics with fo:external-graphic src=circle.svg/ If I use Mayura Draw for drawing, there are no problems, but if I make a simple drawing with staroffice 6.0 and export it to SVG I have no success. I can view this file in Adobe SVG Viewer, I can transcode it with batik 1.5 to png, but I have no success with this file in fop. The Staroffice files differ from the mayura files in there coordinate system, maybe this is a problem: --- ?xml version=1.0 encoding=UTF-8? !DOCTYPE svg PUBLIC -//W3C//DTD SVG 1.0//EN http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd; svg width=46mm height=38mm viewBox=0 0 4600 3800 g style=stroke:rgb(0,0,0);fill:none polyline points=2383,3252 2011,3202 1678,3061 1395,2842 1176,2559 1035,2226 986,1855 1035,1483 1176,1150 1395,867 1678,648 2011,507 2383,458 2754,507 3087,648 3370,867 3589,1150 3730,1483 3780,1855 3730,2226 3589,2559 3370,2842 3087,3061 2754,3202 2383,3252 style=fill:none/ /g /svg --- Maybe somebody has a tip! Regards, Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10941] - Memory leaks when using dynamic images
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=10941. 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=10941 Memory leaks when using dynamic images [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 17:03 --- *** This bug has been marked as a duplicate of 8003 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14657] - [PATCH] Awt measuring/rendering problems
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=14657. 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=14657 [PATCH] Awt measuring/rendering problems --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 17:15 --- Created an attachment (id=3893) patch as requested - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14659] - spurious (nuisance) errors on print/awt renderers
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=14659. 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=14659 spurious (nuisance) errors on print/awt renderers --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 17:23 --- Created an attachment (id=3896) patch added as attachement (now that lf's are fixed in PrintStarter.java) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14659] - spurious (nuisance) errors on print/awt renderers
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=14659. 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=14659 spurious (nuisance) errors on print/awt renderers --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 17:24 --- Now that LF's are fixed in PrintStarter, I resubmitted patches to both sources as an attachment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 839] - Positioning of blocks in a block section.
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=839. 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=839 Positioning of blocks in a block section. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Priority||High Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 17:40 --- fo:block doesn't have absolute position properties and relative positioning is not implemented yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6178] - Color palette of .bmp files with 1 bit/pixel not used
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=6178. 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=6178 Color palette of .bmp files with 1 bit/pixel not used --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 17:50 --- Could you please provide a small example of such bml image? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6230] - true type embedded fonts cannot be extracted from acrobat reader
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=6230. 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=6230 true type embedded fonts cannot be extracted from acrobat reader --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 17:55 --- font metrics-file=Uvcl.xml kerning=yes embed-file=Uvcl.ttf This line looks dubious to me. If you are trying to embed Type1 fomt, what is that Uvcl.ttf file? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] changes to bugs.xml doc
Keiron Liddle wrote: Still having some trouble with diffs, it might be something to do with downloading via IE. Thanks for pointing this out -- I didn't realize there was a problem. I do use IE to upload the attachments through Bugzilla. Do you think that is the source of the problem? Also, since I don't see it, I don't know what problem you are seeing. Is it best practice to use a different browser? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6238] - Error when opening pdf in acrobat reader
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=6238. 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=6238 Error when opening pdf in acrobat reader [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 18:02 --- Probably broken font file, try another one or send it to me privately and I'll check it out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6230] - true type embedded fonts cannot be extracted from acrobat reader
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=6230. 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=6230 true type embedded fonts cannot be extracted from acrobat reader --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 18:31 --- I just followed the instruction from http://xml.apache.org/fop/fonts.html : Register the fonts within FOP Edit conf/userconfig.xml and add entries for the font if the fonts section, ie: font metrics-file=cyberbit.xml kerning=yes embed- file=C:\WINNT\Fonts\Cyberbit.ttf font-triplet name=Cyberbit style=normal weight=normal /font This also uses a ttf file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6230] - true type embedded fonts cannot be extracted from acrobat reader
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=6230. 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=6230 true type embedded fonts cannot be extracted from acrobat reader [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 18:48 --- Probably the instruction is not so clear. The example is about TrueType font as can be seen from .ttf extension. You should use original pfb file to embedding. Try font metrics-file=Uvcl.xml kerning=yes embed-file=Uvcl.pfb font-triplet name=Univers-CondensedLight style=normal weight=normal/ /font - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5917] - table defined as footenote doesnt appear if body text is too long
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=5917. 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=5917 table defined as footenote doesnt appear if body text is too long [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 18:51 --- *** This bug has been marked as a duplicate of 8819 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8819] - Footnotes lost
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=8819. 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=8819 Footnotes lost [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 18:51 --- *** Bug 5917 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12809] - footnote coming at the bottom page
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=12809. 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=12809 footnote coming at the bottom page --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 18:56 --- Cannot reproduce the problem, probably because I don't have NewBaskerville font. provide an example with no special font definition, please. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Xerces 2.2.1
It's me. It is bug 14539 in Bugzilla. It's just that in you have a comment before the root element, the SAX startDocument is called two times. Bernard -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: 19 November, 2002 15:44 To: [EMAIL PROTECTED] Subject: Re: Xerces 2.2.1 Jeremias Maerki wrote: Hi Peter I should have done that earlier because about at the same time I updated to Xerces 2.2.0, Xerces 2.2.1 was published and I knew it was a bugfix release. On 19.11.2002 15:18:45 Peter B. West wrote: I'm glad to see that you have upgraded Xerces to 2.2.1. I just discovered that 2.2.0 was badly broken when my code fell over after I had upgraded to that release. Unfortunately I had also made a number of code changes at the same time (bad practice), so it took a while to work out what was going on. This may fix some problems that have been attributed to Xalan. Which, if I may ask? Nothing in particular. I just remembered that someone recently posted a bug report to Xalan. Bugs in Xerces could well have ramifications for Xalan. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Xerces 2.2.1
So, could you check if the problem persist when using a Xerces 2.2.1? Thanks. On 19.11.2002 20:10:30 Bernard D'Have wrote: It's me. It is bug 14539 in Bugzilla. It's just that in you have a comment before the root element, the SAX startDocument is called two times. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Xerces 2.2.1
I'll check this tomorrow at work. Bernard -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: 19 November, 2002 20:28 To: [EMAIL PROTECTED] Subject: Re: Xerces 2.2.1 So, could you check if the problem persist when using a Xerces 2.2.1? Thanks. On 19.11.2002 20:10:30 Bernard D'Have wrote: It's me. It is bug 14539 in Bugzilla. It's just that in you have a comment before the root element, the SAX startDocument is called two times. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14290] - strokeSVGText=false causes space characters to be rendered incorrectly
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=14290. 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=14290 strokeSVGText=false causes space characters to be rendered incorrectly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 22:16 --- I have found the problem and think I have a fix. The 'loca' table we write in the PDF for the font subset is not correct. Just want to run it by Jeremias or other font expert before committing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
Hi all (and especially Jeremias or other font experts),
This bug seems to be due to the way we generate the 'loca' table in the
embedded font subsets (CID fonts). In fact, it has offsets to the
correct glyph descriptions, but the offsets are not in ascending order.
Since it seems that the length of the glyph description is found by
subtracting the offset to the glyph from the offset for the next glyph
in the loca table, this does not work. For Acrobat, as long as there
actually _is_ a glyph description, it seems to work anyway. However for
space characters, there is no glyph. Acrobat thinks there is because of
the offset, so it draws the glyph that _is_ stored at the offset.
This only shows up with SVG text because it has embedded spaces. The
spaces in normal text are generally turned into explicit offsets and not
drawn as such.
The attached diff fixes the bug; though there are perhaps more elegant
ways to do it. Does anyone see anything wrong with this idea?
If not, I'll commit asap.
In fact, using this fix, xpdf now also works with embedded fonts,
whereas before it produced garbage.
Regards,
Karen Lease
(Lately very overworked) Senior Software Developer
SPX Valley Forge
Paris/Munich
Index: org/apache/fop/fonts/TTFSubSetFile.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fonts/TTFSubSetFile.java,v
retrieving revision 1.5.2.2
diff -u -r1.5.2.2 TTFSubSetFile.java
--- org/apache/fop/fonts/TTFSubSetFile.java 8 Nov 2002 10:25:26 - 1.5.2.2
+++ org/apache/fop/fonts/TTFSubSetFile.java 19 Nov 2002 22:29:00 -
@@ -311,29 +311,35 @@
pad4();
start = currentPos;
+int[] offsets = new int[glyphs.size()];
+
for (Iterator e = glyphs.keySet().iterator(); e.hasNext(); ) {
-int glyphLength = 0;
Integer origIndex = (Integer)e.next();
Integer subsetIndex = (Integer)glyphs.get(origIndex);
+offsets[subsetIndex.intValue()] = origIndex.intValue();
+}
+for (int i=0;ioffsets.length;i++) {
+int glyphLength = 0;
int nextOffset = 0;
-if (origIndex.intValue() = (mtx_tab.length - 1))
+int origGlyphIndex = offsets[i];
+if (origGlyphIndex = (mtx_tab.length - 1))
nextOffset = (int)lastLoca;
else
nextOffset =
-(int)mtx_tab[origIndex.intValue() + 1].offset;
+(int)mtx_tab[origGlyphIndex + 1].offset;
glyphLength = nextOffset
- - (int)mtx_tab[origIndex.intValue()].offset;
+ - (int)mtx_tab[origGlyphIndex].offset;
// Copy glyph
-System.arraycopy(in.getBytes((int)entry.offset +
(int)mtx_tab[origIndex.intValue()].offset, glyphLength),
+System.arraycopy(in.getBytes((int)entry.offset +
+ (int)mtx_tab[origGlyphIndex].offset,
+glyphLength),
0, output, currentPos, glyphLength);
// Update loca table
-writeULong(locaOffset + subsetIndex.intValue() * 4,
- currentPos - start);
+writeULong(locaOffset + i * 4, currentPos - start);
if ((currentPos - start + glyphLength) endOffset)
endOffset = (currentPos - start + glyphLength);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: basic-link brocken (maintenance branch)
Hi guys, If the problem is that the link rectangles are now merged by default, I am the one that changed it. There was a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9335 and I was doing a bunch of improvements to the positioning of the link rectangles. However, in this case, all I did was change the default merge behavior to yes. Is there something else broken? Regards, Karen Jeremias Maerki wrote: I fixed a bug there, but this obviously brought another. I'll have a look at it. On Wed, 13 Nov 2002 12:17:59 +0100 Christian Geisert wrote: Hi, I just discoverd that basic-link isn't working as expected in the maintenance branch (docs/example/fo/links.fo for example) It seems that mergelinks() is the problem so I'll change the default links.merge to no if there are no objections. (IIRC there has been some discussion about this but a quick search on the mailing list did not find anything) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Extension to write continued label in table headers
A while back, if I remember correctly, someone was looking for and perhaps going to write an extension to write continued labels in table headers. Ie, when the table continues, to add text like (continued) or whatever in the header (and/or footer). Apparently this never made it into the common pool, but I have recently cooked up something fairly simple (and limited) to handle this. Is there interest in putting it in for the next maintenance release ? It has very minor impact on the table layout code and probably would be useful to a number of people. Regards, Karen Lease Senior Software Developer SPX Valley Forge Paris/Munich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Extension to write continued label in table headers
Karen Lease wrote: A while back, if I remember correctly, someone was looking for and perhaps going to write an extension to write continued labels in table headers. Ie, when the table continues, to add text like (continued) or whatever in the header (and/or footer). Just yesterday there was one more such a question at fop-user. Apparently this never made it into the common pool, but I have recently cooked up something fairly simple (and limited) to handle this. Is there interest in putting it in for the next maintenance release ? It has very minor impact on the table layout code and probably would be useful to a number of people. +1, it would be great, how does semantics look like? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Xerces 2.2.1
Bernard, Ah, memory! Wonderful thing when it works. I must remember to read Proust again. I wanted to talk to you about this. I haven't yet followed up on your fix to this, so I am not sure how you handle it, but wouldn't the variable and the process be better as startDocumentAlreadySeen? Then you can skip the whole STARTDOCUMENT handler if the variable is true. Have you tried the original code with 2.2.1? Peter Bernard D'Have wrote: It's me. It is bug 14539 in Bugzilla. It's just that in you have a comment before the root element, the SAX startDocument is called two times. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12809] - footnote coming at the bottom page
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=12809. 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=12809 footnote coming at the bottom page --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 05:02 --- Hi Oleg, I have made modifcation in the fo file, and the following file is generating the same errors. Thanks Narinder ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:fox=http://xml.apache.org/fop/extensions; fo:layout-master-set fo:simple-page-master master-name=halftitlePage page-height=612pt page- width=396pt margin-bottom=79pt margin-left=48pt margin-right=48pt margin-top=138pt fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=halftitlePage format=1 initial-page- number=1 fo:flow flow-name=xsl-region-body fo:block id=IDA1ZSPB hyphenate=true hyphenation-push-character- count=2 hyphenation-remain-character-count=3 language=en fo:block id=pg1/ fo:block font-size=13pt line-height=17pt text-align=justify text- indent=17pt fo:inline id=pg6/ pamphleteer, had taken strong ground against the measures of the British Government injurious to American commerce, wrote as follows in 1808 about the practice of seizing British subjects in American ships: That we, the people of America, should engage in ruinous warfare to support a rash opinion, that foreign sailors in our merchant ships are to be protected against the power of their sovereign, is downright madness. Why not, he wrote again in 1813, while the war was raging, waiving flippant debate, lay down the broad principle of national right, on which Great Britain takes her native seamen from our merchant ships? Let those who deny the right pay, suffer, and fight, to compel an abandonment of the claim. Men of sound mind will see, and men of sound principle will acknowledge, its existence. In his opinion, there was but one consistent course to be pursued by those who favored the war with Great Britain, which was to insist that she should, without compensation, surrender her claim. If that ground be taken, he wrote, the war [on our part] will be confessedly, as it is now impliedly, unjust. Morris was a man honorably distinguished in our troubled nationalfo:footnote fo:inline font-size=11pt line-height=13.75pt fo:basic-link internal-destination=chap1.6.44/fo:basic-link /fo:inline fo:footnote-body fo:block text-align=justify font-size=11pt line- height=13.75pt id=chap1.6.4 padding-before=0.75pt * 3 text-indent=0pt start-indent=0pt fo:inline4/fo:inline. Annals of Congress. Thirteenth Congress, vol. ii. pp. fo:inline fo:basic-link internal-destination=pg1563 fo:page-number-citation ref-id=pg1563/ /fo:basic-link /fo:inline; fo:inline1555 1558/fo:inline./fo:block /fo:footnote-body /fo:footnote fo:inline/fo:inlinezation /fo:block /fo:block /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] changes to bugs.xml doc
On Tue, 2002-11-19 at 18:59, Victor Mote wrote: Keiron Liddle wrote: Still having some trouble with diffs, it might be something to do with downloading via IE. Thanks for pointing this out -- I didn't realize there was a problem. I do use IE to upload the attachments through Bugzilla. Do you think that is the source of the problem? Also, since I don't see it, I don't know what problem you are seeing. Is it best practice to use a different browser? I'm not really sure what is the source of the problem. A few of the patches had hunks failing and some worked with fuzz offsets. One error meesage I got was that it couldn't find the character on line 9, so I went to line 9 and found the character, of course it was really looking for . Maybe archiving the patch might work better. Anyway there are better ways of solving this problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: rendering SVG Graphic exported from staroffice 6
The problem is with the viewBox, this is not implemented properly in the releases. It has been implemented in cvs however. Why don't you use a circle to draw a circle? On Tue, 2002-11-19 at 18:35, [EMAIL PROTECTED] wrote: Hello, I tried to include some svg graphics with fo:external-graphic src=circle.svg/ If I use Mayura Draw for drawing, there are no problems, but if I make a simple drawing with staroffice 6.0 and export it to SVG I have no success. I can view this file in Adobe SVG Viewer, I can transcode it with batik 1.5 to png, but I have no success with this file in fop. The Staroffice files differ from the mayura files in there coordinate system, maybe this is a problem: --- ?xml version=1.0 encoding=UTF-8? !DOCTYPE svg PUBLIC -//W3C//DTD SVG 1.0//EN http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd; svg width=46mm height=38mm viewBox=0 0 4600 3800 g style=stroke:rgb(0,0,0);fill:none polyline points=2383,3252 2011,3202 1678,3061 1395,2842 1176,2559 1035,2226 986,1855 1035,1483 1176,1150 1395,867 1678,648 2011,507 2383,458 2754,507 3087,648 3370,867 3589,1150 3730,1483 3780,1855 3730,2226 3589,2559 3370,2842 3087,3061 2754,3202 2383,3252 style=fill:none/ /g /svg --- Maybe somebody has a tip! Regards, Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/render/pdf PDFRenderer.java
keiron 2002/11/19 23:51:35
Modified:src/org/apache/fop/pdf PDFDocument.java PDFInfo.java
src/org/apache/fop/render AbstractRenderer.java
Renderer.java
src/org/apache/fop/render/pdf PDFRenderer.java
Log:
enable setting creator
Revision ChangesPath
1.58 +10 -1 xml-fop/src/org/apache/fop/pdf/PDFDocument.java
Index: PDFDocument.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/pdf/PDFDocument.java,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- PDFDocument.java 11 Nov 2002 08:50:50 - 1.57
+++ PDFDocument.java 20 Nov 2002 07:51:34 - 1.58
@@ -193,6 +193,15 @@
}
/**
+ * set the creator of the document
+ *
+ * @param creator string indicating application creating the document
+ */
+public void setCreator(String creator) {
+this.info.setCreator(creator);
+}
+
+/**
* Set the filter map to use for filters in this document.
*
* @param map the map of filter lists for each stream type
1.10 +14 -1 xml-fop/src/org/apache/fop/pdf/PDFInfo.java
Index: PDFInfo.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/pdf/PDFInfo.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- PDFInfo.java 25 Oct 2002 09:29:46 - 1.9
+++ PDFInfo.java 20 Nov 2002 07:51:35 - 1.10
@@ -47,6 +47,15 @@
this.producer = producer;
}
+/**
+ * set the creator string
+ *
+ * @param creator the document creator
+ */
+public void setCreator(String creator) {
+this.creator = creator;
+}
+
public void setTitle(String t) {
this.title = t;
}
@@ -82,6 +91,10 @@
}
if (keywords != null) {
p += /Keywords ( + this.keywords + )\n;
+}
+
+if (creator != null) {
+p += /Creator ( + this.creator + )\n;
}
p += /Producer ( + this.producer + )\n;
1.29 +8 -1 xml-fop/src/org/apache/fop/render/AbstractRenderer.java
Index: AbstractRenderer.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/AbstractRenderer.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- AbstractRenderer.java 6 Nov 2002 15:36:29 - 1.28
+++ AbstractRenderer.java 20 Nov 2002 07:51:35 - 1.29
@@ -95,6 +95,13 @@
*/
protected int containingIPPosition = 0;
+/** @see org.apache.fop.render.Renderer */
+public void setProducer(String producer) {
+}
+
+/** @see org.apache.fop.render.Renderer */
+public void setCreator(String creator) {
+}
/** @see org.apache.fop.render.Renderer */
public void setUserAgent(FOUserAgent agent) {
1.29 +15 -1 xml-fop/src/org/apache/fop/render/Renderer.java
Index: Renderer.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/Renderer.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- Renderer.java 9 Sep 2002 10:54:52 - 1.28
+++ Renderer.java 20 Nov 2002 07:51:35 - 1.29
@@ -47,6 +47,9 @@
/**
* Initiates the rendering phase.
+ * This must only be called once for a rendering. If
+ * stopRenderer is called then this may be called again
+ * for a new document rendering.
*
* @param outputStream The OutputStream to use for output
* @exception IOException If an I/O error occurs
@@ -56,6 +59,8 @@
/**
* Signals the end of the rendering phase.
+ * The renderer should reset to an initial state and dispose of
+ * any resources for the completed rendering.
*
* @exception IOException If an I/O error occurs
*/
@@ -91,6 +96,15 @@
* embedded in the generated file.
*/
void setProducer(String producer);
+
+/**
+ * Set the creator of the document to be rendered. If this method
+ * isn't called the renderer uses a default.
+ * Note: Not all renderers support this feature.
+ *
+ * @param creator The name of the document creator
+ */
+void setCreator(String creator);
/**
* Reports if out of order rendering is supported. p
1.130 +16 -4 xml-fop/src/org/apache/fop/render/pdf/PDFRenderer.java
Index: PDFRenderer.java
