Non-Local File URLs

By default PDFreactor now blocks all file URLs with any non-empty authority components other than exactly "localhost". This is to prevent Java-specific behavior which could be used by potentially malicious authors to gain information about the server's OS or available network resources.

Examples of file URLs and how they are now treated by PDFreactor 12:

• file:///dir/file → valid
• file://host/dir/file → invalid
• file://localhost/dir/file → valid
• file://LOCALHOST/dir/file → invalid
• file://localhost:8080/dir/file → invalid
• file://john:doe@localhost/dir/file → invalid

To achieve the behavior of PDFreactor versions below 12, you need to allow non-remote file URLs in the security settings. Please refer to the PDFreactor manual for more information on this subject.

Access to PDF Output Options

By default, PDFreactor now prevents access to the PDF output options that can be specified in JavaScript via the ro.pdf object. Attempts to access that object will result in an error. This is to prevent potentially malicious authors from altering critical configuration options, such as PDF encryption or PDF script. To re-enable access, use the allowAuthorApiOverrides security setting.

JavaScript Engine

PDFreactor 12 uses a JavaScript implementation based on the JavaScript engine Oracle GraalJS. Previous versions used Mozilla Rhino as JavaScript engine and that engine can still be enabled via a setting. However, we recommend to only use it as a temporary solution for the rare cases when it supports scripts that GraalJS does not yet handle correctly.

config.setJavaScriptSettings(new JavaScriptSettings()
.setJavaScriptEngine(JavaScriptEngine.RHINO));

Note: The included JavaScript library awesomizr.js now requires the use of GraalJS. However, you can use a previous version of that library if you require Rhino.

JavaScript Enabled by Default

JavaScript processing is now enabled by default. It can be disabled via the API:

config.setJavaScriptSettings(new JavaScriptSettings()
.setDisabled(true));

Required Java Versions for JavaScript Processing

JavaScript processing with the GraalJS engine requires at least Java 17 while the Rhino engine only requires Java 8. (Using the PDFreactor Web Service also raises the requirement to Java 17.)

Deprecated API

The following configuration properties are deprecated and have either been moved into another object or replaced:

• allowAnnotations → moved to encryptionSettings
• allowAssembly → moved to encryptionSettings
• allowCopy → moved to encryptionSettings
• allowDegradedPrinting → moved to encryptionSettings
• allowFillIn → moved to encryptionSettings
• allowModifyContents → moved to encryptionSettings
• allowPrinting → moved to encryptionSettings
• allowScreenReaders → moved to encryptionSettings
• authenticationCredentials → moved to networkSettings and changed data type (see below)
• cookies → moved to networkSettings
• encryption → moved to encryptionSettings and renamed to type
• httpsMode → replaced by securitySettings.trustAllConnectionCertificates (see below)
• mergeDocuments → moved to mergeSettings and renamed to documents
• mergeMode → moved to mergeSettings and renamed to mode
• overlayRepeat → moved to mergeSettings
• ownerPassword → moved to encryptionSettings
• rawCookies → obsolete; use networkSettings.cookies instead
• requestHeaders → moved to networkSettings
• resourceConnectTimeout → moved to networkSettings and renamed to connectTimeout
• resourceReadTimeout → moved to networkSettings and renamed to readTimeout
• userPassword → moved to encryptionSettings

New Log Levels

PDFreactor 12 now uses custom log levels consistently throughout its API and in the logs.

FATAL

SEVERE

FATAL

ERROR

WARN

WARNING

WARN

INFO

INFO

INFO

DEBUG

CONFIG

DEBUG

DEBUG

FINE

DEBUG

FINER

PERFORMANCE

FINEST

TRACE

Note that log level TRACE in particular should never be used in production as it may produce a large amount of records and enable additional analysis features which may impact performance.

Document Type Detection

The automatic document type detection now takes file extensions, XML declarations and certain elements of the doctype preamble into account to find a suitable document type, and thus the detection decides which document parser should be used.

If a different parser is used and this causes unwanted changes, then the document type has to be forced to the previously used type via the configuration property documentType. The used document type can be found in the PDFreactor log on the level INFO.

Color Space Conversion for Image Output

Conversion to CMYK is now supported for image output. This also means that for image formats that don't support CMYK an exception will be thrown when CMYK conversion is specified via the ColorSpaceSettings.

config.setColorSpaceSettings(null);

Barcode API

-ro-barcode-human-readable-position: none;

Visibility of noscript Elements

