Please add support for allowing the width and height of form field elements to be set.

i want to use this library but idon't know if this support css3 or not and angularjs

Is it possible to add PDF properties ?
I mean properties like owner, title, subject, security...

Well it would be really nice if possible :)

I have an issue running on JBoss EAP 6.1 which seems to be down to some kind of Xalan / XML parser conflict. I note that the line in question has a //FIXME comment so wonder if you can advise of any workaround. My code is running fine on Jetty.

EAP stacktrace:

JBWEB000236: Servlet.service() for servlet dispatcher threw exception: java.lang.ClassNotFoundException: com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl from [Module "deployment.edental-web-pars.war:main" from Service Module Loader]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
	at java.lang.Class.forName0(Native Method) [rt.jar:1.8.0_102]
	at java.lang.Class.forName(Class.java:348) [rt.jar:1.8.0_102]
	at javax.xml.transform.FactoryFinder.getProviderClass(FactoryFinder.java:116) [rt.jar:1.8.0_102]
	at javax.xml.transform.FactoryFinder.newInstance(FactoryFinder.java:169) [rt.jar:1.8.0_102]
	at javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:152) [rt.jar:1.8.0_102]
	at com.openhtmltopdf.resource.XMLResource$XMLResourceBuilder.createXMLResource(XMLResource.java:216) [openhtmltopdf-core-0.0.1-RC8.jar:]

which is triggered by the following code:

try {
	// FIXME:
	// Currently, we have to do this as the user may have an older vesion of xalan on their classpath which would be
	// used otherwise.
	xformFactory = TransformerFactory.newInstance("com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl", null);
} catch(Exception e) {
	XRLog.load(Level.SEVERE, "Could not load preferred XML transformer, using default which may not be secure.");
	xformFactory = TransformerFactory.newInstance();
}

As TransformerFactory throws an Error rather than an Exception it looks your catch{} block does not execute.

    public static TransformerFactory newInstance(String factoryClassName, ClassLoader classLoader)
        throws TransformerFactoryConfigurationError{

        //do not fallback if given classloader can't find the class, throw exception
        return  FactoryFinder.newInstance(TransformerFactory.class,
                    factoryClassName, classLoader, false, false);
    }

I don't know much about these things but seems to be because JBoss includes specific version of Xalan and Xerces as modules. Drilling down into the modules directory I can find a file named javax.xml.transform.TransformerFactory with the following content:

org.apache.xalan.processor.TransformerFactoryImpl

I have tried excluding these modules via the jboss-deployment-descriptor and bundling a javax.xml.transform.TransformerFactory file with the application but with no success.

Hi Daniel,

I want to use openhtmltopdf to generate PDFs that are partially based on user supplied HTML on a corporate website. I'm wondering if you could comment about any security issues that might raise, as it has the security team raising their eyebrows.

For example it might be possible there is a bug in the image rendering code that allows code to be executed on the server if some special image is supplied to it. Personally I think the scenario is very unlikely but I'd like to hear your take on it. The image rendering code is part of the PDFBox library isn't it? If that is pure java then it's not really vulnerable to stack buffer overflow attack is it? To me the probability of such an attack is exceedingly small but I have to convince the security team and I don't have any real knowledge of how that part of the library is implemented.

Are you aware of any other risks and how they can be mitigated when rendering user supplied HTML?

Thanks in advance
Martin

This is critical for multi script support where text may be in two or more languages but a font only supports one script.

@willamette has proved an implementation for Flying-saucer which we can base our implementation on.

Related issue #9 (RTL support).

In the following example, Firefox and Chromium refuse to break within any of the "test/test" sequences.

openhtmltopdf puts a break between "test" and "/test" (having the / on the next line), as shown here.

<!DOCTYPE html>
<html>
    <head>
        <title></title>
    </head>
    <body>
        <p style="font-size: 5em;">
            test/test test/test test/test
        </p>
    </body>
</html>

I believe it would be best if slash ("/") were considered to be a non-breaking character as other browsers seem to do.

This issues is extended with "basic features", as more advanced features and elements (like drop-downs or definition of text content types) are covered in a separate issue

As in the current flying saucer version, input elements should not only be rendered, but also be created as AcroForm elements in the resulting PDF (note that the implementation in flying saucer has some limitations though - e.g. radioboxes are not yet implemented, and css styles are a bit quirky still). In a first implementation, the following elements should be considered:

• HTML <input type="text" name="..." value="..."> : a text form field should be rendered, one line only. If a value is provided in the value attribute, it should be pre-filled with that value. The name attribute should be taken as value for the "name" property of the form field.
• HTML <textarea name="..." value="..."> : a multi-line text form field should be rendered. The hight of the form field should be created based on the css style. If no "height" style can be determined from the css, then it should be calculated based on the rows attribute value, multiplied by the line hight and paddings / line spacings. If the <textarea> element has a node child, the form field should be pre-filled with the text content of that child node. The name attribute should be taken as value for the "name" property of the form field.
• HTML <input type="radio" name="..." value="..." checked="true"> : a radio form field should be rendered. The value from the _id attribute should be taken as group-id for the radio boxes. The "name" property of the form field should be composed out of the name attribute, extended by a "." and the running number of the element within the group (e.g. if the name is "mysection.myoptions" then the form element name of the first radio button with this name will be "mysection.myoptions.1"). The "option" value of the form element is to be taken directly from the value attribute of the <input> element. The option should be selected by default, if the checked attribute in the <input> element is set respectively.
• HTML <input type="checkbox" name="..." value="..."> : a checkbox form field should be created. The name attribute should be taken as value for the "name" property of the form field. The form field value should be taken over from the value property of the <input> element. The checkbox should be checked by default, if the checked attribute in the <input> element is set respectively.

For all the above elements, basic styling for borders (width, color), background-color, inner padding to content and font settings should be applied (for checkboxes and radio buttons, the dot/check sign is rendered in the font-color - so even there it does count)

Implementation code available from neoFlyingSaucer.

With PDF-BOX 2, ITEXT is no longer required.

The following causes the leading spaces to be dropped from the rendered output:

<b>&#160;&#160;&#160; Text</b><br />

Whereas the following renders fine:

&#160;&#160;&#160; <b>Text</b><br />

As of PDF-BOX 2.0.0-RC3 there is no way to implement text justification. Need to open PDF-BOX JIRA issue asking them to implement the text spacing and space spacing operators.

I've started implementing CSS3 transform. My primary goal is to get rotate() working. The rest should be relative easy, but I primary need rotate(90deg).

You can view the my current development here https://github.com/rototor/openhtmltopdf/tree/css3-transform-implementation

CSS parsing should be mostly done, but it is not yet applied on the elements. I'll be away for a week on holidays, but will continue to implement this afterwards.

Note, related to #23 I implemented saveSate() and restoreState() - also for Java2D.

Allows users to use an external http library without rewriting an entire user agent callback.

We don't want the situation where it works on the developer's machine and not on the server or vice versa because of different locales.

the PDField partial name is being set to an internally generated name like "OpenHTMLCtrl1" and only the mapping name is being set to the name in the HTML. This causes lookup from PDAcroForm.getField(String) to fail when looking up by the name in the HTML because the mapping name is not used in that lookup.

Trying to close generated PDF in Adobe Reader gives Do you want to save changes to 'some.pdf' before closing? dialog.
Tested with rc7 and rc8. Worked fine with rc4.

Found this post.

There are several places in the code where they are treated as equal, such as the first letter breaker, title case transformer, etc. As far as possible we should use ICU4J when the rtl-support module is available.

The jar 0.0.1-RC9 is not in maven repository. Can you upload them to maven repository?

running this HTML:

<html> <head> <STYLE type="text/css"> body { font-family: Sans-Serif; } </STYLE> </head> <body> <p>Sample text</p> </body> </html>

on OSX 10.10.5 with java version "1.8.0_40" openhtmltopdf 0.0.1-RC5-SNAPSHOT
using com.openhtmltopdf.testcases.TestcaseRunner
the output is not san serf

