IronPDF와 제품 비교

The documentation for the product is what will make or break it in the long-term with developers. As they dive in and need more advanced features, how quickly can they find that material and are there samples provided that help teach these concepts.

In each of these products, I searched their API documentation for the ability to add digital signatures to a PDF.

IronPDF

The API documents are clear and well organized with a left panel table-of-contents with a live filter. The search box in the top-right also includes a live filter and quickly returned several articles about the various components that provide Signature features. The API site has a light and dark mode, a nice feature developers prefer.

Figure 15 - IronPDF API Search Results for Signature

The PdfSignature class document describes the object but does not include any links to sample code. I searched the ironpdf.com website for "signature" and found sample code that references the PdfSignature object at IronPDF Digitally Sign a PDF Example.

Aspose

The Aspose API docs linked me to their PdfFileSignature class when I searched for Signature. This page, like IronPDF's, shows the details of the PdfFileSignature class, but does not include any links to demos or describe how to use the class.

I returned to the Aspose documentation base page at Aspose PDF for .NET Documentation and searched for signature. I was then presented with a list of relevant articles and clicked through to the 'Add Signature in PDF file" article at Aspose Add Signature in PDF.

SyncFusion

SyncFusion's base documentation page for the PDF file formats product is at Syncfusion PDF File Formats Overview and took a few clicks through their site to find it. I didn't have to look far to find the signature sample as the front page of the documentation.

There are no API documents that support the digital signature feature available on the SyncFusion site.

iText

The API documentation for iText is very thorough and generated from each released version. It's a standard look and feel that you'll see from other libraries on the internet. Searching for a signature found a few classes with some great descriptions around those features, but again no links to samples.

I searched the iText website for a Signature sample and was not able to locate one, and instead was presented with several blog articles announcing new partnerships.

The API made available by each of the tools is very descriptive and each takes its own approach to giving the developer full access to creating and managing the content of a PDF document. Thankfully, all of the frameworks have complete autocomplete hints that provide great in-line documentation as you work with their tools in a modern code editor like Visual Studio or Visual Studio Code that provides autocomplete capabilities.

IronPDF

The IronPDF APIs make very difficult and complex interactions easy to do with simplified commands like "RenderHtmlAsPdf", but still provide deep access to the creation and placement of content, security, metadata, and forms of the document. As a developer, these APIs "speak to the way that I think" about rendering content.

The names and terms used by the IronPDF APIs make it clear you are rendering a document or building a document. Time properties on some of the settings are integers representing milliseconds where I would have preferred a native TimeSpan type. Finally, I would like to see Settings and Options types provided with a modern fluent configuration API like this:

var renderer = new IronPdf.ChromePdfRenderer(options => {
    options.RenderDelay = TimeSpan.FromSeconds(1);
});

var renderer = new IronPdf.ChromePdfRenderer(options => {
    options.RenderDelay = TimeSpan.FromSeconds(1);
});

SyncFusion

SyncFusion APIs are clear and give very descriptive control over how to interact with their converter tools. There are no shortcuts here, everything is required, and you must tell it which tools you are using with no defaults available. The Settings are extensive with fine-grained control over everything, including the location of the WebKit renderer on disk.

This extra configuration, while not needed in some installations, has caused problems for folks in the past and in future versions SyncFusion promises is not a problem.

Aspose

The Aspose API is extremely verbose and it makes me wonder if they are trying to make developers more productive at all. The amount of configuration needed to load a document from a website is astounding, ten lines of code or twice as many lines as SyncFusion (five).

One example of this is that Aspose doesn't have APIs to allow you to specify a URL to fetch and convert.

iText

iText has a similar API to Aspose, very verbose and allows direct interaction with writing into the document with different data types, but it's not clear how to create sections of the document. With how explicit the APIs are and the low quality of the documentation, working with iText is difficult at best.

The reference website is very simple with no CSS and just text with links and images.

Figure 16 - The reference website for Static Web Tests

