DO NOT REPLY [Bug 50510] No content in the generated rtf file using FOP after revision 1036000
https://issues.apache.org/bugzilla/show_bug.cgi?id=50510 Simon Pepping spepp...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED OS/Version||All --- Comment #1 from Simon Pepping spepp...@apache.org 2010-12-22 07:41:44 EST --- The problem was created in revision 1036179. There I erroneously removed a constructor which as a side effect attaches the new object to its parent. Fixed in revision 1051874. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
RE: FOP build
I don't know why my ant builds always seems to fail junit tests, but it appears most if not all of those tests are for the custom fonts it includes for whatever reason. I print everything in one font (Lucida Typewriter) so it's readable and fixed width, so I'll just create my own version and hack out everything to do with specific fonts including the junit tests. -Original Message- From: Pascal Sancho [mailto:pascal.san...@takoma.fr] Sent: Thursday, December 09, 2010 8:28 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: FOP build Hi, Junit tests are for pre-commit purpose. You can easily avoid them by running the right ant option: ant package. see [1] for further info on running ant with fop. [1] http://xmlgraphics.apache.org/fop/1.0/compiling.html#env-ant Le 09/12/2010 14:08, Eric Douglas a écrit : Is there a way to simplify FOP? I have the 1.0 source. I can run the ant build and it creates a new jar. Now I tried excluding a font class I don't need, and it failed the build on a junit test. I tried commenting that test out and it failed a different test. I excluded a few tests and it succeeded but it didn't create the jar. It should still be executing that step which creates the jar. I'm passing in custom fonts so I'd like to be able to save some overhead by removing all of those base 14 fonts. -- pascal
Question on MimeConstants
Hello All, I just downloaded the FOP jar file. Our Project involves Converting XML to PDF...So, while compiling your examples...we found out that Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, foUserAgent, out); Mime-PDF was not defined in MimeConstants.java Please help with this one Thank You, Dickson Robert 518-402-5404
RE: Question on MimeConstants
public interface MimeConstants extends
org.apache.xmlgraphics.util.MimeConstants {
Check out the other class(es). There's more than one set of
MimeConstants combined here.
From: Dickson Robert [mailto:dickson.rob...@ag.ny.gov]
Sent: Wednesday, December 22, 2010 10:16 AM
To: 'fop-dev@xmlgraphics.apache.org'
Subject: Question on MimeConstants
Hello All,
I just downloaded the FOP jar file. Our Project involves Converting XML
to PDF...So, while compiling your examples...we found out that
Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, foUserAgent, out);
Mime-PDF was not defined in MimeConstants.java
Please help with this one
Thank You,
Dickson Robert
518-402-5404
Patch for large memory usage inside o.a.f.r.p.PDFDocumentHandler
Hi fop-dev,
In one of my use cases, I create a PDF file having about 2 pages from FOP
intermediate format. I imagined this as a streaming process (e.g. read a page
in FOP_IF, write it to PDF and release memory) with the exception of caching of
images. In reality, by analyzing a heap dump taken with the
-XX:+HeapDumpOnOutOfMemoryError parameter on a production server, I found out
that o.a.f.r.p.PDFDocumentHandler keeps for every page a reference to be used
for bookmarks outlines. In my case, the retained heap size of every page is
about 150kb. If you multiply this with the number of pages, the memory usage is
large. Even worse, on my production server I have 10 threads creating 20k page
documents in parallel.
Attached is a patch against the latest revision 1051938 of trunk that
considerably reduces the memory usage by keeping only a String pdfPageRef
instead of the full org.apache.fop.pdf.PDFReference object. This was possible
because from the object we only need to get that string. Ideally, I would like
not to keep at all the page references if bookmarks outlines are not used. Or
at least, keep it only for the pages that are indeed referenced. Is this
possible ? If so, do you have any hints for this ?
If further optimizations are not possible or complex, then I guess I will just
open an issue and attach this patch. I hope you agree with the addition of
generics on the Map declaration and with the change of new Integer() to
Integer.valueOf()) (findbugs performance warning).
Greetings,
Alexis Giotis
Index: src/java/org/apache/fop/render/pdf/PDFDocumentHandler.java
===
--- src/java/org/apache/fop/render/pdf/PDFDocumentHandler.java (revision
1051938)
+++ src/java/org/apache/fop/render/pdf/PDFDocumentHandler.java (working copy)
@@ -39,7 +39,6 @@
import org.apache.fop.pdf.PDFAnnotList;
import org.apache.fop.pdf.PDFDocument;
import org.apache.fop.pdf.PDFPage;
-import org.apache.fop.pdf.PDFReference;
import org.apache.fop.pdf.PDFResourceContext;
import org.apache.fop.pdf.PDFResources;
import org.apache.fop.render.extensions.prepress.PageBoundaries;
@@ -93,7 +92,7 @@
protected PageReference currentPageRef;
/** Used for bookmarks/outlines. */
-protected Map pageReferences = new java.util.HashMap();
+protected MapInteger, PageReference pageReferences = new
java.util.HashMapInteger, PageReference();
private final PDFDocumentNavigationHandler documentNavigationHandler
= new PDFDocumentNavigationHandler(this);
@@ -238,7 +237,7 @@
pdfUtil.generatePageLabel(index, name);
currentPageRef = new PageReference(currentPage, size);
-this.pageReferences.put(new Integer(index), currentPageRef);
+this.pageReferences.put(Integer.valueOf(index), currentPageRef);
this.generator = new PDFContentGenerator(this.pdfDoc,
this.outputStream,
this.currentPage);
@@ -308,21 +307,22 @@
}
PageReference getPageReference(int pageIndex) {
-return (PageReference)this.pageReferences.get(
-new Integer(pageIndex));
+return this.pageReferences.get(Integer.valueOf(pageIndex));
}
static final class PageReference {
-private final PDFReference pageRef;
+private final String pageRef;
private final Dimension pageDimension;
private PageReference(PDFPage page, Dimension dim) {
-this.pageRef = page.makeReference();
+// Avoid keeping references to PDFPage as memory usage is
+// considerably increased when handling thousands of pages.
+this.pageRef = page.makeReference().toString();
this.pageDimension = new Dimension(dim);
}
-public PDFReference getPageRef() {
+public String getPageRef() {
return this.pageRef;
}
Index: src/java/org/apache/fop/render/pdf/PDFDocumentNavigationHandler.java
===
--- src/java/org/apache/fop/render/pdf/PDFDocumentNavigationHandler.java
(revision 1051938)
+++ src/java/org/apache/fop/render/pdf/PDFDocumentNavigationHandler.java
(working copy)
@@ -189,7 +189,7 @@
p2d = new Point2D.Double(
action.getTargetLocation().x / 1000.0,
(pageRef.getPageDimension().height -
action.getTargetLocation().y) / 1000.0);
-String pdfPageRef = pageRef.getPageRef().toString();
+String pdfPageRef = pageRef.getPageRef();
pdfGoTo.setPageReference(pdfPageRef);
pdfGoTo.setPosition(p2d);
DO NOT REPLY [Bug 50514] New: Images being created with a blueish tint in the PDF
https://issues.apache.org/bugzilla/show_bug.cgi?id=50514 Summary: Images being created with a blueish tint in the PDF Product: Fop Version: 0.95 Platform: Other OS/Version: Linux Status: NEW Severity: regression Priority: P2 Component: images AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: jeremy.gr...@jivesoftware.com Created an attachment (id=26440) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26440) Example of blue images in PDF When PDF is generated, some images are appearing with a blue hue to them. Example attached. System specifics... OS RHEL OS Version Red Hat Enterprise Linux Server release 5.3 Server VMWare CPU 4 2.40GHz Intel(R) Xeon(R) CPU E7450 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50514] Images being created with a blueish tint in the PDF
https://issues.apache.org/bugzilla/show_bug.cgi?id=50514 --- Comment #1 from jeremy.gr...@jivesoftware.com 2010-12-22 13:14:55 EST --- Created an attachment (id=26441) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26441) The original images -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: A question about working on apache fop
Hi Martin and Roland, The FOP team is pleased to accept contributions to FOP, large and small. Contributions are best submitted as a patch attached to an issue in our bug tracking system bugzilla, http://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop. If you plan a larger contribution, such as the one you intend to develop, it is useful to create a single bugzilla issue, and attach subsequent patches to it. We will create a Subversion branch for your project, to which we will add your patches. We will also keep the branch up to date with respect to the main code (Subversion trunk), so that integration of your contributions with the main code is tested automatically. Our ant build system allows one to test the code with junit, checkstyle, and findbugs tests. We encourage contributors to run those tests. We also encourage them to create and submit test cases for their new functionality or feature and bug fixes. The use of a subversion branch allows you to submit an early implementation to FOP, and discard it later. In view of the complexity of the work, it may be useful to create design documents first, along with theoretical considerations about the algorithms used. You may publish these in your own web space, but you may also use FOP's wiki, http://wiki.apache.org/xmlgraphics-fop/DeveloperPages, for that purpose. The code in our subversion repository is automatically synchronized in a git repository, git://git.apache.org/fop.git or https://github.com/apache/fop. See also http://wiki.apache.org/general/GitAtApache. For larger contributions, the Apache Software Foundation (ASF) wishes to have a contributor license of all copyright owners (authors or their employers) of the submitted code, see http://www.apache.org/licenses/#clas. See also 'How can I contribute?', http://xmlgraphics.apache.org/fop/dev/faq.html#faq-N1000D. See also some parts of 'Guide for new committers', http://www.apache.org/dev/new-committers-guide.html. This enables the ASF to release the code under the Apache license version 2. All contributions must go via patches at bugzilla, so that it is clear that you submitted them under your contributor license with the ASF. Therefore, if you would maintain a public git branch or a public branch in another distributed VC system, we would not pull directly from it. Your first steps would be anything you need to do to arrive at your first submitted patch: design, code, test, submit. You could open a bugzilla issue early if you wish. You could create a wiki page for your project and add design documents to it. We hope to see your contributions to FOP, to the benefit of all its users. Best, Simon Pepping On Tue, Dec 21, 2010 at 04:40:11PM +0100, Roland Schwarz wrote: Dear developers, dear members of the Project Management, we work on a research project called XML-Print at the University of Trier, Germany. The idea is to implement (or improve) a XML to PDF typesetter with an easy-to-use GUI which helps humanists to publish their critical editions, dictionaries etc. It will be part of the toolkit TextGrid Lab which is a long-term project to develop a general framework containing different tools for collaborative work on digital documents (http://www.textgrid.de/en/startseite.html). Having looked at existing approaches FOP seems to be a stable and promising base to build on. However there are some features missing either not yet implemented in FOP itself or even not defined in XSL-FO 1.1. We therefore would have to implement features based on XSL-FO 1.1, but also on the requirements for XSL-FO 2.0 as described in http://www.w3.org/TR/xslfo20-req/. Among others we are especially interested in some elements mentioned in the current design draft like - marginalia (2.2.3) - side-by-side flows (2.2.6) - line numbering (2.2.7.1) ** - cross references (2.2.8) ** The line numbering will also involve some more complex issues, not only a simple line numbering of every n-th line. For example there could be interactions between line numbers and marginalia, which have to be considered in the typesetting process. We would also have to design and implement new layout features currently not mentioned in any seen XSL-FO design draft like the usage of a complex bibliographic apparatus or a grid typesetting feature. There are also requirements for complex footnotes, which may lead to an extension of the currently available footnote mechanism in the XSL-FO standard. At the current point in our work we wonder how we can use the current status of FOP, how we can embed our work into future releases and last but not least, give some work back to the community. One developer would work full-time on FOP for at least one year. Furthermore we would like to know if an early implementation of requirements -- using a separate namespace of course -- is somehow wanted and if there is any other group working on them. What would be the next steps for us? Thank
DO NOT REPLY [Bug 43166] unclosed border on nested inlines
https://issues.apache.org/bugzilla/show_bug.cgi?id=43166 --- Comment #3 from Simon Pepping spepp...@apache.org 2010-12-22 13:39:40 EST --- The patch works of course, but it looks a bit like magic. I would like to dig deeper into this. I am surprised that the actual value of the index makes such a difference. It would be helpful if you would indicate: 1. where in the code the border is added or not added to the result page, depending on the value of the index; 2. where in the code the knuth element is replaced instead of being added. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Height of an inline-area
Hi, I have a question for the XSL-FO scholars out there. Given the following FO snippet: fo:blockLorem ipsum dolor fo:inline id=outer border=1pt solid redfo:inline id=inner font-size=30ptsit/fo:inline/fo:inline amet/fo:block how tall is the border supposed to be? Section 4.6, “Inline-areas”, states that “An inline-area with inline-area children has a content-rectangle which extends from its dominant baseline by its text-depth in the block-progression-direction, and in the opposite direction by its text-altitude”. In the case of the outer inline-area, text-altitude and text-depth are taken from the font metrics and amount to 11100mpt. So the border-rectangle is 11.1pt high. The inner inline-area has a font-size of 30pt, which makes its content-rectangle 27750mpt high, which largely overflows the border-rectangle of the outer inline-area. Have I missed anything, or is this behaviour utterly counter-intuitive? Note that the height of the inner inline-area still is taken into account when building lines; this is explained in details in section 4.5, “Line-areas” but, basically, when the inline-stacking-strategy is left to its default value, the maximum-line-rectangle is used and determined according to the content-rectangles of /all/ the inline-areas stacked within the line-area. I came to think about this issue when it was mentioned to me that only the bottom part of an image surrounded by an fo:basic-link element is active. The description of fo:basic-link closely follows the one for fo:inline so the explanation above applies. If I understand well, the only way to increase the content-rectangle of the basic-link area is to increase the font size, but that font-size would need to be computed in a pre-processing step. It would have to take into account the active font where the basic-link occurs, and the size of the image, and possibly content-height set on the fo:external-graphic. That would be horribly tricky and fragile. Any thoughts? Thanks, Vincent
Re: A question about working on apache fop
Hello, Welcome to the FOP project. In addition to Simon’s notes, I have a few more specific comments. In theory I would be reluctant to work on any features that have not been standardized yet. The way they are specified may heavily impact the design, so you face the danger of having to throw away all your work and restart again. This can be mitigated by a careful definition of the object model, abstractions and encapsulations but the risk is still there. As you mentioned, any non-standardized element should be defined in its own extension namespace and developed as a plug-in to FOP. This will allow to avoid conflicts and backwards incompatibilities with later versions of the Recommendation. Any work on typesetting is inherently difficult, but FOP has a few additional challenges of its own. ATM the layout engine is not really designed to be pluggable, with well-defined extension points. That would need to be addressed. Also, the data model it’s based on (inspired from Dr Knuth’ work on digital typography) is fundamentally limited and doesn’t work well for e.g. tables. Some time ago I started to work on the prototype of a new layout engine, but unfortunately I was sidetracked by more urgent work. I’m planning to restart this work at some point in the future. The object-oriented paradigm applies well to XSL-FO. Implementing this paradigm on the layout engine is IMO the only way to keep it manageable and maintainable, especially if we are to add such complex new features (XSL-FO 1.1 alone is already extremely complex!). We’re not quite there yet, but this is doable. In short, a lot of work and challenges, but this is a very interesting area, and your full-time developer will definitely be welcome. Vincent On 21/12/10 15:40, Roland Schwarz wrote: Dear developers, dear members of the Project Management, we work on a research project called XML-Print at the University of Trier, Germany. The idea is to implement (or improve) a XML to PDF typesetter with an easy-to-use GUI which helps humanists to publish their critical editions, dictionaries etc. It will be part of the toolkit TextGrid Lab which is a long-term project to develop a general framework containing different tools for collaborative work on digital documents (http://www.textgrid.de/en/startseite.html). Having looked at existing approaches FOP seems to be a stable and promising base to build on. However there are some features missing either not yet implemented in FOP itself or even not defined in XSL-FO 1.1. We therefore would have to implement features based on XSL-FO 1.1, but also on the requirements for XSL-FO 2.0 as described in http://www.w3.org/TR/xslfo20-req/. Among others we are especially interested in some elements mentioned in the current design draft like - marginalia (2.2.3) - side-by-side flows (2.2.6) - line numbering (2.2.7.1) ** - cross references (2.2.8) ** The line numbering will also involve some more complex issues, not only a simple line numbering of every n-th line. For example there could be interactions between line numbers and marginalia, which have to be considered in the typesetting process. We would also have to design and implement new layout features currently not mentioned in any seen XSL-FO design draft like the usage of a complex bibliographic apparatus or a grid typesetting feature. There are also requirements for complex footnotes, which may lead to an extension of the currently available footnote mechanism in the XSL-FO standard. At the current point in our work we wonder how we can use the current status of FOP, how we can embed our work into future releases and last but not least, give some work back to the community. One developer would work full-time on FOP for at least one year. Furthermore we would like to know if an early implementation of requirements -- using a separate namespace of course -- is somehow wanted and if there is any other group working on them. What would be the next steps for us? Thank you for any responses. Best regards and Happy Holidays from Martin Sievers and Roland Schwarz