Big thanks to @lillesand for bringing to my attention that Flying Saucer and OpenHTMLtoPDF are vulnerable to XXE attacks. You may be vulnerable if you use either project and allow the user to supply arbitrary XHTML (which I don't recommend at this stage).

Links:
https://www.gracefulsecurity.com/xml-external-entity-injection-xxe-vulnerabilities/
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing

I am about to commit a fix and then release RC6 so people can update promptly.

I don't believe the library is supporting a CSS max-height property. I am new to the library but found the same problem in Flying Saucer when I was using that. I came up with this to fix it:

    private static final class MaxWidthHeightSupportingRenderer extends ITextReplacedElementFactory {
        MaxWidthHeightSupportingRenderer(ITextOutputDevice outputDevice) {
            super(outputDevice);
        }

        @Override
        public ReplacedElement createReplacedElement(LayoutContext c, BlockBox box, UserAgentCallback uac, int cssWidth, int cssHeight) {
            Element e = box.getElement();
            if (e != null && "img".equals(e.getNodeName())) {
                String srcAttr = e.getAttribute("src");

                if (srcAttr != null && srcAttr.length() > 0) {
                    FSImage fsImage = uac.getImageResource(srcAttr).getImage();
                    if (fsImage != null) {
                        if (cssWidth != -1 || cssHeight != -1) {
                            long maxWidth = box.getStyle().asLength(c, CSSName.MAX_WIDTH).value();
                            long maxHeight = box.getStyle().asLength(c, CSSName.MAX_HEIGHT).value();
                            if (cssHeight > maxHeight && cssHeight >= cssWidth) {
                                fsImage.scale(-1, (int) maxHeight);
                            } else if (cssWidth > maxWidth) {
                                fsImage.scale((int) maxWidth, -1);
                            } else {
                                fsImage.scale(cssWidth, cssHeight);
                            }
                        }
                        return new ITextImageElement(fsImage);
                    }
                }
            }
            return super.createReplacedElement(c, box, uac, cssWidth, cssHeight);
        }
    }

I don't know how relevant that is to this project, as I just started using the library and need to learn more about how it works. Excited to see this though!

Any way to use custom font? There is PdfBoxFontResolver, but currently don't see how to add custom font to it.

Support RTL text such as Arabic. I've divided this issue up into the following tasks. Note that Bidi and ArabicShaping classes come from ICU4J. The aim is to provide identical output to Chrome browser with dir="auto" set on html element. The implementation uses interfaces with a do nothing implementation by default to avoid a compulsory dependency on ICU4J.

• Split document up into paragraphs. The owner of each text node is said to be the nearest parent block element.
• Split paragraphs up into directional runs with Bidi::setPara, Bidi::countRuns and Bidi::getVisualRun.
• Determine if a line is predominantly RTL and right align it if it is.
• Also if a line is predominantly RTL, lay its children out from right to left instead of left to right.
• Shape text with ArabicShaping::shape. This will turn isolate characters into begin, middle or end forms depending on position in word.
• Reorder text from RTL to LTR so we can output it with the standard showText instead of character by character backwards. This uses Bidi::writeReverse.
• Deshape characters if the shaped versions are missing in the font.
• Use fallback font in case character still doesn't exist in font. For example latin characters, when using an Arabic font.

I´ve investigated the "#" problem I described in #19 a bit future. The problem is, that   is renderd as '#'. The # comes from the default xhtmlrenderer.conf:

# When rendering text, not all fonts support all character glyphs. When set to true, this
# will replace any missing characters with the specified character to aid in the debugging
# of your PDF.  Currently only supported for PDF rendering.
xr.renderer.replace-missing-characters=false
xr.renderer.missing-character-replacement=#

The character is used as replacement even if xr.renderer.replace-missing-characters=false. It seem no font has a   character. This makes somehow sense, as its visual the same character as a normal space.

Just replacing   (character 160) with ' ' would fix the problem - but it does not feel like a correct fix to me:

--- a/openhtmltopdf-pdfbox/src/main/java/com/openhtmltopdf/pdfboxout/PdfBoxOutputDevice.java
+++ b/openhtmltopdf-pdfbox/src/main/java/com/openhtmltopdf/pdfboxout/PdfBoxOutputDevice.java
@@ -381,6 +332,8 @@ public class PdfBoxOutputDevice extends AbstractOutputDevice implements OutputDe
         for (int i = 0; i < str.length(); ) {
             int unicode = str.codePointAt(i);
             i += Character.charCount(unicode);
+            if( unicode == 160 )
+                unicode = ' ';
             String ch = String.valueOf(Character.toChars(unicode));
             boolean gotChar = false;

Especially because their are more spaces then just space and non-breaking-space. For examples see here https://www.cs.tut.fi/~jkorpela/chars/spaces.html

Unfortunately, this doesn't fix #52

Currently it only works with the document base uri. This means it can not be used for import statements in CSS which should be relative to the CSS document. It is also a mess of code.

Once it is fixed, make sure the CSS parser uses it for import statements instead of bypassing the user agent resolver altogether.

Probably a breaking change.

Considering the following example:

<!DOCTYPE html>
<html>
<meta charset="utf8" />
<head>
</head>
<body>
some long text… (<span class="keyword">example</span>) …some long text… «&nbsp;<span class="keyword">example2</span>&nbsp;» some long text… <i>example3</i>.
</body>
</html>

Firefox, Safari, Chrome will never break between the texts in spans and the (immediate-)surrounding characters.

But, depending on the position of the text, openhtmltopdf may put a line break between:

• "(" and "example" or "example" and ")"
• same between "«"/"»" and "example2"
• same between example3 and "."

This results in not properly formatted text.
The texts here in the spans should be considered as being on the same level as the surrounding text.

More generally, this should probably be the default behavior for any inline tags.

Hello,
is it possible to format html with no ending tags?

something like this html file:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//CZ">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1250">
</HEAD>
<BODY TOPMARGIN="10" MARGINWIDTH="10" LEFTMARGIN="10" MARGINHEIGHT="10" BGCOLOR="White" TEXT="Black">
<FONT FACE="Courier New CE, Courier New, Courier CE, Courier, monospaced">
-------------------------------------------------------------------------<BR>
this is just the test
characters: +ľščťžýáíé <br>
</FONT>
</BODY>
</HTML>

thanks

this is my html.
`

WHITE 白い(default)

but when i run TestcaseRunner, the pdf display
WHITE ##(default)

Hi Danfickle
Currently I using flyingsauser and ITEXT 2.1.2 in my project and I like change those libraries to openhtmltopdf including the pdfbox integration.

I’m interesting to get more information about your release schedule. Is there a plan when this library will be released to a stable version?

Does openhtmltopdf support css3 like this?

.pic-box a.nth-of-type_1 {
    transform: rotate(-6deg);
    -ms-transform: rotate(-6deg);
    -moz-transform: rotate(-6deg);
    -webkit-transform: rotate(-6deg);
    -o-transform: rotate(-6deg);
    z-index: 2;
}

I removed CSS Pseudo-classes because I can got it by CSS2.1

Guys, did anyone try to do this, or thought about it? My current employer needs this feature desperately, willing to offer a compensation for whoever takes on this task.

Hello,

I recently experienced an OutOfMemory error while using the OpenHtmlToPDF framework. Our requirements are rather normal, that is, generating a PDF file out of a simple HTML file which contains only basic CSS 2.0 and XHTML - mainly tables, text and up to three images.

We ran a stress test because the framework should be integrated in our server component, which needs to convert HTML to PDF for our clients. I used a fairly simple for-loop to iterate over HTML files and for each HTML-content, we used OpenHtmlToPDF to generate a PDF file. After about 6000 iterations, the test stopped and a "java.lang.OutOfMemoryError" was shown.

I then took apart all the components, stripped away code step by step to reproduce the OutOfMemoryError with minimal test-code and the result was this simple test case:

@Test
public void test_stressPdfRendererBuilder() throws Exception
{
    int count = 10000;

    String html = FileUtils.readFileToString( new File( "html-with-embedded-jpg.html" ), Charsets.UTF_8 );

    for ( int i = 0; i < count; i++ )
    {
        System.err.println( "i: " + i );

        ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();

        PdfRendererBuilder builder = new PdfRendererBuilder();
        builder.withHtmlContent( html, null );
        builder.toStream( byteArrayOutputStream );

        builder.run();
    }
}

The file html-with-embedded-jpg.html is a simple HTML with a img-Tag with embedded JPEG image (Base64 encoded). You can display that HTML file with the image with any browser.

Running the above test, one can see in the Windows Task Manager, how the occupied memory grows rapidly (interestingly, the Java heap space is doing "ok"). In iteration 5000, it was at ~ 1,6 GB.

After about iteration 6000, the "java.lang.OutOfMemoryError" occurs, with the following stack trace:

java.lang.OutOfMemoryError: Initializing Reader
    at com.sun.imageio.plugins.jpeg.JPEGImageReader.initJPEGImageReader(Native Method)
    at com.sun.imageio.plugins.jpeg.JPEGImageReader.<init>(Unknown Source)
    at com.sun.imageio.plugins.jpeg.JPEGImageReaderSpi.createReaderInstance(Unknown Source)
    at javax.imageio.spi.ImageReaderSpi.createReaderInstance(Unknown Source)
    at javax.imageio.ImageIO$ImageReaderIterator.next(Unknown Source)
    at javax.imageio.ImageIO$ImageReaderIterator.next(Unknown Source)
    at org.apache.pdfbox.pdmodel.graphics.image.JPEGFactory.readJPEG(JPEGFactory.java:103)
    at org.apache.pdfbox.pdmodel.graphics.image.JPEGFactory.createFromStream(JPEGFactory.java:78)
    at com.openhtmltopdf.pdfboxout.PdfBoxOutputDevice.realizeImage(PdfBoxOutputDevice.java:688)
    at com.openhtmltopdf.pdfboxout.PdfBoxUserAgent.getImageResource(PdfBoxUserAgent.java:81)
    at com.openhtmltopdf.pdfboxout.PdfBoxReplacedElementFactory.createReplacedElement(PdfBoxReplacedElementFactory.java:58)
    at com.openhtmltopdf.render.BlockBox.calcMinMaxWidth(BlockBox.java:1524)
    at com.openhtmltopdf.render.BlockBox.calcMinMaxWidthInlineChildren(BlockBox.java:1684)
    at com.openhtmltopdf.render.BlockBox.calcMinMaxWidth(BlockBox.java:1567)
    at com.openhtmltopdf.newtable.TableBox$AutoTableLayout.recalcColumn(TableBox.java:1240)
    at com.openhtmltopdf.newtable.TableBox$AutoTableLayout.fullRecalc(TableBox.java:1214)
    at com.openhtmltopdf.newtable.TableBox$AutoTableLayout.calcMinMaxWidth(TableBox.java:1509)
    at com.openhtmltopdf.newtable.TableBox.calcMinMaxWidth(TableBox.java:158)
    at com.openhtmltopdf.newtable.TableBox.layout(TableBox.java:221)
    at com.openhtmltopdf.layout.BlockBoxing.layoutBlockChild0(BlockBoxing.java:321)
    at com.openhtmltopdf.layout.BlockBoxing.layoutBlockChild(BlockBoxing.java:299)
    at com.openhtmltopdf.layout.BlockBoxing.layoutContent(BlockBoxing.java:90)
    at com.openhtmltopdf.render.BlockBox.layoutChildren(BlockBox.java:990)
    at com.openhtmltopdf.render.BlockBox.layout(BlockBox.java:870)
    at com.openhtmltopdf.render.BlockBox.layout(BlockBox.java:799)
    at com.openhtmltopdf.layout.BlockBoxing.layoutBlockChild0(BlockBoxing.java:321)
    at com.openhtmltopdf.layout.BlockBoxing.layoutBlockChild(BlockBoxing.java:299)
    at com.openhtmltopdf.layout.BlockBoxing.layoutContent(BlockBoxing.java:90)
    at com.openhtmltopdf.render.BlockBox.layoutChildren(BlockBox.java:990)
    at com.openhtmltopdf.render.BlockBox.layout(BlockBox.java:870)
    at com.openhtmltopdf.render.BlockBox.layout(BlockBox.java:799)
    at com.openhtmltopdf.layout.BlockBoxing.layoutBlockChild0(BlockBoxing.java:321)
    at com.openhtmltopdf.layout.BlockBoxing.layoutBlockChild(BlockBoxing.java:299)
    at com.openhtmltopdf.layout.BlockBoxing.layoutContent(BlockBoxing.java:90)
    at com.openhtmltopdf.render.BlockBox.layoutChildren(BlockBox.java:990)
    at com.openhtmltopdf.render.BlockBox.layout(BlockBox.java:870)
    at com.openhtmltopdf.render.BlockBox.layout(BlockBox.java:799)
    at com.openhtmltopdf.pdfboxout.PdfBoxRenderer.layout(PdfBoxRenderer.java:431)
    at com.openhtmltopdf.pdfboxout.PdfRendererBuilder.run(PdfRendererBuilder.java:54)
    ...
    ...

I digged into the code and ended up in PdfBoxOutputDevice.realizeImage(PdfBoxImage) where I found the following lines:

if (img.isJpeg()) {
    xobject = JPEGFactory.createFromStream(_writer,
            new ByteArrayInputStream(img.getBytes()));
} else {
    BufferedImage buffered = ImageIO.read(new ByteArrayInputStream(
            img.getBytes()));

    xobject = LosslessFactory.createFromImage(_writer, buffered);
}

So there is a condition where JPEGFactory.createFromStream is used, if the image is an JPEG, otherwise ImageIO.read is used.

So I changed my test-html-file to embed a PNG instead of an JPEG image - and the OutOfMemory error was gone. Java heap is doing fine, the Windows Task Manager shows only ~ 80 MB memory usage for the Java process no matter how many iterations I run.

Doing a simple seach I came across this:

• http://stackoverflow.com/questions/11052091/pdfbox-out-of-memory-when-adding-image

Maybe there is a problem in PDFBox or in the way, the PDFBox-API is used to integrate an JPEG image into a PDDocument, I'm not sure.

So, the workaround for me is to not use the JPEG image format when embedding an image into the HTML code, but instead using PNG.

I wanted to post this issue here first. I'm sure you know how to debug the code better than me, but I hope I could help a bit with the above information.

Hope to hear from you and that there is an easy fix for it. Or maybe this is a bug in PdfBox eventually.

Thanks a lot!

This comprises the following tasks:

• Implement pluggable URI resolver.
• Implement pluggable cache.
• Make sure all calls for external resources go through the user agent. Specifically: URI resolver -> cache -> http stream.
• Allow vetoing of an external resource call, probably with the URI resolver.
• Allow overriding of the whole user agent.

It doesn't seem to support the font-face way of adding fonts in CSS currently.

Whenever I try to convert an HTML with CDATA sections to PDF, I get a NullPointerException back. If one tries to execute the following snippet:

    PdfRendererBuilder builder = new PdfRendererBuilder();
    builder.toStream(outputStream);
    builder.withHtmlContent("<html><body><div><![CDATA[test]]></div></body></html>", "");
    builder.run();

The following error will occur

Exception in thread "main" java.lang.NullPointerException
    at com.openhtmltopdf.layout.BoxBuilder.doBidi(BoxBuilder.java:1250)
    at com.openhtmltopdf.layout.BoxBuilder.createChildren(BoxBuilder.java:1207)
    at com.openhtmltopdf.layout.BoxBuilder.createChildren(BoxBuilder.java:132)
    at com.openhtmltopdf.render.BlockBox.ensureChildren(BlockBox.java:970)
    at com.openhtmltopdf.layout.BoxBuilder.createChildren(BoxBuilder.java:1199)
    at com.openhtmltopdf.layout.BoxBuilder.createChildren(BoxBuilder.java:132)
    at com.openhtmltopdf.render.BlockBox.ensureChildren(BlockBox.java:970)

This happens because the paragraph splitter doesn't recognize CDATA sections as text. The pull request #15 fixes this issue.

I'm using thymeleaf to process the HTML page that would be then passed to openhtmltopdf to generate a PDF with Arabic content.
the issue if I'm trying to generate using
withHtmlContent(String html, String baseUri)
then:

• the PDF will have #### for any Arabic Content.
• what is baseUri and how I should set it?
• if I just pass the HTML page location using withUri(String uri), Arabic is rendered, the issue with this is I need to process the HTML to be dynamic "generate a purchase order"

check below sample code:

public void generateOpenPDF() throws Exception {
    String htmlContent = "<html xmlns=\"http://www.w3.org/1999/xhtml\"><head><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\"/><style>@font-face{font-family: noto; src: url('NotoNaskhArabic-Regular.ttf');}body, body *{font-family: 'noto', sans-serif;}</style></head><body><div class=\"border\"><h1>عربي</h1></div></body></html>";

   ByteArrayOutputStream os = new ByteArrayOutputStream();
   PdfRendererBuilder builder = new PdfRendererBuilder();
   builder.useUnicodeBidiSplitter(new ICUBidiSplitter.ICUBidiSplitterFactory());
   builder.useUnicodeBidiReorderer(new ICUBidiReorderer());
   builder.defaultTextDirection(TextDirection.RTL); // OR RTL
	    
   builder.withHtmlContent(htmlContent, "/tmp");
        
   builder.toStream(os);
   builder.run();
   byte[] pdfAsBytes = os.toByteArray();
   os.close();
   Path file = Paths.get("/tmp/the-file-name.pdf");
   Files.write(file, pdfAsBytes);
}

I want to set the page header, page footer and page number, even to choose a picture as the background. How can i do that please?

Currently, SVG images are not supported. PDFBox does not "draw" SVGs natively. Best practice is, to use apache batik to transcode SVGs to PDFs and embed these as PDFFormXObject via PDFBox.

_See also _

• SVGs via batic in PDFBox: https://www.mail-archive.com/[email protected]/msg06998.html
• Transcoding SVGs with batic: http://stackoverflow.com/questions/6875807/convert-svg-to-pdf

Currently fonts in font-face rules or fonts added programmatically are automatically downloaded even if they are never used. They don't make it into the PDF, but most browsers don't download unused fonts and we should aim to copy this behavior.

This will be a possibly breaking change, because currently if a font-weight or font-style isn't provided in the font-face rule, the font is processed and these values are taken from the font data. That will clearly be impossible if we do not download the font until we get a match.

Note that non subset fonts will continue to be embedded even if they are not used.