PDF 병합

병합은 PDF의 페이지를 지정한 순서대로 새 문서 하나에 복사해 합치는 작업입니다. 페이지는 완성된 객체 그대로 옮겨집니다 — 텍스트는 계속 선택할 수 있고, 페이지 안의 링크도 그대로 동작하며, 이미지는 원본 데이터를 유지합니다. 아무것도 다시 인코딩하지 않으므로, 병합된 파일은 원본들을 나란히 놓은 것과 똑같이 보이고 똑같이 동작합니다.

작업 전체가 브라우저에서 실행됩니다. 이 페이지에는 업로드 엔드포인트가 없습니다 — 파일은 메모리로 읽히고, 백그라운드 워커에서 동작하는 PDF 엔진이 이를 합친 다음, 브라우저가 다운로드하는 파일로 기록합니다. 확정하기 전에 순서 목록에 페이지 수가 표시되는 것도 그래서입니다. 도구는 파일을 어디에도 보내지 않고도 각 파일에 무엇이 들어 있는지 이미 알고 있습니다.

결과 파일 이름은 merged.pdf이며 워터마크는 없습니다. 원본 문서 중 하나라도 양식 필드가 있으면, 여러 파일의 필드가 서로 충돌할 수 있다고 결과 카드에서 알려 줍니다. PDF 양식은 이름으로 필드를 식별하는데, 두 문서가 서로 다른 필드에 같은 이름을 쓸 수 있기 때문입니다. 암호화된 PDF는 병합해서 손상된 결과를 만드는 대신 처음부터 거부합니다.

구조상 아무것도 탭을 떠나지 않습니다. 페이지가 파일을 메모리로 읽고, PDF 엔진이 백그라운드 워커에서 병합 문서를 조립하고, 결과는 다운로드 파일로 기록됩니다 — 어느 단계에서도 요청이 문서를 어딘가로 실어 나르지 않으며, 페이지는 그렇게 할 수도 없습니다. 페이지의 보안 정책이 외부 연결을 완전히 차단하기 때문입니다. 실행하는 동안 네트워크 패널을 지켜볼 수 있습니다. 이렇게 만든 이유가 바로 그것입니다. 계정도, 이메일도, 워터마크도, 보관된 사본도 없습니다 — 보관할 서버 측 사본 자체가 없습니다.

병합은 페이지 단위 도구입니다. 페이지 전체를 합칠 뿐, 페이지 안의 글자는 건드릴 수 없고, 결과를 압축할 수 없으며, 암호화된 파일은 열 수 없습니다. 이런 한계는 얼버무리지 않고 밝혀 둡니다. 페이지 안의 텍스트는 Android 앱이 원본 텍스트 객체를 직접 편집하고, 암호화된 파일은 휴대폰에서 비밀번호로 엽니다. 병합의 목적이 주로 순서 — 어느 장 다음에 어느 장이 오는지 — 라면 이 페이지로 충분합니다.

전형적인 사용 흐름은 이렇습니다. contract.pdf, scope.pdf, appendix.pdf를 페이지에 끌어다 놓으면 목록에 각각 4, 2, 16페이지가 표시됩니다. 결재 순서가 바뀌었으니 appendix를 scope 위로 드래그합니다. “PDF 병합”을 누르고 20초 뒤 merged.pdf를 다운로드합니다. 계정을 만들지도, 이메일을 입력하지도 않았고, 어떤 파일도 컴퓨터를 떠나지 않았습니다 — 관련된 파일 네 개는 모두 내 디스크에만 있으며, 그중 세 개는 끌어다 놓기 전 자리에 그대로 있습니다.