| Issue 55: | Export to PDF does not work | |
| 2 people starred this issue and may be notified of changes. | Back to list |
I added the export option TableFacadeImpl.PDF to the BasicPresidentController example. Line 62 reads now: tableFacade.setExportTypes(response, CSV, EXCEL, PDF); I also added the needed libraries from the export-dependencies package and flyingsaucer. When I klick on the PDF export link I get a ServletException "Operation timed out: connect:could be due to invalid address" (whole stacktrace is appended as a file) I tried the versions 2.2.4 and 2.3_07.10.29. Could you please fix this bug because I really need this functionality. thanks. Dirk Michaelsen
Nov 13, 2007
#1
extremec...@gmail.com
Nov 13, 2007
The saved file is added as attachment.
Nov 13, 2007
Are you saying that you followed the FAQ instructions and this is the output? If so then I see that the output is not valid...do you get any error messages while exporting it to just this file?
Status:
Accepted
Nov 13, 2007
Yes I followed the FAQ instructions and there was no error message.
Nov 13, 2007
My fault...that was not a valid test. The getBytes() method only returns the String bytes. In fact if I rename your output.pdf file to output.html it displays your table in my browser. The actual conversion to a pdf file happens in the exporter for this view: http://jmesa.googlecode.com/svn/trunk/jmesa/src/org/jmesa/view/pdf/PdfViewExporter.java Take a look at the export method and rip out the code to do the rendering and then output that to a local file. If that is confusing I could try it tonight myself. What I am trying to do is see if we are able to get a valid pdf file outside of the servlet container context. I really think what we are going to find is that the pdf is being generated, but then one of your filters is causing problems when exported because of a container issue. After doing this for some time now I have found that usually the filters are the cause. There are workarounds but I am hoping that we can prove it is or is not a valid pdf file first.
Nov 13, 2007
Here, try putting this in your class to debug it. This will tell us if the pdf is
able to be created...
I am going to come up with a export utility class too so that developers can test
their exports like this.
private void testPdfOutput(HttpServletRequest request, TableFacade tableFacade) {
Limit limit = tableFacade.getLimit();
if (!limit.isExportable() || !limit.getExport().getType().equals("pdf")) {
return;
}
View view = tableFacade.getView();
byte[] contents = view.getBytes();
System.setProperty("xr.load.xml-reader", "org.ccil.cowan.tagsoup.Parser");
System.setProperty("xr.util-logging.loggingEnabled", "false");
System.setProperty("xr.util-logging.java.util.logging.ConsoleHandler.level",
"WARN");
System.setProperty("xr.util-logging..level", "WARN");
System.setProperty("xr.util-logging.plumbing.level", "WARN");
System.setProperty("xr.util-logging.plumbing.config.level", "WARN");
System.setProperty("xr.util-logging.plumbing.exception.level", "WARN");
System.setProperty("xr.util-logging.plumbing.general.level", "WARN");
System.setProperty("xr.util-logging.plumbing.init.level", "WARN");
System.setProperty("xr.util-logging.plumbing.load.level", "WARN");
System.setProperty("xr.util-logging.plumbing.load.xml-entities.level", "WARN");
System.setProperty("xr.util-logging.plumbing.match.level", "WARN");
System.setProperty("xr.util-logging.plumbing.cascade.level", "WARN");
System.setProperty("xr.util-logging.plumbing.css-parse.level", "WARN");
System.setProperty("xr.util-logging.plumbing.layout.level", "WARN");
System.setProperty("xr.util-logging.plumbing.render.level", "WARN");
XRLog.setLoggingEnabled(false);
ITextRenderer renderer = new ITextRenderer();
try {
DocumentBuilder builder =
DocumentBuilderFactory.newInstance().newDocumentBuilder();
Document doc = builder.parse(new ByteArrayInputStream(contents));
renderer.setDocument(doc, request.getRequestURL().toString());
renderer.layout();
File file = new File("/home/jeff/workspace/output.pdf");
FileOutputStream output = new FileOutputStream(file);
renderer.createPDF(output);
} catch (Exception e) {
throw new RuntimeException("not able to generate the pdf");
}
}
Nov 14, 2007
Thanks for the test code. Unfortunately it still does not work. The exception throw
is still the ServletException ("connection timed out"). In the debugger I found out
that the line of code that produces the error is
Document doc = builder.parse(new ByteArrayInputStream(contents));
The error is definitely produced in the parse method of the builder. As environment I
installed a clean room Tomcat 5.5.20 server. For testing purposes I changed the log
level of your code to ALL and added a e.printStackTrace() before the RuntimeException
is thrown. The console output is added as an attachment (console.log). This may help
you analysing the problem.
Nov 14, 2007
Meanwhile I found out that the problem is caused by the parser that wants to call home to www.w3.org via internet while it parses the document. That call seems to be captured by our firewall. Is there any way to tell the parser not to verify the document?
Nov 14, 2007
Interesting...I was just going to get back with you too. I am having other problems with the PDF as well. I am able to view it when I use that test code to put it out to a local file, but not when I send it out to the response. The developer that created that view is looking into it today.
Status:
Started
Nov 14, 2007
If you look in the PdfView file you will see that that is where the call happens.
That is a pretty typical thing for a html document. Do you generally run without a
doctype declaration on your website?
I found out my problem with the PDF was related to the new stylesheet.
The following new styling breaks it:
.jmesa .odd td {
border: 1px solid #ffffff;
}
.jmesa .even td {
border: 1px solid #e3e3e3;
}
Nov 14, 2007
See issue 58 for a fix for the PDF export with enhancements.
Nov 14, 2007
I included the changes. In addition I moved the doctype to the preferences file so that the doctype could be modified, or blanked out. pdf.css=/css/jmesa-pdf.css pdf.doctype=<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Would you be interested in helping out in testing this? If so I could do a build of the project and the example web site.
Nov 14, 2007
Sure I would!
Nov 15, 2007
I put a build in the downloads: http://builds.jmesa.org/ They are the builds that begin with jmesa-2.2.4-pdf. Let me know if you have any problems or questions.
Nov 15, 2007
Now I have tested the new build and it's like always in life: I have good news and I have bad news. The good news are that when I run the basic president example on my home computer, the two outputs (saved and downloaded) are valid PDF documents and they are byte-equal. So from your point of view your job seems to be done - many thanks so far. The bad news are that the parser of the DocumentBuilder still tries to connect to www.w3.org which is blocked by the firewall of my company. The only thing that changed is the exception that is thrown. It is not the ServletException anymore but it's a java.net.ConnectException (stacktrace is attached as file). I think you can easily reproduce this problem if you unplug your network cable before running the example (then it's an UnknownHostException). It seems the DocumentBuilder tries to validate the xmlschema. I already tried to download the DTDs from w3c and to put them into the WEB-INF directory of the application. But that didn't work. Do you have any ideas what else I can do to get the PDF export working?
Nov 16, 2007
In the WEB-INF/jmesa.properties file declare the pdf.doctype attribute and keep the doctype as blank. The jmesa.properties file is the Preferences file. What you are doing is overriding the default. pdf.doctype=
Nov 16, 2007
Thank you very much! Now it works like a charm. :-)
Nov 16, 2007
Thats great news! I will close this issue out then...it will be part of the 2.2.5 upcoming release (probably a week or so out). I will write up a wiki page to make the export features more clear.
Status:
Fixed
|