IronPDF를 이용한 제품 비교

제품의 문서는 장기적으로 개발자에게 성공 여부를 결정짓습니다. 그들이 더 고급 기능이 필요할 때, 얼마나 빨리 해당 자료를 찾을 수 있는지와 이러한 개념을 가르치는 데 도움이 되는 샘플이 제공되는지 확인합니다.

이 제품들 각각에서, PDF에 디지털 서명을 추가할 수 있는 기능을 API 문서에서 검색했습니다.

IronPDF

API 문서는 명확하고 잘 구성되어 있으며, 왼쪽 패널에는 실시간 필터가 포함된 목차가 있습니다. 오른쪽 상단의 검색 상자에도 실시간 필터가 포함되어 있고, 서명 기능을 제공하는 다양한 구성 요소에 대한 여러 기사를 신속하게 반환했습니다. API 사이트에는 개발자가 선호하는 라이트 및 다크 모드가 있는 멋진 기능이 있습니다.

그림 15 - IronPDF API 서명 검색 결과

PdfSignature 클래스 문서는 객체를 설명하지만 샘플 코드에 대한 링크는 포함되어 있지 않습니다. ironpdf.com 웹사이트에서 'signature'를 검색해서 IronPDF Digitally Sign a PDF Example에서 PdfSignature 객체를 참조하는 샘플 코드를 찾았습니다.

Aspose

Aspose API 문서는 서명을 검색했을 때 PdfFileSignature 클래스에 연결되었습니다. 이 페이지는 IronPDF의 것처럼 PdfFileSignature 클래스의 세부사항을 보여주지만, 데모에 대한 링크를 포함하지 않거나 클래스를 사용하는 방법을 설명하지 않습니다.

Aspose 문서 기본 페이지로 돌아가 Aspose PDF for .NET 문서에서 서명을 검색했습니다. 관련 기사 목록이 표시되었고 Aspose Add Signature in PDF 기사로 이동했습니다.

Syncfusion

Syncfusion의 PDF 파일 형식 제품에 대한 기본 문서 페이지는 Syncfusion PDF File Formats Overview에 있으며, 사이트를 몇 번 클릭해서 찾았습니다. 문서의 첫 페이지에 이미 서명 샘플을 찾기 위해 멀리 찾아볼 필요가 없었습니다.

Syncfusion 사이트에는 디지털 서명 기능을 지원하는 API 문서가 없습니다.

iText

iText의 API 문서는 매우 철저하며 각 버전이 릴리스될 때마다 생성됩니다. 인터넷의 다른 라이브러리에서 볼 수 있는 표준적인 외관과 느낌입니다. 서명을 검색했을 때 해당 기능에 대한 훌륭한 설명이 있는 몇 가지 클래스를 찾았지만, 여전히 샘플에 대한 링크는 없습니다.

iText 웹사이트에서 서명 샘플을 검색했지만 찾을 수 없었고 대신 몇 가지 새 파트너십을 발표하는 블로그 게시물이 제공되었습니다.

각 도구가 제공하는 API는 매우 설명적이며, 각자 PDF 문서의 컨텐츠를 생성하고 관리할 수 있도록 개발자에게 전체 액세스를 줍니다. 다행히도 모든 프레임워크는 현대적인 코드 에디터인 Visual Studio 또는 Visual Studio Code처럼 자동 완성 기능을 제공하는 도구와 함께 작업할 때 훌륭한 인라인 문서를 제공하는 완전한 자동 완성 힌트를 갖추고 있습니다.

IronPDF

IronPDF API는 'RenderHtmlAsPdf' 같은 단순화된 명령으로 매우 어렵고 복잡한 상호작용을 쉽게 수행할 수 있도록 하지만, 여전히 문서의 컨텐츠 생성 및 배치, 보안, 메타데이터, 양식에 깊은 접근을 제공합니다. 개발자로서 이러한 API는 제가 콘텐츠 렌더링에 대해 생각하는 방식을 전합니다.

IronPDF API가 사용하는 이름과 용어는 문서를 렌더링하거나 생성하고 있다는 것을 명확히 합니다. 몇몇 설정의 시간 속성은 밀리초를 나타내는 정수로 제공되며, 저는 본래의 TimeSpan 유형을 선호했습니다. 마지막으로, 다음과 같은 최신 유창한 구성 API가 제공된 설정 및 옵션 유형을 보고 싶습니다:

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

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