The HTML element noscript is now handled properly and will be made visible when JavaScript has been disabled, instead of being always set to display:none. In order to restore the previous behavior, the display style of the elements has to be set manually:

noscript {
    display: none;
}

Fragmentation of Flex Containers with Height

Multi-line flex containers with a non-auto height no longer prevent fragmentation and are now allowed to be split between their flex lines (just like flex containers with an auto height). The previous behavior can be restored by setting overflow: scroll on the flex container, thus making the flex container monolithic and preventing any breaks:

.flex {
    overflow: scroll;
}

Note that while there are no scrollbars in the resulting PDF, browsers would display them, so this style should only be applied during the conversion. When setting the style via the PDFreactor API is not an option, this can be achieved in style sheets by using the media rule @media -ro-pdfreactor.

Default Vertical Align in Fast Tables

PDFreactor 12 adds support for the vertical-align property to Fast Tables, specifically for the values bottom and middle, treating all others as top. This means that the default value for HTML table cells, i.e. middle, is now respected, changing the default alignment visibly when cell heights are larger than the font heights.

table.fastTable td,
table.fastTable th {
    vertical-align: top;
}

New Media Feature Default Values

Some default values that PDFreactor uses to resolve media features have been changed to more accurately represent the output:

• resolution has been changed from 2dppx to 300dpi
• width and height have been changed to be based on A4 with a 2cm margin instead of only 1cm, i.e. a change from 190 × 277mm to 170 × 257mm.
• color was previously always 8 and now depends on whether a grayscale or monochrome image output has been specified, in which case it is set to 0.
• color-index was previously always 0, but is now 256 if the output has been set to the image format gif.
• monochrome was previously always 0, but is now 8 when forceGrayscaleImage has been set and 1 if a monochrome tiff variant has been chosen as output format.

Should any problems arise from these new values, the previous ones can be restored via the API. For example:

config.setMediaFeatureValues(
    new MediaFeatureValue().setMediaFeature(MediaFeature.RESOLUTION).setValue("2dppx"));

Absolutely Positioned Elements inside Multi-column

In previous versions, the containing block of elements with position:absolute inside a multi-column element was the column itself, thus placing it relative to the column. In PDFreactor 12 the columns are no longer containing blocks for absolutely positioned elements, as is demanded by the CSS specifications.

The new value column has been introduced for the proprietary property -ro-position-origin which allows to restore the original behavior:

.pos-abs {
    -ro-position-origin: column;
}

Fragmentation of Table Captions

Table captions can not be distributed over multiple fragmentation containers (pages, columns, etc.) anymore. They are now monolithic and considered as a coherent unit. Forced breaks inside them do not have an effect anymore. The behavior of PDFreactor 11 can not be restored via pure CSS. If the old behavior is necessary then the table caption element should be removed from the table and placed before or after the table and the display value of the caption should be set to block.

Baseline of Images

The baseline of images is now the bottom margin edge, instead of the bottom border edge.

Image Clipping Paths are Now Disabled by Default

To match the browser behavior, any clip path stored in the meta data of images is now ignored by default. To reactivate them, the proprietary CSS property -ro-image-clip-path can be set to auto or from-image.

img, .background-image {
    -ro-image-clip-path: auto;
}

Footnotes on column- or region-level

Footnotes are now always placed on page-level by default. In order to place footnotes on column- or region-level the property -ro-float-reference can be used.

.multiColumn .footnote {
    -ro-float-reference: column;
}
.regionElement .footnote {
    -ro-float-reference: region;
}

Default Image Interpolation

Unless prohibited by conformance, image interpolation is now enabled by default. For PDF output this differs from previous behavior where the interpolation flag was never set. The previous behavior can be restored using the property image-rendering:

* {
    image-rendering: pixelated;
}

Comment Properties

To create PDF comments, you now have to specify at least one of the following CSS properties: -ro-comment-content, -ro-comment-style, -ro-comment-start, or -ro-comment-end. In the rare case where you want to create comments and don't need either of these properties, it is recommended to specify an empty string as the value for -ro-comment-content to create the comment:

.comment {
    -ro-comment-content: "";
}

Inherited Rasterization Properties

The properties -ro-rasterization, -ro-rasterization-supersampling and -ro-rasterization-max-size are now inherited. So to e.g. not increase the resolution of an SVG in a paragraph with text shadow you have to to reset the value for that SVG:

<p>Hello <i>World</i> <img src="some.svg"></p>