IronPDF

This was a simple three lines of code to execute, and the performance looked good at 835ms. However, when I opened the PDF, I found that none of the images were included in the rendering, a disappointing result with the default configuration.

After a little exploring, I learned that I could add a render delay, and with this configuration, I was able to render a PDF that included the proper images on the page.

With the test version of the tool, there is a watermark that is included in the rendered PDF. In the fully licensed version, this watermark is not present.

Figure 17 - IronPDF Rendering of the Static Site

SyncFusion

SyncFusion was a curious and confusing trip. Their documentation refers to several different ways to render and deliver HTML and PDF with different version numbers and different frameworks requiring different code and configurations as well as installs of binary tools in order to function properly.

Like the IronPDF demo, SyncFusion did not render the images for the page and delivered a PDF with very small margins.

With the test version of the tool, there is a watermark that is included in the rendered PDF. In the fully licensed version, this watermark is not present.

Figure 18 - SyncFusion Rendering of the Static Site.

Aspose

Aspose has a very clear set of directions about how to use their tools. However, based on the instructions on their website for converting a website to a PDF, they have a significant bug that prevents the feature from working. Additionally, their online tool that converts a website to a PDF no longer functions.

iText

iText's documentation is not as easy to find, and we had to read an eBook to get the sample code we were looking for to run this sample. With no code changes, no additional configuration and four lines of code we rendered a very good-looking PDF with no watermarks and good margins.

Figure 19 - iText Rendering of the Static Site.

For this test, we're using ESPN.com, a sports website that has a lot of CSS, images, and JavaScript on the page. Given that Aspose did not function for the simple test, we will skip them going forward. We will use the same code that we utilized for the last demo to create these captures, just substituting the website address.

For reference, here is the appearance of ESPN at the time of this test:

Figure 20 - Full rendering of ESPN.com in the browser

The scores on the top and the report of the state of the game in the middle of the screen are placed with JavaScript, and all positioning and colors are handled with CSS3.

IronPDF

The IronPDF rendering was able to faithfully duplicate and load the dynamic content, however, it appears as though the page was rendered for a mobile device with content elements broken out into separate segments and tiled.

Figure 21 - IronPDF Rendering of ESPN

SyncFusion

SyncFusion performed a similar 'mobile style' rendering with content tiled vertically. However, we have lost several images that were dynamically loaded by the ESPN site and some of the font formatting is also lost:

Figure 22 - SyncFusion rendering of ESPN

iText

For this test, iText refused to run and was throwing a NullReferenceException, preventing it from attempting to render the website.

The final test is to generate a PDF with form entry fields based on a website. The simple newsletter sign-up form I wrote is available in the GitHub repository and renders with Bootstrap 5 in Firefox like so:

Figure 23 - Form Website in Firefox

Note: the State is a combobox, the Phone field is a telephone field, the Email is an email field, and the Shoe Size is a number field.

IronPDF

Iron really shines in this test, rendering quickly in a similar mobile-friendly layout as evidenced by the hamburger menu button in the top right. The watermarks across the page are annoying in a test version, but removed in the fully licensed version.

All of the textbox fields are rendered as PDF form fields that I can interact with, except for the radio buttons and checkbox at the end. The textboxes have no particular validation or content enforcement on them as they do in the browser.

Figure 24 - IronPDF Rendering of the Form

SyncFusion

SyncFusion rendered what appears to be the full desktop version of the website, as there is no hamburger menu button present. The form elements rendered appear as the squares, buttons, and boxes on the screen but none of them are standard PDF data entry fields. The links on the header and footer, while obscured by the watermark, are clickable.

Figure 25 - Form site rendered by SyncFusion

iText

iText was easily the fastest of the three frameworks at rendering the content. However, that speed came at a price. Their rendering did deliver anchor tags that navigated when clicked, but did not reach the original website. All formatting from bootstrap was lost, and all form fields were rendered as plain boxes.

Figure 26 - Form site rendered by iText