Dim renderer = New IronPdf.ChromePdfRenderer(Sub(options)
	options.RenderDelay = TimeSpan.FromSeconds(1)
End Sub)

Syncfusion

Syncfusion API는 명확하며, 그들의 변환 도구와 상호작용하는 방법에 매우 설명적인 제어를 제공합니다. 여기에는 지름길이 없고, 모든 것이 필요하며, 사용 중인 도구를 명시해야 하며 기본값은 제공되지 않습니다. 설정은 모든 항목을 세밀하게 제어할 수 있고, 하드 디스크의 WebKit 렌더러 위치까지 포함되어 있을 정도로 광범위합니다.

몇몇 설치에서는 필요하지 않지만, 이 여분의 설정이 과거 문제를 일으켰으며, 향후 버전에서는 Syncfusion이 문제가 되지 않는다고 약속합니다.

Aspose

Aspose API는 매우 장황하며, 개발자를 전혀 생산적으로 만들 가능성이 있는지 궁금하게 만듭니다. 웹사이트에서 문서를 로드하는 데 필요한 구성의 양은 경이롭습니다. 10줄의 코드 또는 5줄의 Syncfusion보다 두 배나 많은 줄입니다.

이 예 중 하나는 Aspose에 URL을 지정하여 가져오고 변환할 수 있는 API가 없다는 것입니다.

iText

iText에는 Aspose와 유사한 API가 있으며, 매우 장황하고 다양한 데이터 유형으로 문서에 직접 쓸 수 있는 상호작용을 허용하지만, 문서 섹션을 생성하는 방법은 명확하지 않습니다. API가 매우 명확하고 문서의 저품질이기 때문에 iText와 작업하기 어려운 상태입니다.

참조 웹사이트는 CSS가 없고 링크와 이미지가 있는 텍스트만 있는 매우 간단한 구조입니다.

그림 16 - 정적 웹 테스트를 위한 참조 웹사이트

IronPDF

이것은 실행하기 위한 간단한 세 줄의 코드였으며, 성능도 835ms로 좋았습니다. 그러나 PDF를 열어보니 기본 설정에서 이미지가 렌더링에 포함되지 않아 실망스러운 결과가 나타났습니다.

약간의 탐색을 통해 렌더링 지연을 추가할 수 있다는 것을 알게 되었고, 이 설정으로 페이지에 적절한 이미지가 포함된 PDF를 렌더링할 수 있었습니다.

도구의 테스트 버전에서는 렌더링된 PDF에 워터마크가 포함됩니다. 정식 라이센스 버전에서는 이 워터마크가 없습니다.

그림 17 - 정적 사이트의 IronPDF 렌더링

Syncfusion

Syncfusion은 호기심을 불러일으키고 혼란스러운 여행이었습니다. 그들의 문서는 HTML 및 PDF를 렌더링하고 전달하기 위한 다양한 방법을 여러 버전 번호와 프레임워크에 대해 서로 다른 코드 및 설정, 이진 도구 설치를 요구하여 기능이 정상 작동하도록 설명하고 있습니다.

IronPDF 데모와 마찬가지로 Syncfusion은 페이지의 이미지를 렌더링하지 않았고, 매우 작은 여백의 PDF를 제공했습니다.

도구의 테스트 버전에서는 렌더링된 PDF에 워터마크가 포함됩니다. 정식 라이센스 버전에서는 이 워터마크가 없습니다.

그림 18 - 정적 사이트의 Syncfusion 렌더링.

Aspose

Aspose는 그들의 도구 사용 방법에 대해 매우 명확한 지침을 제공합니다. 그러나 그들의 웹사이트의 웹페이지에서 PDF로 변환하는 방법 지침에 따르면 해당 기능이 작동하지 않게 하는 중요한 버그가 있습니다. 추가적으로, 그들의 웹사이트에서 PDF로 변환하는 온라인 도구도 더 이상 작동하지 않습니다.

iText

iText의 문서는 찾기가 쉽지 않고, 이 샘플을 실행하기 위해 우리가 찾고 있던 샘플 코드를 얻기 위해 전자책을 읽어야 했습니다. 코드 변경 없이, 추가 설정 없이, 네 줄의 코드로 워터마크도 없고 여백도 좋은 매우 잘 만들어진 PDF를 렌더링했습니다.