p {
    text-shadow: 2pt 3pt 4pt red;       /* both are inherited ... */
    -ro-rasterization-supersampling: 4; /* ... so they affect i and img as well */
}
img {
    -ro-rasterization-supersampling: initial; /* undo the effect on img */
}

Printer Marks

The default position (offset) of crop marks and color bars has changed. The inner side of both marks now is located at the outer edge of the bleed area (offset = 100% of bleed). In order to undo this change and to obtain the old behavior the following CSS can be used:

@page {
    -ro-colorbar-offset: calc(100% + 5mm / 3); /* 100% bleed + colorBarSize / 3 */
    -ro-crop-mark-offset: 66%;                 /* 66% of bleed */
}

Explicit Value of List Items

The proprietary CSS property -ro-listitem-value has been deprecated. The functionality of this property is to explicitly set the value of a list item. Since PDFreactor 12 list items are based on CSS counters. Because of this the value of list items should from now on be manipulated with the corresponding counter properties counter-set, counter-reset and counter-increment only. For backwards compatibility the -ro-listitem-value property now is a shorthand for the counter-set property. It can still be used but it is recommended to adjust all occurrences similar to the following example:

.listItem10 { -ro-listitem-value: 10 }     /* old */
.listItem10 { counter-set: list-item 10 }  /* new */

Creation of Page Margin Boxes

The creation of page margin boxes is now only possible if the content property is not none. The possibility to create a page margin box via width and height only (and no content property) is no longer possible. If a style sheet contains such page margin box rules then the content property must be added as otherwise the boxes will not be created. The following example demonstrates this:

/* old behavior (no content property is necessary) */
@top-center {
    width: 100%;
    height: 100%;
}

/* new behavior (content property is required) */
@top-center {
    content: "";
    width: 100%;
    height: 100%;
}

Generated content on replaced elements

In order to be compatible with the CSS specification and the behavior of browsers, generated content on images is no longer supported (e.g. "img::before"). If this functionality is still required, it can be simulated using JavaScript by inserting elements before or after a replaced element.

PDF Script Actions Set from CSS

The proprietary CSS property pdf-script-action, applicable in @-ro-preferences, has been removed. You can still set PDF script actions via the API configuration property PdfScriptAction or, if enabled, in JS, using ro.pdf.pdfScriptActions.

Links in PDFs Used as Images

PDFs used as images now contain the external links from the source document. To disable this new behavior the following style has been introduced:

.no-links {
    -ro-image-interactivity: none;
}

Artifact Names

PDFreactor traditionally comes in two JAR variants: A monolithic JAR containing all dependencies and a modular JAR without any dependencies. This remains the same in PDFreactor 12 but we renamed the JAR artifacts because we consider the modular JAR now the standard.

pdfreactorcore.jar

pdfreactor.jar

lib

pdfreactor.jar

pdfreactor-uber.jar

lib/uber-jar

Runtime JVM

Support for Java versions 8 to 16 is deprecated. Future versions of PDFreactor will require Java 17+.

Usage of certain features like JavaScript processing with the new default engine already requires Java 17.

Working Directory of the Command Line Wrapper

The working directory for the PDFreactor command line wrapper (pdfreactor-cmd on macOS and Linux, pdfreactor-cmd.exe on Windows systems) is now the current working directory instead of the directory where the command line wrapper is located.

As such certain paths (such as the PDF output directory) are now resolved relative to the current working directory instead of the command line wrapper location.

Java Command Line API

In PDFreactor 12, Java Command Line arguments should now be specified in kebab-case notation instead of the previous camel-case notation, i.e. use --disable-bookmarks instead of --disableBookmarks.

The old notation is still supported but is considered deprecated, and will thus be removed in a future version.

In addition, following the deprecation of several configuration properties, their matching command line arguments have been removed. Other arguments have been added to retain the old functionality, but their names now more closely resemble their configuration counterparts. Use the -h argument to get a full list of supported arguments.

• --allowAnnotations → --encryption-allow-annotations
• --allowAssembly → --encryption-allow-assembly
• --allowCopy → --encryption-allow-copy
• --allowDegradedPrinting → --encryption-allow-degraded-printing
• --allowFillIn → --encryption-allow-fill-in
• --allowModifyContents → --encryption-allow-modify-contents
• --allowPrinting → --encryption-allow-printing
• --allowScreenReaders → --encryption-allow-screen-readers
• --encryption → --encryption-type
• --httpsMode → replaced by -k, --insecure, or --security-trust-all-connection-certificates
• --mergeDocuments → --merge-documents
• --mergeMode → --merge-mode
• --overlayRepeat → --merge-overlay-repeat
• --ownerPassword → --encryption-owner-password
• --resourceConnectTimeout → --network-connect-timeout
• --resourceReadTimeout → --network-read-timeout
• --userPassword → --encryption-user-password

