Forum Replies Created

Viewing 15 posts - 1 through 15 (of 4,247 total)
  • Author
    Posts
  • in reply to: Troubleshooting
    #26168

    Since Java version 1.4 org/w3c/dom/* classes are part of JDK. The Open Source CSS Parser library (ss_css2.jar) also includes the package and causes the conflict. A solution is to remove the conflicting packages from ss_css2.jar using WinZip or any other JAR/ZIP tool.

    in reply to: Troubleshooting
    #26166

    The exception tells, that PD4ML encountered a charset directive, whose value differs from the default. It tries to re-open the input stream in order to apply the new encoding, but it can not in the particular case (for example, InputStream.reset() is not supported).

    The simpliest workaround is to use
    public void render( URL url, OutputStream os )
    instead of your approach.

    in reply to: Troubleshooting
    #26167

    Usually the problem happens if an application server or servlet engine runs in a combination with Apache web server. By default Apache tries to optimize PDF delivery by so-called “byteserve” method, which is not correctly interpreted by every browser/acrobat reader plugin versions. To disable the optimization add to Apache’s httpd.conf file the following directive:
    Header unset Accept-Ranges
    Check Apache documentation to learn in which config section the directive should go to.

    in reply to: Troubleshooting
    #26169

    First, make sure that the source HTML enclosed between and is not blank. If not, a reason may be as follows:

    JSP is a text-oriented format. But PD4ML JSP taglib outputs binary PDF data. Under particular conditions JSP runtime tries to erroneously apply character encoding conversion to the binary bytes and corrupts the PDF content. As a rule such PDFs may contain multiple pages, but most of them (or all) are blank.

    As a workaround try to add encoding=”default” attribute to

    A special case is Resin application server, in situations when the default OS encoding differs from Latin 1 (ISO-8859-1)

    The server in ServlerOutputStream methods always uses default character encoding set for OS ignoring explicitly given settings.

    To avoid such conversion, add to Resin command line the following parameter:

    -Dfile.encoding=ISO-8859-1

    in reply to: Troubleshooting
    #26170

    Since v3.5.0 PD4ML does not resolve relative paths to absolute ones, so the problem is solved.

    For older versions a workaround is to explicitely define a document base, i.e.

    in reply to: Troubleshooting
    #26171

    In most of the cases the exception is caused by an invalid usage of PD4ML. It is thrown by the dispatcher thread of Java, which processes PDF rendering. Itself the exception is not informative – important info comes with an encapsulated “original” exception. You can find it in the stack trace by “Caused by:” pattern (closer to the end of the trace).

    in reply to: Troubleshooting
    #26172

    First of all it is not a problem of PD4ML software. It seems Adobe Acrobat Reader plug-ins starting from version 6.01 does not process correctly content type supplied with HTTP response header and it rejects all PDF documents if their URL strings end not with .pdf extension.

    The only workaround we know, is to add to your web.xml file the following directives:

    [language=xml:2fdc3vxl]
    converter
    /test.jsp


    converter
    /pd4ml.pdf
    [/language:2fdc3vxl]

    Replace “test.jsp” with the actual name of your JSP. Now you can access the generated page with the url:
    http://yourserver/yourapp/pd4ml.pdf

    in reply to: Troubleshooting
    #26173

    Your JSP has whitespace characters (i.e. new line chars) that cause the output writer to be opened before PD4ML takes control. Solution: remove all whitespaces (including “new line” characters) before “
    <%@page contentType="text/html; charset=ISO8859_1"%>
    <%@page contentType="text/html; charset=ISO8859_1" %>%> and <% as well as between %> and , which cause the exception.

    in reply to: Troubleshooting
    #26174

    The issue may unveal itself as any other exception regarding GraphicsEnvironment or AWT.

    * The recommended solution is to run your application or servlet engine with -Djava.awt.headless=true given as parameter to the virtual machine. It is true only for JDK1.4 and above. Java 1.4 includes a new image I/O API that reportedly does not require an X server.

    * Install xvfb. It provides an X server emulator that can run on machines with no display hardware and no physical input devices.

    in reply to: HTML/CSS rendering issues
    #26175

    … or the gap between the header and content is bigger on the first PDF page comparing to the next ones?

    The content on the first page is placed respecting the HTML document top margin. In order to suppress it define the following CSS properties:

    in reply to: PD4ML Tips & Tricks
    #26176

    You may dynamically add the data (for example the current date) to the header/footer definition teamplate:

    Java:

    [language=java:38gya5ch]String pageNumberTemplate = getFormattedDate() + “, page $[page]”;
    footer.setPageNumberTemplate( pageNumberTemplate );[/language:38gya5ch]
    JSP:

    [language=xml:38gya5ch]<% String template = getFormattedDate() + ", page $[page] "; %>

    in reply to: PD4ML Tips & Tricks
    #26177

    TR {page-break-inside: avoid} CSS definition is intended to protect table rows from being broken.

    PD4ML also provides a limited experimental support for table header replication:

    You need to invoke pd4ml.enableTableBreaks(true) method (or to set enableTableBreaks attribute of ) – it implicitly defines page-break-inside: avoid for

    elements and replicates the table heading row(s) to the tops of all table parts. (heading row there is a row, which consists of

    elements only)

    In both of the cases the table border and the table background can not reflect the splits on

    level. So the best way is to disable the table border and background and to define borders and background colors for single cells.

    [language=css:3dp2l7e3]TD { border: 1px solid red }
    TABLE { border: none; border-collapse: collapse }[/language:3dp2l7e3]

    in reply to: PD4ML Tips & Tricks
    #26178

    HTML-to-PDF mapping scale depends on HTML width given in screen pixels and PDF page format width (minus horizontal insets) in typographical points.

    htmlToPdfScale = ( pageFormat.width – pageInsets.left – pageInsets.right ) / htmlWidth

    The font sizes are scaled correspondingly to the entire document scale in order to keep page layout not broken.

    If you need to get a specific font size in your PDF documents, try to achieve that by “playing” with htmlWidth and horizontal PDF page inset parameter values.

    For the cases, when exact PDF objects’ dimensions are critical there is an API call protectPhysicalUnitDimensions(), which forces PD4ML to respect and to output to PDF sizes/dimensions given in pt, in, cm etc. The conversion mode sacrifices proportions between objects, whose dimensions are given in physical and screen units. It may result page layouts differ from the layouts rendered in web browsers. Use it with care.

    in reply to: General questions / FAQ
    #26179

    PD4ML objects access any resource (shared image and font cache, for example) by thread-safe way. But PD4ML instance is not re-enterant: you may not use a single PD4ML object simultaneously from multiple threads.

    If you need to run multiple HTML-to-PDF conversions in parallel, you need to create a separate PD4ML instance per converting thread.

    The safest practice would be to delete PD4ML instance after each HTML-to-PDF conversion and create a new object when needed.

    in reply to: General questions / FAQ
    #26180

    PD4ML requires an open source CSS parser library ss_css2.jar. A patched version of the library is included to PD4ML distribution. Also the library and its changed source code are available to download from our site separately.

Viewing 15 posts - 1 through 15 (of 4,247 total)