그림 19 - 정적 사이트의 iText 렌더링.

이 테스트에서는 CSS, 이미지, JavaScript가 많이 포함된 스포츠 웹사이트인 ESPN.com을 사용합니다. 간단한 테스트에서 Aspose가 작동하지 않았으므로 앞으로는 넘기겠습니다. 마지막 데모에서 사용한 것과 동일한 코드를 사용하여 캡처를 생성할 것이며, 웹사이트 주소만 대체할 것입니다.

참고로, 이 테스트 당시 ESPN의 모습은 다음과 같습니다:

그림 20 - 브라우저에서의 ESPN.com 전체 렌더링

화면 상단의 점수와 화면 중간의 경기 상태 보고서는 JavaScript로 배치되어 있으며, 모든 위치와 색상은 CSS3로 처리됩니다.

IronPDF

IronPDF 렌더링은 동적 콘텐츠를 충실히 복제하고 로드할 수 있었지만, 페이지는 모바일 기기를 위한 것으로 렌더링되어 콘텐츠 요소가 별도의 세그먼트로 나뉘고 타일 형식으로 배열된 것으로 보입니다.

그림 21 - ESPN의 IronPDF 렌더링

Syncfusion

Syncfusion도 유사한 '모바일 스타일' 렌더링을 수행하여 콘텐츠를 수직으로 타일 형식으로 배열했습니다. 그러나 우리는 ESPN 사이트에서 동적으로 로드되는 여러 이미지를 잃었고, 일부 폰트 형식도 손실되었습니다:

그림 22 - ESPN의 Syncfusion 렌더링

iText

이 테스트에서는 iText가 실행을 거부하고 NullReferenceException을 던지며, 웹사이트를 렌더링하려는 시도를 방지했습니다.

마지막 테스트는 웹사이트를 기반으로 양식 입력 필드를 가진 PDF를 생성하는 것입니다. 제가 작성한 간단한 뉴스레터 가입 양식은 깃허브 저장소에 있으며, Firefox에서 Bootstrap 5로 다음과 같이 렌더링됩니다:

그림 23 - Firefox에서의 양식 웹사이트

참고: 상태는 콤보박스이고, 전화 필드는 전화 필드이며, 이메일은 이메일 필드이고, 신발 사이즈는 숫자 필드입니다.

IronPDF

이 테스트에서 Iron은 페이지 오른쪽 상단의 햄버거 메뉴 버튼에 의해 증명된 바와 같이 유사한 모바일 친화적 레이아웃으로 빠르게 렌더링됩니다. 테스트 버전의 페이지 전반에 걸친 워터마크는 성가시지만, 정식 라이센스 버전에서는 제거됩니다.

모든 텍스트박스 필드는 제가 상호작용할 수 있는 PDF 양식 필드로 렌더링되지만, 끝 부분의 라디오 버튼과 체크박스를 제외하고는 그렇게 되어 있지 않습니다. 이 텍스트 상자에는 브라우저에서는 그렇지 않듯이 특정한 유효성 검사 또는 내용 강제가 없습니다.

그림 24 - IronPDF 폼 렌더링

Syncfusion

Syncfusion은 햄버거 메뉴 버튼이 없기 때문에 웹사이트의 전체 데스크톱 버전을 렌더링한 것으로 보입니다. 렌더링된 폼 요소는 화면의 사각형, 버튼 및 상자로 나타나지만 표준 PDF 데이터 입력 필드는 없습니다. 워터마크로 가려져 있지만, 헤더와 푸터에 있는 링크는 클릭 가능합니다.

그림 25 - Syncfusion에 의해 렌더링된 폼 사이트

iText

iText는 세 가지 프레임워크 중에서 콘텐츠를 렌더링하는 데 가장 빠른 속도를 기록했습니다. 그러나 그 속도는 대가를 치렀습니다. 그들의 렌더링은 클릭 시 이동하는 앵커 태그를 제공했지만, 원래 웹사이트에 도달하지 못했습니다. 부트스트랩의 모든 서식이 손실되었고, 모든 폼 필드는 일반 상자로 렌더링되었습니다.

그림 26 - iText에 의해 렌더링된 폼 사이트