Font Cache

In previous versions, PDFreactor automatically created a file system font cache in the user's home directory if no other location was specified. Depending on the integration scenario, that home directory may not exist. So to achieve consistent behavior, the cache is now disabled by default..

config.setCacheFonts(true);

Runtime JVM

The PDFreactor Web Service now uses Jetty 12 and requires Java 17 or higher to run.

Servlet Compatibility

The PDFreactor 12 Web Service is now only compatible with Jakarta Servlet 5.0, dropping support for all earlier Java EE Servlet specifications.

Binary Response Content Types

In previous versions, various REST resources of the PDFreactor Web Service responded with the value application/octet-stream for the Content-type header if this type was specifically requested either via Accept header or .bin file extension. In PDFreactor 12, the service will now always use the actual binary media type for the Content-type header, such as application/pdf or image/jpeg, in lieu of the generic application/octet-stream.

Integrators that rely on the Content-type response header's value specifically being application/octet-stream need to adjust their integration since that media type is no longer a possible value.

Location of Custom Config Files

With PDFreactor 12, the directory structure of the installed resources was changed. PDFreactor Web Service-related resources are now located in the jetty-base-pdfreactor subdirectory. To accommodate the changes made by Jetty 12, the jetty directory was renamed to jetty-base-pdfreactor. So if you've made any changes or added custom .ini files, you may have to migrate those files to the following new locations:

• PDFreactor/jetty/start.ini →
  PDFreactor/jetty-base-pdfreactor/start.d/start.ini
