JavaScript PDF 라이브러리를 선택하는 일은 보통 작은 작업에서 시작됩니다. 인보이스를 생성하거나, 계약서를 표시하거나, 페이지에 도장을 찍는 일입니다. 몇 달 후 같은 프로젝트에서 PDF를 읽고, 중국어 텍스트를 인쇄하거나, Word 템플릿을 PDF로 변환해야 하는데, 첫 작업을 위해 고른 라이브러리는 두 번째 작업의 일부만 처리합니다.
우리는 pdf-lib, jsPDF, PDFKit, PDF.js, @react-pdf/renderer, pdfmake, Spire.PDF for JavaScript 등 7개 라이브러리를 하나의 브라우저 테스트 환경에서 실행해 각각 어디까지 버티는지 확인했습니다. 아래에서 측정된 소요 시간, 출력 크기, 글꼴 동작, 변환 결과를 확인한 뒤 시나리오별 권장 사항을 제시합니다.
공개: Spire.PDF for JavaScript는 이 글의 발행사인 E-iceblue의 제품이며, E-iceblue가 테스트를 진행했습니다. 버전, 테스트 파일, 방법은 테스트 방법에 나와 있습니다. 자사 제품에 불리한 결과도 유리한 결과와 함께 보고합니다.
어떤 JavaScript PDF 라이브러리를 선택해야 할까요?
작업에서 시작하세요. 이 비교의 모든 라이브러리는 아래 표의 일부 행에서 선두이고, 모든 행에서 선두인 라이브러리는 없습니다.
| 작업 | 이 테스트에서 가장 적합한 선택 | 이유 |
|---|---|---|
| 코드에서 작고 빠른 PDF 생성 | jsPDF, PDFKit | jsPDF가 10페이지 중앙값 최저(3.9ms) |
| 자동 페이지 나눔이 있는 표와 긴 보고서 생성 | pdfmake | 표를 지원하는 선언적 레이아웃 |
| React 컴포넌트에서 PDF 생성 | @react-pdf/renderer | 컴포넌트 API, 내부적으로 PDFKit 사용 |
| 텍스트 읽기, PDF 표시 | PDF.js | 파서, 표시 API, 뷰어를 하나의 프로젝트에 제공 |
| 기존 PDF 수정 | pdf-lib | 이미 존재하는 파일을 편집 |
| PDF를 다른 형식으로 변환하거나 위 작업 여러 개를 하나의 패키지로 결합 | Spire.PDF for JavaScript | 테스트에서 12개 출력 대상 실행 |
처음 다섯 행은 단일 작업이며, 전문 오픈소스 라이브러리가 각각을 잘 처리합니다. 마지막 행은 다른 경우입니다. 여러 작업이 필요하거나 형식 간 변환이 필요한 프로젝트에서는 계산이 달라집니다. 단일 라이브러리의 한계와 Spire에 관한 섹션에서 그 이유를 설명합니다.
각 라이브러리가 가장 잘하는 것
여기서 사람들이 검색하는 세 문구 중 두 개는 라이브러리가 아니라 작업을 설명합니다. JavaScript PDF 파서는 파일을 읽고, JavaScript PDF 편집기는 이미 존재하는 파일을 변경합니다. 이 구분이 많은 것을 결정하므로, 아래 각 항목은 라이브러리가 할 수 없는 일로 끝납니다.
pdf-lib (1.17.1)는 PDF를 생성하고 기존 PDF를 수정하므로, 일반적인 오픈소스 JavaScript PDF 편집기입니다.
import { PDFDocument, StandardFonts } from 'pdf-lib'
const doc = await PDFDocument.create()
const page = doc.addPage([595.28, 841.89])
const font = await doc.embedFont(StandardFonts.Helvetica)
page.drawText('Hello', { x: 40, y: 800, size: 12, font })
const bytes = await doc.save()
다른 곳에서 PDF가 도착했고 페이지 추가, 텍스트 오버레이, 값 채우기가 필요할 때 선택하세요. 텍스트 추출 API는 없습니다. 10페이지 테스트 파일의 페이지 수를 8ms에 읽었으며, 그것이 읽기 지원의 전부입니다. 최신 릴리스 1.17.1은 2021-11-06에 나왔습니다. 그 때문에 pdf-lib 대안을 찾고 있다면 커뮤니티 포크인 @cantoo/pdf-lib가 코드를 이어가고 있습니다.
jsPDF (4.2.1)는 명령형 호출로 브라우저에서 문서를 생성합니다.
import { jsPDF } from 'jspdf'
const doc = new jsPDF()
doc.text('Hello', 10, 10)
const buffer = doc.output('arraybuffer')
몇 줄의 코드로 영수증이나 보고서 페이지를 만드는 빠른 내보내기에 적합합니다. 파일만 생성하므로 기존 PDF를 열고 편집할 수 없으며, 이것이 일반적인 pdf-lib vs jsPDF 구분선입니다. compress 옵션은 중국어 텍스트도 손상시키는데, 아래 글꼴 섹션에서 다룹니다. jsPDF 대안을 찾는 사람은 먼저 빠진 부분이 편집(pdf-lib), 표(pdfmake), React(React-PDF) 중 무엇인지 결정해야 합니다.
PDFKit (0.20.2)는 Node에서 문서를 생성하며, 번들러를 사용하면 브라우저에서도 생성합니다. 브라우저 빌드는 표준 글꼴을 직접 등록해야 합니다.
import PDFDocument, { registerStdFonts } from 'pdfkit'
import Helvetica from 'pdfkit/standard-fonts/Helvetica'
registerStdFonts(Helvetica)
const doc = new PDFDocument()
doc.font('Helvetica').text('Hello')
PDFKit는 HTML/CSS 렌더러가 아니라 그리기 API이므로 웹 페이지를 그대로 넘길 수 없고, 텍스트와 그래픽을 직접 배치해야 합니다. 이 제어 방식은 라벨, 인증서, 명세서처럼 고정 레이아웃 문서에 적합합니다. 기존 PDF는 읽을 수 없습니다.
PDF.js (6.5.438)는 파서 코어, 표시 API, 완성된 뷰어입니다. PDF를 읽고 표시하는 오픈소스 선택이며 텍스트 추출도 처리합니다.
import * as pdfjsLib from 'pdfjs-dist'
const doc = await pdfjsLib.getDocument({ data: bytes }).promise
const page = await doc.getPage(1)
const content = await page.getTextContent()
JavaScript PDF 파서를 검색하는 개발자는 보통 여기에 도달합니다. 원시 바이트 대신 구조화된 텍스트와 페이지 데이터를 반환하기 때문입니다. 처음부터 PDF를 생성할 수는 없고, 편집은 saveDocument가 다루는 범위, 예를 들어 페이지 선택과 주석 변경에 머뭅니다. 범용 PDF 편집기는 아닙니다.
@react-pdf/renderer (4.9.0)는 React 컴포넌트를 PDF로 바꿉니다. PDFKit 위에 있으므로 브라우저에서 동일한 표준 글꼴 미등록 오류가 발생합니다.
import { Document, Page, Text, pdf } from '@react-pdf/renderer'
const blob = await pdf(
<Document><Page><Text>Hello</Text></Page></Document>
).toBlob()
이미 UI를 React로 설명하고 인보이스나 보고서가 컴포넌트를 공유하기를 원하는 팀에 적합합니다. 출력만 생성합니다. 기존 파일을 읽거나 편집하려면 다른 라이브러리가 필요합니다.
pdfmake (0.3.14)는 선언적 문서 정의를 받아 표와 페이지 나눔을 처리합니다. 0.3부터 getBuffer는 Promise를 반환합니다. 콜백을 전달하는 코드는 다시 호출되지 않습니다.
import pdfMake from 'pdfmake/build/pdfmake'
import pdfFonts from 'pdfmake/build/vfs_fonts'
pdfMake.vfs = pdfFonts.vfs
const buffer = await pdfMake.createPdf({ content: ['Hello'] }).getBuffer()
오픈소스 6개 중 길고 표가 많은 출력에 가장 편안합니다. 내용을 설명하면 라이브러리가 페이지 나눔 위치를 결정하기 때문입니다. 정의 객체에서 문서를 생성하며 기존 PDF를 파싱하거나 편집할 수 없습니다.
Spire.PDF for JavaScript (11.7.0)는 여기서 한 영역만 담당하지 않는 유일한 항목입니다.
위의 각 라이브러리는 한 작업을 전문으로 하며, 다음 섹션은 프로젝트에 그중 두 개가 필요할 때 드는 비용을 보여줍니다. 이 제품은 생성, 텍스트 추출, 페이지 작업, 이미지 렌더링이라는 같은 네 작업을 하나의 API로 실행하고, 다른 어떤 라이브러리에도 없는 12개 변환 대상을 추가합니다. 한계는 아래에서 측정해 보고한 대로 뷰어 컴포넌트가 아니며, 프로덕션 사용에는 상용 라이선스가 필요합니다. 코드 샘플과 전체 변환 결과는 자체 섹션에 있습니다.
단일 라이브러리가 멈추는 곳
오픈소스 6개 중 PDF를 생성, 파싱, 수정, 렌더링하는 라이브러리는 없습니다. 각각 한 영역을 담당합니다.
평범하게 들리는 워크플로를 생각해 보세요. 고객의 DOCX 템플릿을 읽고, 주문 데이터를 채우고, PDF를 생성한 다음, 암호로 보호합니다. 6개 중 Word 파일을 여는 것은 없으므로 한 패키지가 DOCX 단계를 처리하며, 보통 서버에서 실행됩니다. 그다음 레이아웃 라이브러리가 PDF를 작성하고, 세 번째 패키지가 보호를 적용합니다. 세 패키지와 두 번의 핸드오프입니다.
대화에서 역할도 흐려집니다. 사람들은 세 가지 다른 의미로 "PDF 렌더링"이라고 말합니다. 코드에서 문서를 그리는 것, 기존 파일을 사용자에게 표시하는 것, 페이지를 이미지로 바꾸는 것입니다. PDF.js는 표시하고, 생성기는 그리고, 6개 중 세 가지를 모두 하는 것은 없습니다. 프로젝트에 필요한 의미를 적어 두면 후보 목록의 절반이 줄어듭니다.
모든 핸드오프는 검증할 ArrayBuffer이고, 모든 패키지는 글꼴과 인코딩에 대한 자체 규칙을 가져옵니다. 각 조각은 개별적으로 좋지만, 유지보수 비용은 그 사이의 접착제에서 쌓입니다. 팀은 보통 요구 사항이 경계를 넘을 때, 예를 들어 "결과를 Word로도 내보내기" 같은 요구가 생길 때 처음 느낍니다.
Spire.PDF for JavaScript가 추가하는 것
Spire.PDF for JavaScript는 브라우저에서 WebAssembly로 실행되므로 서버 왕복 없이 클라이언트에서 문서를 처리할 수 있습니다. 우리는 spire.office 패키지 버전 11.7.0을 통해 테스트했습니다.
API는 병합, 분할, 압축, 페이지 작업, 양식 필드, 주석, 책갈피, 첨부 파일, 레이어를 다룹니다. Spire.PDF for JavaScript 프로그램 가이드에 전체 범위가 나와 있습니다. 여기서 측정한 부분은 변환입니다. 2페이지 중국어 PDF(13.1KB)를 FileFormat 열거형의 13개 값 중 10개로 변환하고, PNG 내보내기와 PDF/A 변환도 수행했습니다.
| 출력 | 크기 |
|---|---|
| DOCX | 5,132,598 B |
| XLSX | 9,594 B |
| PPTX | 27,827 B |
| HTML | 89,687 B |
| Markdown | 558 B |
| XPS | 24,202 B |
| OFD | 17,281 B |
| PCL | 47,272 B |
| PostScript | 87,159 B |
| PNG (1페이지, 184ms) | 19,789 B |
| PDF/A-1b | 57,581 B |
| SVG (페이지당 파일 하나) | 페이지당 44,777 B |
12개 대상 모두 중국어 파일을 변환했습니다. SVG 내보내기는 페이지마다 파일 하나를 쓰며, output_1.svg, output_2.svg 등의 이름을 사용합니다. 5.1MB DOCX는 중국어 글꼴이 Word 파일로 전달되기 때문이며, 영어 문서는 그렇게 동작하지 않습니다.
import * as spire from '/spire.pdf.js'
const { PdfDocument, PdfFont, PdfFontFamily, PdfBrushes } = spire.spirepdf
const doc = new PdfDocument()
const page = doc.Pages.Add()
const font = new PdfFont({ fontFamily: PdfFontFamily.Helvetica, size: 12 })
page.Canvas.DrawString({ s: 'Hello', font, brush: PdfBrushes.get_Black(), x: 40, y: 60 })
doc.SaveToFile({ fileName: 'out.pdf' })
매개변수는 하나의 객체 리터럴로 전달합니다. 위치 인수를 사용하면 Ambiguous call 오류가 발생합니다. WebAssembly에는 시스템 글꼴이 없으므로 변환에는 한 단계가 더 필요합니다.
PdfDocument.LoadCustomFontFolder('/Library/Fonts') // skipping this raises "Cannot found font"
const doc = new PdfDocument()
doc.LoadFromFile({ fileName: 'in.pdf' })
doc.SaveToFile({ fileName: 'out.docx', fileFormat: spire.spirepdf.FileFormat.DOCX })
호출 전에 가상 파일 시스템의 해당 폴더에 글꼴 파일을 복사하세요.
모든 것이 하나의 WebAssembly 패키지에서 실행되므로, 한 페이지에서 PDF를 열고 변경한 뒤 바이트를 두 번째 라이브러리에 넘기지 않고 다른 형식으로 저장할 수 있습니다. 브라우저에서 사용자 업로드 파일을 처리하는 팀, 즉 문서를 서버로 보내는 것이 프라이버시나 규정 준수 문제가 되는 팀에 가장 유리합니다.
모든 배포 계획에 세 가지 숫자가 포함되어야 합니다. 첫 로드는 1,900.7ms(다른 콜드 실행에서는 2,756ms)가 걸렸고, 대부분은 CPU입니다. 런타임이 약 19MB의 WebAssembly 아카이브를 다운로드하고 첫 문서를 열기 전에 JSZip으로 압축을 풉니다. 두 아카이브는 Spire.Common.Wasm(10.1MB)과 Spire.Pdf.Wasm(8.6MB)입니다. JavaScript 접착 코드는 원본 약 1.3MB를 추가하지만 전송 시 대략 117KB로 압축됩니다. 아카이브 자체는 이미 압축되어 있어 gzip으로 얻는 것이 없습니다.
하나의 패키지로 Office에서 PDF로
오픈소스 6개 라이브러리는 PDF에서 시작합니다. Word, Excel, PowerPoint 파일은 범위 밖이므로, 이전 섹션의 워크플로에는 네 번째 패키지가 필요했습니다.
Spire.Office for JavaScript는 Word, Excel, PowerPoint, PDF용 네 개의 진입점을 가진 하나의 npm 패키지 제품군입니다. 각 진입점에는 자체 WebAssembly 모듈이 있고, 공통 모듈이 모두 아래에 있습니다. Word to PDF, Excel to PDF, PowerPoint to PDF는 서버 없이 브라우저에서 실행되며, PDF to Word, Excel, PowerPoint, HTML도 같은 제품군을 통해 실행됩니다.
작동하는 코드가 포함된 안내는 React에서 JavaScript로 Word를 PDF로 변환하기를 참조하세요.
이 섹션의 모든 주장에는 한 가지 한계가 적용됩니다. 우리 벤치마크는 PDF 작업만 시간을 측정했습니다. Office-to-PDF 변환은 여기서 측정하지 않았으므로, 이 글에는 해당 속도나 충실도 수치가 없습니다. 그 경로에 의존할 계획이라면 자체 Word 및 Excel 파일로 시간을 측정해야 합니다. 레이아웃 복잡성이 파일 크기보다 변환 비용을 훨씬 크게 바꾸기 때문입니다. 구조적으로 말할 수 있는 것은, 세 패키지가 필요했던 템플릿 워크플로를 하나의 패키지 제품군으로 작성할 수 있고 라이브러리 간 파일 핸드오프가 사라진다는 것입니다.
성능 및 로드 비용
모든 라이브러리가 10페이지 영어 문서를 100ms 이내에 완료했습니다. jsPDF가 3.9ms로 가장 빨랐고 Spire는 90.7ms로, 측정 가능한 차이지만 클릭으로 트리거되는 내보내기에서는 문제가 될 가능성이 낮습니다.
| 라이브러리 | 첫 실행 | 중앙값(10페이지) | 출력 크기 |
|---|---|---|---|
| jsPDF | 12.1 ms | 3.9 ms | 6,609 B |
| PDFKit | 45.7 ms | 6.8 ms | 6,194 B |
| pdf-lib | 86.1 ms | 9.2 ms | 3,123 B |
| pdfmake | 75.6 ms | 25.4 ms | 16,823 B |
| React-PDF | 125.5 ms | 36.3 ms | 7,395 B |
| Spire | 486.0 ms | 90.7 ms | 7,723 B |
첫 실행 열은 한번 볼 만합니다. 일회성 초기화를 포함하므로 페이지 로드 후 사용자가 첫 클릭에서 보는 것을 보여줍니다. 오픈소스 라이브러리는 12.1~125.5ms이고 Spire는 486.0ms입니다. 모두 반복 호출에서는 빠르게 안정됩니다.
실제 비용은 로딩에 있습니다. Spire는 1,900.7ms였고 다른 라이브러리는 13~211ms였습니다.
| 라이브러리 | 첫 가져오기 |
|---|---|
| jsPDF | 13.0 ms |
| React-PDF | 53.2 ms |
| PDFKit | 119.2 ms |
| pdf-lib | 191.7 ms |
| pdfmake | 197.0 ms |
| PDF.js | 211.2 ms |
| Spire.PDF for JavaScript | 1,900.7 ms |
두 숫자를 서로 다른 예산으로 보세요. 생성 시간은 문서마다 소비되고, 로드 시간은 방문마다 한 번 소비됩니다. 한 세션에서 수백 개 파일을 내보내는 도구는 1.9초를 한 번만 지불하지만, 파일 하나를 내보내는 랜딩 페이지는 그 파일을 위해 전부 지불합니다.
이 지연은 첫 페인트 중에 PDF 작업이 발생하는 페이지에서 문제가 됩니다. 클릭 후 변환이 시작되면 모듈을 미리 로드하거나 필요할 때 로드해 대부분을 숨길 수 있습니다.
출력 크기는 라이브러리보다 설정에 더 좌우됩니다. 800x800 PNG로 jsPDF는 기본 1,923,288B, compress: true에서 32,044B를 생성했습니다. pdf-lib(128.1ms)와 PDFKit(189.6ms)은 같은 이미지를 jsPDF(257.8ms)보다 빠르게 삽입했고, 각각 26,846B와 27,993B였습니다.
읽기는 10페이지 PDF에서 실행한 별도 벤치마크입니다.
| 라이브러리 | 페이지 수 읽기 | 텍스트 추출 |
|---|---|---|
| pdf-lib | 8 ms | 지원 안 함 |
| Spire | 94 ms | 284 ms |
| PDF.js | 200 ms | 190 ms |
시간만 비교하세요. Spire는 공백 보존으로 설정되어 1,381자를 반환했고, PDF.js는 텍스트 항목을 결합해 521자를 반환했으므로 문자 수는 비교할 수 없습니다.
중국어 텍스트 및 글꼴 처리
오픈소스 6개 모두 사용자가 제공하는 중국어 글꼴 파일이 필요합니다. 우리는 SimHei(9.7MB TrueType)를 사용했습니다. 제공 후 모두 글꼴을 포함하고 텍스트를 올바르게 렌더링했으며, PyMuPDF로 출력을 렌더링해 확인했습니다.
| 라이브러리 | 중국어 1페이지 중앙값 | 출력 크기 |
|---|---|---|
| jsPDF | 1.1 ms (첫 호출 479.8 ms) | 3,160 B |
| React-PDF | 7.3 ms | 11,286 B |
| pdfmake | 10.7 ms | 5,323 B |
| PDFKit | 11.3 ms | 10,743 B |
| pdf-lib | 32.7 ms | 9,693 B |
| Spire (TTF 포함) | 169.3 ms | 12,289 B |
글꼴 파일 자체가 9.7MB이므로 페이지에서 전송하거나 가져와야 하며, 필요할 때 로드하고 캐시할 계획을 세우세요. jsPDF의 1.1ms는 글꼴 등록 후에 적용됩니다. 등록을 포함한 첫 호출은 479.8ms였으므로 이 수치를 속도 우위로 읽으면 안 됩니다.
함정은 jsPDF에 있습니다. 기본 설정으로 생성한 중국어 페이지는 184,355B였고 올바르게 렌더링되었습니다. compress: true를 사용하면 파일이 3,168B로 줄었지만 중국어 문자가 전혀 없고 라틴 문자 횡설수설로 렌더링되었습니다. 글꼴이 글꼴 테이블에서 사라졌고 렌더링으로 확인했으므로 추출 문제가 아니었습니다. 중국어 문서에서는 압축을 끄고 렌더링된 페이지를 확인하세요. 이미지 전용 페이지는 안전하게 압축되므로(1,923,288B에서 32,044B로) 문서별 결정입니다.
Spire는 글꼴 파일이 필요 없는 내장 CJK 글꼴 제품군을 제공하며, 글꼴을 포함하지 않으므로 우리가 본 가장 작은 출력(2,262B)을 생성합니다. 지원 범위는 제품군에 따라 다릅니다. SinoTypeSongLight는 샘플의 모든 문자를 렌더링했지만 MonotypeHeiMedium과 MonotypeSungLight는 报와 数를 누락했습니다. 선택한 제품군에 문자 집합이 있는지 확인하거나, 테스트에서 올바르게 렌더링된 TTF를 포함하세요.
PDF/A 및 라이선스
PDF/A는 PDF의 보존 프로필이며, 많은 기록 및 규정 준수 워크플로에서 요구합니다. 파일이 뷰어에서 올바르게 보여도 표준을 통과하지 못할 수 있으므로 눈으로 확인하지 않고 검증기로 출력을 확인했습니다. veraPDF 1.30.3으로 보존 출력을 검증했습니다. Spire의 PDF/A-1b 및 PDF/A-2b 파일은 모두 통과했습니다. PDFKit은 문서화된 subset: 'PDF/A-1b' 옵션으로 호출했지만 글꼴 미포함(6.3.4), 메타데이터 키 누락(6.7.2), Info와 XMP 메타데이터 불일치(6.7.3) 등 다섯 가지 위반으로 실패했습니다. 변환하지 않은 Spire 원본 파일도 1b에 실패했으며, 이는 검증기가 좋은 파일과 나쁜 파일을 구분한다는 것을 보여줍니다. 다른 라이브러리는 PDF/A를 테스트하지 않았습니다.
Spire.PDF for JavaScript는 세 가지 에디션으로 제공됩니다. 무료 에디션은 free-pdf-for-javascript에서 PDF 파일 생성 및 변환을 다루며 워터마크가 없습니다. 이 벤치마크에 사용된 평가판 빌드는 출력에 워터마크와 페이지 제한을 적용합니다. 무료 임시 라이선스는 제품을 평가하는 동안 두 제한을 해제하며, 상용 라이선스는 프로덕션 사용을 다루며 이는 상용 SDK의 일반적인 방식입니다.
평가하는 실용적인 방법은 실제 문서 세 개를 고르는 것입니다. 가장 긴 문서, 중국어 또는 기타 비라틴 텍스트가 있는 문서, PDF/A 또는 Word로 내보내야 하는 문서입니다. 해당 실행을 위해 무료 임시 라이선스를 요청해 문서 길이가 변수가 되지 않게 한 다음, 그렇지 않으면 사용할 오픈소스 라이브러리와 로드 시간 및 출력 모두를 비교하세요.
테스트 방법
테스트는 Windows 11 Pro(10.0.26300)의 Chromium 기반 브라우저에서 Vite 프로젝트로 실행했으며, Node v26.12.1과 npm 12.0.1을 사용했습니다. 각 측정은 워밍업 1회와 반복 5회를 사용했고 중앙값을 보고합니다. 이미지 테스트 파일은 런타임에 캔버스에서 생성한 800x800 PNG였고, 중국어 테스트는 SimHei를 사용했습니다.
라이브러리 버전은 pdf-lib 1.17.1, jsPDF 4.2.1, PDFKit 0.20.2, PDF.js 6.5.438, @react-pdf/renderer 4.9.0, pdfmake 0.3.14, spire.office 11.7.0이었습니다. 글꼴은 PyMuPDF로 렌더링해 확인했고, PDF/A 파일은 veraPDF로 확인했습니다.
벤치 프로젝트와 분석 스크립트는 재현 가능하므로 팀이 자체 하드웨어에서 같은 사례를 다시 실행해 비교할 수 있습니다. 타이밍은 머신마다 다르며, 라이브러리 간 비율이 더 유용한 신호입니다.
테스트 문서는 10페이지 이하였습니다. 라이브러리 간 렌더링 픽셀 비교와 Spire 및 PDFKit 이외 라이브러리의 PDF/A 출력은 이번 실행 범위 밖이었습니다. 처음에 밝혔듯이 E-iceblue가 이 벤치마크를 실행했고 Spire.PDF for JavaScript를 발행합니다.
자주 묻는 질문
브라우저에서 PDF를 렌더링할 수 있나요? 표시 API와 뷰어를 포함한 PDF.js를 사용하세요. 라이브러리 간 렌더링 픽셀은 비교하지 않았습니다. Spire.PDF for JavaScript는 페이지를 PNG로 변환하지만(테스트에서 1페이지 184ms) 뷰어 컴포넌트는 아닙니다. 브라우저 내 보기와 편집에는 Spire.OfficeJS가 그 작업을 위해 만들어진 프런트엔드 제품군입니다.
중국어 텍스트에는 어떤 라이브러리가 가장 좋나요?
jsPDF의 compress: true를 제외하면 글꼴을 제공하면 오픈소스 6개 중 어느 것이든 작동합니다. Spire의 내장 CJK 제품군은 글꼴 파일이 필요 없습니다. SinoTypeSongLight는 전체 중국어 샘플을 지원했지만 두 Monotype 제품군은 몇 문자를 누락했습니다.
Word 또는 Excel 파일을 처리해야 한다면요? 오픈소스 6개 라이브러리는 PDF에서 시작합니다. Spire.Office for JavaScript는 같은 패키지 제품군에서 Word, Excel, PowerPoint를 처리합니다.
번들 크기가 문제가 될까요? 오픈소스 라이브러리는 13~211ms에 초기화되었습니다. Spire는 1.9초가 걸리고 총 약 19.6MB의 파일이 있으며, 이는 다운로드 크기와 같지 않습니다. 첫 페인트가 중요하면 필요할 때 로드하세요.
프로덕션에서 라이선스가 필요한가요? 무료 에디션은 워터마크 없이 PDF 파일 생성 및 변환을 다룹니다. 평가판 빌드는 출력에 워터마크와 페이지 제한을 적용하며, 무료 임시 라이선스가 제품을 평가하는 동안 이를 제거합니다. 프로덕션에는 상용 라이선스가 필요합니다.
시나리오별 권장 사항
선택은 프로젝트에 작업이 몇 개인지에 달려 있습니다.
작업 하나: 전문 라이브러리를 선택하세요.
- 속도 우선의 인보이스와 영수증: jsPDF 또는 PDFKit, 중국어라면 글꼴 확인.
- 표와 긴 보고서: pdfmake.
- React 애플리케이션: @react-pdf/renderer.
- 기존 PDF 편집: pdf-lib, 2021년 릴리스 날짜를 염두에 두세요.
- 읽기와 보기: PDF.js.
- 검증기를 통과해야 하는 보존 출력: Spire.PDF for JavaScript. PDF/A-1b 및 PDF/A-2b 파일이 veraPDF를 통과했지만 PDFKit의 문서화된
subset옵션은 다섯 규칙에서 실패했습니다. - 글꼴 파일을 배포하지 않는 중국어 출력: Spire의 내장 CJK 제품군. SinoTypeSongLight는 전체 샘플을 지원했고, 오픈소스 6개는 각각 직접 배포해야 하는 글꼴 파일이 필요하며 테스트에서는 9.7MB였습니다.
작업 두 개 이상, 또는 형식 간 변환이 있는 경우: 계산이 달라집니다. DOCX 템플릿을 읽고, PDF를 작성하고, 결과를 다른 형식으로 변환하는 프로젝트에는 위 라이브러리 중 두세 개와 Word용 네 번째 패키지가 필요하며, 그 사이의 모든 핸드오프는 검증할 ArrayBuffer이고 별도의 글꼴 파이프라인을 구성해야 합니다. Spire.PDF for JavaScript가 만들어진 경우가 바로 이것입니다. 위 네 작업과 12개 변환 대상을 아우르는 하나의 API가 서버 없이 브라우저에서 실행됩니다.
비용은 측정 가능하며 우리가 보고했습니다. 첫 로드에 1.9초가 걸리는데, 런타임이 첫 문서를 열기 전에 약 19MB의 WebAssembly 압축을 풀기 때문입니다. 첫 클릭 전에 미리 로드하면 사용자는 보지 못합니다. 무료 에디션은 워터마크 없이 생성과 변환을 다루며, 임시 라이선스는 자체 문서와 비교하는 동안 평가 제한을 제거합니다.