RE: [PATCH] Support for percentages and table-units
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] snip / The borderline cases may be very much in the minority (and must be, judging by the degree of usage that FOP gets now) but they must be taken into account in the design of the solution. If we go for the low-hanging fruit and then discover that the ladder is too short we end up back in the workshop. I understand, but what I'm referring to is (taking your analogy a bit further): You want an 'extensible' ladder which you can keep short for the low-hanging fruit, and extend to reach the higher ones. If you get to a tiny tree with a huge ladder, you're going to be cursing yourself anyway as your big ladder will make the job more difficult, IYKWIM (--you might not even need that ladder, but still you carried it all the way down there...). The point that would concern me is an API that forces the most trivial and common cases into a processing-model that is actually meant to accommodate rather complicated structures. So you'd end up having an overhead in 95% of the cases, overhead which strictly speaking is meant to occur in only 5% of the possible situations. If it results in (virtually) no overhead at all, this point of course dissolves totally... the ladder is then extensible in just the right way. I wasn't thinking of the buffers. The re-usability of the buffers is only relevant to static-content and markers, so I don't see that as a major issue, and would expect to keep the static-content buffers for a page in memory for the life of the page-sequence. Markers are a bit more problematical, and may well benefit from some transparent serialization. Sorry, I'm still a bit misguided, it seems. This part, I already got, but... I was thinking more of the historical parts of the FO and Area trees. ... putting quotes around there is to beg the question, so, would that be the parts that have already been processed in some way? At one stage I considered linking all nodes in the FO tree with reference objects, but I was concerned about the extra layer of reference objects and their impact on memory and performance. However, when we get parallel FO tree, Area tree and rendering working it may pay dividends. I find the language of the java.lang.ref package confusing, but I think that phantom references open the possibility of performing serialization on demand, when the object is queued for GC. Can you elaborate a bit on this? AFAICT, the actual referent of a phantom reference is itself unreachable through the reference object (the ref's get() method always returns null), so you could indeed test via isEnqueued() whether or not the referent of a phantom reference is queued for GC, and then...? A soft reference at least would allow to get() the object and do something with it or make it do something with itself before actually clearing the ref. Cheers, Andreas
cvs commit: xml-fop/examples/fo/tables background.fo borders.fo break.fo headfoot.fo keep.fo omit.fo space.fo widowsorphans.fo
gmazza 2004/02/22 05:37:07 Modified:examples/fo/advanced barcode.fo cid-fonts.fo giro.fo examples/fo/basic border.fo fonts.fo images.fo link.fo normal.fo normalex.fo pdfoutline.fo examples/fo/footnotes columns.fo simple.fo examples/fo/keeps_and_breaks columnlevel1.fo pagelevel1.fo pagelevel2.fo pagelevel3.fo pagelevel4.fo examples/fo/markers glossary.xsl hide.fo examples/fo/pagination allregions.fo franklin_2pageseqs.fo franklin_alt.fo franklin_rep.fo franklin_rep_max_repeats.fo franklin_rep_max_repeats_expl.fo franklin_rep_max_repeats_nl.fo examples/fo/region_body simplecol2.fo simplecol3.fo simplecol4.fo examples/fo/svg external.fo examples/fo/tables background.fo borders.fo break.fo headfoot.fo keep.fo omit.fo space.fo widowsorphans.fo Log: Formatting cleanup of fo:layout-master-sets in examples. Revision ChangesPath 1.2 +38 -17xml-fop/examples/fo/advanced/barcode.fo Index: barcode.fo === RCS file: /home/cvs/xml-fop/examples/fo/advanced/barcode.fo,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- barcode.fo29 Jan 2003 16:07:15 - 1.1 +++ barcode.fo22 Feb 2004 13:37:06 - 1.2 @@ -1,22 +1,43 @@ ?xml version=1.0 encoding=ISO-8859-1? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; - fo:layout-master-set - fo:simple-page-master page-width=21cm page-height=29.7cm master-name=first margin-top=5mm - fo:region-body margin-bottom=4.5in margin-right=5mm margin-left=5mm margin-top=5mm/ - fo:region-after extent=4in border-top-color=silver border-top-style=dotted border-top-width=0.13mm/ - /fo:simple-page-master - fo:simple-page-master page-width=21cm page-height=29.7cm master-name=rest margin-right=5mm margin-left=5mm margin-top=5mm margin-bottom=5mm - fo:region-body/ - /fo:simple-page-master - fo:page-sequence-master master-name=A4 - fo:repeatable-page-master-alternatives -fo:conditional-page-master-reference master-reference=first page-position=first/ -fo:conditional-page-master-reference master-reference=rest page-position=rest/ -fo:conditional-page-master-reference master-reference=rest/ - /fo:repeatable-page-master-alternatives - /fo:page-sequence-master - /fo:layout-master-set - fo:page-sequence master-reference=A4 + +fo:layout-master-set + fo:simple-page-master master-name=first +page-width=21cm +page-height=29.7cm +margin-top=5mm + fo:region-body +margin-bottom=4.5in +margin-right=5mm +margin-left=5mm +margin-top=5mm/ + fo:region-after +extent=4in +border-top-color=silver +border-top-style=dotted +border-top-width=0.13mm/ + /fo:simple-page-master + + fo:simple-page-master master-name=rest +page-width=21cm +page-height=29.7cm +margin-right=5mm +margin-left=5mm +margin-top=5mm +margin-bottom=5mm + fo:region-body/ + /fo:simple-page-master + + fo:page-sequence-master master-name=A4 + fo:repeatable-page-master-alternatives +fo:conditional-page-master-reference master-reference=first page-position=first/ +fo:conditional-page-master-reference master-reference=rest page-position=rest/ +fo:conditional-page-master-reference master-reference=rest/ + /fo:repeatable-page-master-alternatives + /fo:page-sequence-master +/fo:layout-master-set + +fo:page-sequence master-reference=A4 fo:flow flow-name=xsl-region-body fo:block font-size=14pt font-weight=bold 1.3 +8 -2 xml-fop/examples/fo/advanced/cid-fonts.fo Index: cid-fonts.fo === RCS file: /home/cvs/xml-fop/examples/fo/advanced/cid-fonts.fo,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- cid-fonts.fo 29 Jan 2003 16:07:15 - 1.2 +++ cid-fonts.fo 22 Feb 2004 13:37:06 - 1.3 @@ -5,8 +5,14 @@ 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 page-width=21cm page-height=29.7cm master-name=A4 - fo:region-body margin-bottom=1.5cm margin-right=2cm margin-left=2cm margin-top=1.5cm/ + fo:simple-page-master master-name=A4 +
Web Maestro vs. The Breadcrumb Problem
Clay, I'm *very* happy to see you working on fixing the pesky breadcrumb problem[1] on our website. I'm also seeing that you're bringing yourself up to speed with the usage of Forrest [2], something few (any?) of us have, outside of just being able to edit the XML documents. (This combination of doing work and showing initiative are both valuable traits for this project!) Our website hasn't been updated much since Victor became inactive, and I'm concerned about it getting neglected, falling behind the commercial implementation sites. Anyway, your efforts have certainly been noted and are appreciated. Thanks, Glen [1] http://marc.theaimsgroup.com/?l=forrest-devm=107660215609973w=2 [2] http://marc.theaimsgroup.com/?l=forrest-devm=107714679202746w=2
Bug report for Fop [2004/02/22]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence | | 953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t| | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 1180|New|Maj|2001-04-02|Problem with monospaced font | | 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r| | 1998|New|Nor|2001-06-05|linefeed-treatment not understood | | 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl| | 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row| | 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly | | 2909|New|Maj|2001-07-30|Gradient render error | | 2964|Ass|Nor|2001-08-02|problems with height of cells in tables | | 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-| | 3044|Ass|Maj|2001-08-08|keep-together not functioning | | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body | | 3497|New|Maj|2001-09-07|id already exists error when using span=all attr| | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts | | 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work | | 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D| | 4415|New|Nor|2001-10-25|scaling=uniform does not work on images... | | 4510|New|Nor|2001-10-30|fo:inline common properties ignored? | | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 4767|New|Nor|2001-11-09|SVG text is distored in PDF output| | 5001|New|Nor|2001-11-21|content-width and content-height ignored? | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5047|Ass|Nor|2001-11-23|Dotted border style is not supported | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from | | 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values | | 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop| | 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render | | 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving| | 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label| | 6918|New|Enh|2002-03-06|reference-orientation has no effect | | 6929|New|Nor|2002-03-06|Cells border hidden by cells background | | 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi| | 7140|New|Enh|2002-03-15|page-position attribute set to last on condition| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in | | 7337|New|Nor|2002-03-21|border around external image leaves empty space | | 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page | | 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b| | 7525|New|Cri|2002-03-27|table with spans inside a list-block | | 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8050|New|Nor|2002-04-13|Soft hyphen (shy;) is not handled properly | |
Re: [PATCH] Support for percentages and table-units
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] snip / The borderline cases may be very much in the minority (and must be, judging by the degree of usage that FOP gets now) but they must be taken into account in the design of the solution. If we go for the low-hanging fruit and then discover that the ladder is too short we end up back in the workshop. I understand, but what I'm referring to is (taking your analogy a bit further): You want an 'extensible' ladder which you can keep short for the low-hanging fruit, and extend to reach the higher ones. If you get to a tiny tree with a huge ladder, you're going to be cursing yourself anyway as your big ladder will make the job more difficult, IYKWIM (--you might not even need that ladder, but still you carried it all the way down there...). The point that would concern me is an API that forces the most trivial and common cases into a processing-model that is actually meant to accommodate rather complicated structures. So you'd end up having an overhead in 95% of the cases, overhead which strictly speaking is meant to occur in only 5% of the possible situations. If it results in (virtually) no overhead at all, this point of course dissolves totally... the ladder is then extensible in just the right way. There's a lot of subjective judgement in making such calls, which is why it's useful to have a number of different opinions kicking ideas around. I wasn't thinking of the buffers. The re-usability of the buffers is only relevant to static-content and markers, so I don't see that as a major issue, and would expect to keep the static-content buffers for a page in memory for the life of the page-sequence. Markers are a bit more problematical, and may well benefit from some transparent serialization. Sorry, I'm still a bit misguided, it seems. This part, I already got, but... I was thinking more of the historical parts of the FO and Area trees. ... putting quotes around there is to beg the question, so, would that be the parts that have already been processed in some way? Yes. Candidates would be FOs and areas associated with pages containing forward references, and, in general such objects associated with the current page sequence, from the point of view of possible layout optimisation. At one stage I considered linking all nodes in the FO tree with reference objects, but I was concerned about the extra layer of reference objects and their impact on memory and performance. However, when we get parallel FO tree, Area tree and rendering working it may pay dividends. I find the language of the java.lang.ref package confusing, but I think that phantom references open the possibility of performing serialization on demand, when the object is queued for GC. Can you elaborate a bit on this? AFAICT, the actual referent of a phantom reference is itself unreachable through the reference object (the ref's get() method always returns null), so you could indeed test via isEnqueued() whether or not the referent of a phantom reference is queued for GC, and then...? A soft reference at least would allow to get() the object and do something with it or make it do something with itself before actually clearing the ref. As I say, I find the language confusing, but it seemed to me that, as long as the object being GC'd contained enough information to determine its origins, when it found its way onto the reference queue for disposal the thread responsible could serialize it just before it was destroyed, and store the information required for its recovery in the appropriate place. The same may be achievable using the other reference types. Whether the imprecations against finalizers apply also to phantom reference finalizers I don't know. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
embed images
Hello, I've got a special question using FOP 0.20.5: I want to include GIF and JPEG images in the PDF which are not accessible neither through HTTP, FTP nor the local file system. They reside only in memory. I can imagine the following solutions: 1. URL protocol handler 2. FO extension 3. something like a virtual file system URL protocol handler implemention is simple but unfortunately does not work because I had to set the System property java.protocol.handler.pkgs which is write protected in our production environment. Is there a possibility to embed the images in the FO file ? So I could implement an FO extension. What ideas about a VFS ? Any help and advice is welcome. Greets, Heiko
[VOTE] Remove Visitor Patterns from AbstractRenderer.java
Team,
To simplify the Area Tree--Renderer interaction somewhat, making this
section of the code easier to follow, I'd like to make two changes to
the code:
1.) Remove the serveVisitor() methods in AbstractRenderer.java [1], and
return to what we were using last year, that of having the InlineArea
call the render() methods. This will allow us to drop the
area.inline.InlineAreaVisitor interface[2] as well as the sundry
acceptVisitor methods in the inlineArea subclasses[3, for one example
of the 8-9 places this occurs].
Currently developing with them around IMO makes comprehension, coding
and debugging more difficult. They also add an additional level of
indirection in the code where there is enough complexity already. If
there's a need for these patterns in the future, e.g., for more Area
Tree pluggability, we can bring them back, but upon actual demand and
after things are finished in our coding.
Anyway, here's my +1 for this change.
[1]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/render/AbstractRenderer.java?r1=1.12r2=1.13diff_format=h
[2]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/area/inline/InlineAreaVisitor.java?diff_format=hrev=1.2view=auto
[3]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/area/inline/Character.java?r1=1.1r2=1.2
-
2.) (This I'm less sure on) After reverting, I'd like to remove the
render functions within the InlineArea objects in favor of direct
function calls within AbstractRenderer:
i.e., move from here in render.AbstractRenderer:
protected void renderLineArea(LineArea line) {
List children = line.getInlineAreas();
for (int count = 0; count children.size(); count++) {
InlineArea inline = (InlineArea) children.get(count);
inline.render(this);
}
}
to here:
protected void renderLineArea(LineArea line) {
List children = line.getInlineAreas();
for (int count = 0; count children.size(); count++) {
InlineArea inline = (InlineArea) children.get(count);
renderInlineArea(inline); // may need expansion, with
instanceof() operators.
}
}
This will result in allowing us to remove several render() functions
from the InlineArea objects, and remove the bounce-back between
Renderers and Area objects, further simplifying the coding. The
drawback to this method is that we may need some instanceof() operators
in order to choose the proper render method. (Different InlineAreas
currently have different rendering functions.)
I'm almost +1 on this, but am awaiting more comments on the performance
issues involved. Performance is the my only concern with this change
(this section of the code is very highly called)--I otherwise like the
simplification that this change will offer.
Thanks,
Glen
DO NOT REPLY [Bug 27150] New: - FOP does not formatting xml to pdf in Jetspeed/Applet, but it works in Java application
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=27150. 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=27150 FOP does not formatting xml to pdf in Jetspeed/Applet, but it works in Java application Summary: FOP does not formatting xml to pdf in Jetspeed/Applet, but it works in Java application Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, Iam building an application with FOP in Jetspeed portlet. It dont generate or formatting XML to PDF file when i run this in the portlet or in a 'java applet'. Here is a litle debug list: using embedding.package FOP ExampleObj2XML Preparing... Input: a CustomerOrder object Output: XML (C:\FUTURE\eclipse\xml\xml\CustomerOrder.xml) Serializing... Input: XML (C:\FUTURE\eclipse\xml\xml\CustomerOrder.xml) Stylesheet: C:\FUTURE\eclipse\xml\xslt\CustomerOrderfo.xsl Output: PDF (C:\FUTURE\eclipse\xml\xml\CustomerOrder.pdf) Transforming... Start XSLT transformation and FOP processing [DEBUG] Building formatting object tree [DEBUG] Current heap size: 1730Kb [DEBUG] Parsing of document complete [DEBUG] Initial heap size: 1501Kb [DEBUG] Current heap size: 1741Kb [DEBUG] Total memory used: 239Kb [DEBUG] Memory use is indicative; no GC was performed [DEBUG] These figures should not be used comparatively [DEBUG] Total time used: 1151ms [DEBUG] Pages rendered: 0 //This look like the pages did not rendered. -- Pages rendered: 0 Here is an debug when i use this in Java application: FOP ExampleXML2PDF Preparing... Input: XML (.\xml\xml\CustomerOrder.xml) Stylesheet: .\xml\xslt\CustomerOrderfo.xsl Output: PDF (.\out\CustomerOrder.pdf) Transforming... [INFO] building formatting object tree [WARNING] Screen logger not set - Using ConsoleLogger. [INFO] setting up fonts [INFO] [1] [WARNING] Sum of fixed column widths 269290 greater than maximum specified IPD 99212 [INFO] area contents overflows area in line [WARNING] Sum of fixed column widths 481884 greater than maximum specified IPD 99212 [WARNING] Sum of fixed column widths 269289 greater than maximum specified IPD 42519 [WARNING] Sum of fixed column widths 269290 greater than maximum specified IPD 42519 [INFO] area contents overflows area in line [WARNING] Sum of fixed column widths 269289 greater than maximum specified IPD 42519 [WARNING] Sum of fixed column widths 269290 greater than maximum specified IPD 42519 [INFO] area contents overflows area in line [INFO] Parsing of document complete, stopping renderer Iam using the same XML and xsl-fo file in both of these application. The same with the Java code, and the same component. But it only works in Java application and not in an java applet or in Jetspeed portlet. I hope you can help me with a solution by this problem.