• PDFreactor/jetty/start.d/*.ini →
  PDFreactor/jetty-base-pdfreactor/start.d/*.ini

When upgrading an existing PDFreactor installation using an installer, the old PDFreactor/jetty directory will remain and you have to manually migrate any custom config files to PDFreactor/jetty-base-pdfreactor.

JavaScript Client

The JavsScript Client is now an ES6 module and can be found under module/pdfreactor.js. Further, PDFreactor and other types are now classes.

<script src="lib/PDFreactor.js">
    var pdfReactor = new PDFreactor();
    
    try {
        await pdfReactor.convert(config);
        // ...
    } catch (PDFreactor.PDFreactorWebserviceError e) {
        // ...
    }                        
</script>

<script type="module">
    import { PDFreactor, PDFreactorWebserviceError } from './module/pdfreactor.js';
    
    const pdfReactor = new PDFreactor();
    
    try {
        await pdfReactor.convert(config);
        // ...
    } catch (PDFreactorWebserviceError e) {
        // ...
    }                        
</script>

Please refer to the JavaScript Client samples for more complex integrations.

Should ES6 modules be incompatible with your integration, feel free to use the PDFreactor 11 JavaScript Client, which remains compatible with PDFreactor 12.

Node.js Client

The Node.js Client is now an ES6 module and can be found under module/pdfreactor.mjs. Further, PDFreactor and other types are now classes.

The PDFreactor module now requires Node 18 and relies on the fetch API. It uses the native Node fetch implementation if available, otherwise it falls back on the node-fetch module. So please make sure either one is available. If the native fetch implementation is available, you can omit the module/fetch-polyfill.mjs file.

var pdfReactor = new PDFreactor();

try {
    await pdfReactor.convert(config);
    // ...
} catch (PDFreactor.PDFreactorWebserviceError e) {
    // ...
}

import { PDFreactor, PDFreactorWebserviceError } from './module/pdfreactor.mjs';

const pdfReactor = new PDFreactor();

try {
    await pdfReactor.convert(config);
    // ...
} catch (PDFreactorWebserviceError e) {
    // ...
}

Please refer to the Node.js Client samples for more complex integrations.

Should ES6 modules be incompatible with your integration, feel free to use the PDFreactor 11 Node.js Client, which remains compatible with PDFreactor 12. Alternatively, you can use an ES6 module within a CommonJS module like this:

(async () => {
    const { PDFreactor, PDFreactorWebserviceError } = await import('../module/pdfreactor.mjs');
    const pdfReactor = new PDFreactor();
    
    try {
        await pdfReactor.convert(config);
        // ...
    } catch (PDFreactorWebserviceError e) {
        // ...
    }
})();

PHP Client

PDFreactor 12 comes with a new version of the PHP client (client version 12) which requires cURL to be installed on the client's host system. The old client (client version 8) is compatible with PDFreactor 12 and can still be used, but it may lack certain new features.

Python Client

The Python client (client version 12) now requires Python 3.10. Support for Python 2 was dropped.

Perl Client

PDFreactor 12 no longer contains a Perl Client. You can continue to use the PDFreactor 11 Perl Client with PDFreactor 12, however we no longer offer any support for it from PDFreactor 12 onwards.

JavaScript/Node.js

try {
    // ...
} catch (e) {
    if (e instanceof PDFreactor.PDFreactorWebserviceError) {
        // Since 'e' is now an object, use 'e.message' to access the error message
        // ...
    }
}

PHP

try {
    // ...
} catch (Exception $e) {
} catch (PDFreactorWebserviceException $e) {
    // ...
}

Python

try:
    # ...
except Exception as e:
except PDFreactorWebserviceException as e:
    # ...
}

Ruby

begin
    # ...
rescue Exception => error
rescue PDFreactor::PDFreactorWebserviceError => error
    # ...
}

Perl

eval {
    # ...
} || do {
    if ($e->isa("PDFreactor::PDFreactorWebserviceException")) {
        # ...
    }
}

signPDF

When digitally signing a PDF using the signPDF configuration property, PDFreactor will now throw an exception and thus fail the conversion if the PDF could not be signed. Appropriate log entries as well as exception messages will provide information as to the reason.

Old API

config.setAttachments(new Attachment(null, "http://myAttachment.zip", null, null));
config.setUserStyleSheets(new Resource("p { color: red; }", null));

New API

config
    .setAttachments(new Attachment().setUri("http://myAttachment.zip"));
    .setUserStyleSheets(new Resource().setContent("p { color: red; }"));

Old API

config.Attachments.Add(new Attachment(null, "http://myAttachment.zip", null, null));
config.UserStyleSheets.Add(new Resource("p { color: red; }", null));

New API

config.Attachments.Add(new Attachment { Uri = "http://myAttachment.zip" });
config.UserStyleSheets.Add(new Resource { Content = "p { color: red; }" });

Old API

// merge single document from binary source
config.setMergeByteArray(byteArray1);
// merge multiple documents from binary source
config.setMergeByteArrays(byteArray1, byteArray2);
// merge single document from URL source
config.setMergeByteURL(url1);
// merge multiple documents from URL source
config.setMergeByteURLs(url1, url2);

New API

// merge single document from binary source
config.setMergeDocuments(new Resource().setData(byteArray1));
// merge multiple documents from binary source
config.setMergeDocuments(new Resource().setData(byteArray1),
        new Resource().setData(binary2));
// merge single document from URL source
config.setMergeDocuments(new Resource().setUri(url1));
// merge multiple documents from URL source
config.setMergeDocuments(new Resource().setUri(url1),
        new Resource().setUri(url2)));

The ScriptResource type is now deprecated, use Resource instead. This change only affects Java and .NET APIs.

Old API

PDFreactor pdfReactor = new PDFreactor();

// simple settings
pdfReactor.setAddBookmarks(true);
pdfReactor.setAddLinks(true);

// adding a user style sheet
pdfReactor.addUserStyleSheet("p { color: red }", null, null, null);

// create PDF and specify the document
byte[] pdf = pdfReactor.renderDocumentFromURL("https://www.realobjects.com");

New API

PDFreactor pdfReactor = new PDFreactor();
Configuration config = new Configuration();

// specify the document
config.setDocument("https://www.realobjects.com");

// simple settings
config.setAddBookmarks(true);
config.setAddLinks(true);

// adding a user style sheet
config.getUserStyleSheets().add(new Resource("p { color: red }", null));

// create PDF
Result result = pdfReactor.convert(config);
byte[] pdf = result.getDocument();

Old API

PDFreactor pdfReactor = new PDFreactor();

// simple settings
pdfReactor.SetAddBookmarks(true);
pdfReactor.SetAddLinks(true);

// adding a user style sheet
pdfReactor.AddUserStyleSheet("p { color: red }", "", "", "");

// create PDF and specify the document
byte[] pdf = pdfReactor.RenderDocumentFromURL("https://www.realobjects.com");

New API (Changed in version 8.1)

PDFreactor pdfReactor = new PDFreactor();
Configuration config = Configuration();

// specify the document
config.Document = "https://www.realobjects.com";

// simple settings
config.AddBookmarks = true;
config.AddLinks = true;

// adding a user style sheet
config.UserStyleSheets = new List<Resource> {new Resource("p { color: red }", "")};

// create PDF
Result result = pdfReactor.Convert(config);
byte[] pdf = result.Document;

Old API

$pdfReactor = new PDFreactor();

// simple settings
$pdfReactor->setAddBookmarks(true);
$pdfReactor->setAddLinks(true);

// adding a user style sheet
$pdfReactor->addUserStyleSheet("p { color: red }", "", "", "");

// create PDF and specify the document
$result = $pdfReactor->renderDocumentFromURL("https://www.realobjects.com");

New API

$pdfReactor = new PDFreactor();
$config = array(
    // specify the document
    "document" => "https://www.realobjects.com",
    
    // simple settings
    "addBookmarks" => true,
    "addLinks" => true,
    
    // adding a user style sheet
    "userStyleSheets" => array(
        array(
            "content"=> "p { color: red }"
        )
    )
);

// create PDF
// ...as base64 encoded String
$result = $pdfReactor->convert($config);
$pdf = $result->document;

// ...as binary
$pdf = $pdfReactor->convertAsBinary($config);

To convert the base64 encoded document into binary data, you can do the following:

echo base64_decode($result->document);

Old API

pdfReactor = PDFreactor()

# simple settings
pdfReactor.setAddBookmarks(True)
pdfReactor.setAddLinks(True)

# adding a user style sheet
pdfReactor.addUserStyleSheet("p { color: red }", "", "", "")

# create PDF and specify the document
result = pdfReactor.renderDocumentFromURL("https://www.realobjects.com");

New API

pdfReactor = PDFreactor()
config = {
    # specify the document
    'document': "https://www.realobjects.com",
    
    # simple settings
    'addBookmarks': True,
    'addLinks': True,
    
    # adding a user style sheet
    'userStyleSheets': [
        {
            'content': "p { color: red }"
        }
    ]
}

# create PDF
# ...as base64 encoded String
result = pdfReactor.convert(config)
pdf = result['document']

# ...as binary
pdf = pdfReactor.convertAsBinary(config)

To convert the base64 encoded document into binary data, you can do the following:

import base64
print(base64.b64decode(result['document']))

Old API

pdfReactor = PDFreactor.new();

# simple settings
pdfReactor.setAddBookmarks(true)
pdfReactor.setAddLinks(true)

# adding a user style sheet
pdfReactor.addUserStyleSheet("p { color: red }", "", "", "")

# create PDF and specify the document
result = pdfReactor.renderDocumentFromURL("https://www.realobjects.com")

New API

pdfReactor = PDFreactor.new()
config = {
    # specify the document
    document: "https://www.realobjects.com",
    
    # simple settings
    addBookmarks: true,
    addLinks: true,
    
    # adding a user style sheet
    userStyleSheets: [
        {
            content: "p { color: red }"
        }
    ]
}

# create PDF
# ...as base64 encoded String
result = pdfReactor.convert(config)
pdf = result["document"]

# ...as binary
pdf = pdfReactor.convertAsBinary(config)

To convert the base64 encoded document into binary data, you can do the following:

require "base64"
print Base64.decode64(result["document"])

Old API

my $pdfReactor = PDFreactor -> new();

# simple settings
$pdfReactor -> setAddBookmarks('true');
$pdfReactor -> setAddLinks('true');

# adding a user style sheet
$pdfReactor -> addUserStyleSheet("p { color: red }", "", "", "");

# create PDF and specify the document
$result = pdfReactor -> renderDocumentFromURL("https://www.realobjects.com");

New API

my $pdfReactor = PDFreactor -> new();
$config = {
    # specify the document
    'document' => "https://www.realobjects.com",
    
    # simple settings
    'addBookmarks' => 'true',
    'addLinks' => 'true',
    
    # adding a user style sheet
    'userStyleSheets' => [
        {
            'content' => "p { color: red }"
        }
    ]
};

# create PDF
# ...as base64 encoded String
$result = $pdfReactor -> convert($config);
$pdf = $result->{'document'};

# ...as binary
$pdf = $pdfReactor -> convertAsBinary($config);

To convert the base64 encoded document into binary data, you can do the following:

use MIME::Base64 ();
print MIME::Base64::decode($result->{'document'});