나는 무언가를 확인하기 위해 두 페이지 보고서를 Word로 변환했고 두 번째 단락은 다음과 같이 돌아왔습니다.
세 번째 인원수 증가는 4분기 4분의 2 증가한 2명 모두 지원에 따라 증가했습니다. 고용 대규모 갱신은 8월 4분기에 계획에 서명했습니다. 여백은 평평하게 유지되었습니다. 6가지 역할에서 변함이 없습니다.
완벽하게 평범한 산문의 두 열은 시궁창을 가로질러 한 줄씩 읽혀서 모든 문장이 옆에 있는 문장으로 연결됩니다. 아무것도 고장나지 않았습니다. 변환기는 변환기가 할 수 있는 일을 정확히 수행했으며, 그와 "pdf to word"라는 구문이 약속한 것 사이의 격차가 이 가이드의 전체 주제입니다. 아래에 인용된 모든 출력은 변환을 설명하는 것이 아니라 실행에서 나온 것입니다.
TL;DR: PDF는 좌표에 글리프를 저장합니다. 단락, 열, 표 또는 제목을 저장하지 않으므로 변환기는 위치에서 추론해야 하며 이러한 추론 중 일부는 예측할 수 있는 방식으로 잘못되었습니다. 테스트 보고서에서 측정: 2개의 열이 한 줄씩 인터리브된 4열 테이블이 한 줄로 평평해졌습니다. "region Q2 Q3 EMEA 412 455 Amer 388 401 APAC 120 166", 아래 단락에 머지 않은 제목이 있고 텍스트 레이어가 없는 페이지는 전혀 생성되지 않습니다. 안정적으로 되돌릴 수 있는 것은 페이지 순서로 편집 가능한 산문이며, 대부분의 작업에서 원하는 작업입니다. 그만큼 PDF에서 단어로 변환기 브라우저에서 실행되므로 문서가 업로드되지 않습니다.
PDF 안에 무엇이 저장되어 있습니까?
문서가 아닌 페이지를 그리는 방법에 대한 지침.
PDF의 콘텐츠 스트림은 "이 글꼴을 이 크기로 설정하고 x 60, y 720으로 이동, 이 글리프를 표시"와 같은 내용을 말합니다. 그만큼 사양 자체 도형 모델에 대한 설명이며, 텍스트 연산자는 선을 그리는 것과 도형을 채우는 데 사용됩니다. 파일에는 "단락"을 의미하는 개체가 없고, "이것은 테이블"을 의미하는 개체가 없으며, 두 개의 텍스트 블록이 하나의 너비가 아닌 열이라는 것을 기록하는 개체가 없습니다. 형식은 페이지가 모든 곳에서 동일하게 인쇄되도록 설계되었으며 페이지를 콘텐츠가 아닌 마크로 설명함으로써 이를 달성합니다.
따라서 변환기는 위치가 지정된 실행 목록을 수신합니다. pdf.js, 이것이 실행되는 파서가 페이지가 그리는 대로 정확하게 돌려줍니다. 1페이지는 34개, 2페이지는 4개를 제작했습니다. 각 실행은 x, y, 너비 및 글꼴 높이가 있는 문자열이며, 그들이 도착하는 순서는 페이지가 그려진 순서이며, 반드시 읽을 순서는 아닙니다.
PDF에 없는 워드 문서에 필요한 모든 것, 변환기는 이 네 가지 숫자에서 재구성해야 합니다. 그 재건은 모든 것이 잘못되는 모든 것을 포함하여 다음의 전체입니다.
변환기는 좌표에서 단락을 어떻게 다시 작성합니까?
각각에 대한 임계값이 있는 두 개의 패스로.
첫 번째 패스 그룹은 기준선에 따라 선으로 연결됩니다. y 값이 서로의 글꼴 높이의 절반 이내인 실행은 한 줄입니다. 두 번째는 그 사이의 수직 간격으로 단락으로 줄을 그룹화합니다. 일반적인 줄 간격이 약 1.45배보다 큰 간격은 새 단락을 시작합니다. 여기서 "UAL"은 고정된 숫자가 아닌 해당 페이지의 중앙값 간격입니다. 따라서 규칙은 9포인트 또는 14포인트로 설정된 문서에 적응합니다.
라인 내부에 세 번째 임계값이 있습니다. PDF.js는 종종 간격이 없는 여러 실행에 대해 한 단어를 분할하므로 공간에서 연결이 실행되면 "filename"이 "f i l e n a m e"로 바뀝니다. 수정은 수평 간격이 글꼴 높이의 1/4을 초과하는 경우에만 공백을 삽입하는 것입니다. 이는 실제 단어 공간의 너비입니다.
이 세 가지 숫자가 출력에 대한 거의 모든 것을 결정합니다. 결과가 좋을 때 그들은 옳았습니다. 제목이 그 아래 단락에 붙어 있을 때 격차는 중앙값의 1.45배 미만이었고 규칙은 한 단락을 말했습니다.
두 개의 열이 인터리브로 나오는 이유는 무엇입니까?
열에 대한 유일한 증거는 수평 간격이고 선 그룹화는 수직 위치를 먼저 봅니다.
내 테스트 페이지의 두 블록은 공유 기준선에 줄이 있는 x 60 및 x 320에 있었습니다. 그룹화에는 6개의 기준선이 있었고, 각각은 양쪽에서 텍스트를 전달하고 각 측면에서 각각을 읽었습니다. 결과는 이 가이드의 맨 위에 있는 단락입니다. 왼쪽 열의 모든 줄 바로 옆에 있는 줄입니다.
이것은 OCR의 스크램블 열과 동일한 실패이며, 같은 근본을 가지고 있습니다. 읽기 순서는 읽을 수 없는 무언가에 의해 지오메트리로 만들어진 레이아웃에 대한 판단입니다.
열을 잘 처리하는 변환기 먼저 페이지 분할 단계를 수행하여 페이지 높이를 실행하고 라인 그룹화 전에 페이지를 분할하는 일관된 공백의 공백 밴드를 찾습니다. 그것은 거터가 넓고 규칙적인 신문이나 저널 논문에서 작동합니다. 사이드바, 견적 따옴표 또는 두 개의 열 테이블이 밴드를 끊는 일반적인 경우에서는 덜 신뢰할 수 있습니다.
문서에 열이 있는 경우 실제 답은 각 페이지의 출력을 확인하고 각 페이지의 첫 번째 단락을 수정하거나 문서가 그만한 가치가 있을 만큼 충분히 긴 경우 한 번에 열을 변환하는 것입니다.
테이블에 무슨 일이?
문장이 됩니다.
내 테스트 파일에는 3개의 열이 있는 4개의 행 테이블이 있습니다. 변환 후 전체는 다음과 같습니다.
Region Q2 Q3 EMEA 412 455 AMER 388 401 APAC 120 166
모든 가치는 살아남았습니다. 구조는 그렇지 않았습니다. 위치를 계산하고 원본의 모양을 알지 않고 412가 EMEA의 Q2 수치임을 그 선에서 알 수 없습니다.
그 이유는 대부분의 PDF에도 테이블이 포함되어 있지 않기 때문입니다. PDF의 표는 일반적으로 주변에 몇 개의 선이 그려진 좌표로 그려진 텍스트이며, 선은 동봉한 텍스트에 연결하는 파일에 없는 그래픽 작업입니다. 변환기는 숫자의 정렬을 감지하고 그리드를 추론하고 어떤 실행이 어느 셀에 속하는지 결정해야 합니다. 이는 구문 분석이 아닌 연구 문제입니다.
일부 PDF는 접근성을 위해 추가된 태그를 통해 실제 구조를 전달하며 훨씬 더 잘 변환됩니다. 그들은 소수입니다. 태그가 지정된 PDF는 인쇄 드라이버가 아닌 Word 또는 InDesign에서 신중하게 내보내기에서 가져온 것입니다.
원하는 테이블이면 스프레드시트에 손으로 복사하거나 PDF를 텍스트로 변환하고 거기에서 모양을 변경합니다. 변환된 단어 파일은 셀을 제공하지 않습니다.
내 제목이 단락에 합쳐진 이유는 무엇입니까?
그 아래의 공간이 단락 규칙을 넘어설 만큼 크지 않았기 때문입니다.
테스트 파일 2페이지에서 본문은 본문 위 40점, 몸통은 18점 간격으로 자리잡고 있다. 그 간격은 2.2배의 줄 간격으로 분할해야 하지만 그렇지 않았습니다. 왜냐하면 4개의 실행만 있는 페이지의 중앙값 간격이 신뢰할 수 있는 추정이 아니기 때문입니다. 출력은 다음과 같습니다.
Notes Note 14 covers intercompany revenue and the treatment of
deferred items carried over from the prior year.
이것이 전체 문제의 정직한 형태입니다. 임계값 규칙은 기본 리듬을 설정하고 희소한 리듬에 대해 제대로 설정하기에 충분한 텍스트가 있는 페이지에서 잘 작동합니다. 제목 페이지, 짧은 메모, 표지 또는 양식이 종종 하나의 실행 단락으로 돌아옵니다.
사실 이후에 고칠 수 있는 가장 쉬운 방법이기도 합니다. 제목은 인간 독자에게 분명하며 올바른 위치에서 Return을 누르는 데 1초가 걸립니다. 이는 올바른 도구를 만드는 데 걸리는 시간보다 짧은 시간입니다.
스캔한 페이지는 어떻게 됩니까?
아무것도 나오지 않으며 그것이 올바른 행동입니다.
내 테스트 파일의 세 번째 페이지에는 텍스트 레이어가 전혀 없었고 스캔을 위해 서 있는 회색 직사각형만 있었습니다. PDF.js는 0 실행을 반환했고 변환기는 0에 대한 단락을 생성했습니다.
페이지는 여전히 계산됩니다. 단어 파일에 빈 페이지로 나타나므로 원본과 정렬된 상태를 유지한 후에 페이지가 나뉘므로 누군가가 페이지 번호에서 작업할 때 중요합니다. 조용히 떨어뜨린 변환기는 나중에 페이지마다 이동합니다.
페이지가 모두 이미지인 PDF는 스캔이며 추출할 텍스트가 없기 때문에 변환기가 그로부터 텍스트를 추출할 수 없습니다. 필요한 것은 문자의 그림을 읽고 문자를 추측하고 고유한 오류율을 가져오는 OCR입니다. 해당 거래의 측정 버전은 다음과 같습니다. OCR을 중단하는 방법에 대한 가이드: 3도를 지나면 해상도가 아니라 스캔을 망치는 것입니다.
유용한 경험 법칙: PDF를 열고 커서로 문장을 선택하십시오. 텍스트가 강조 표시되면 변환기가 읽을 수 있습니다. 이미지 위에 선택 사각형이 있으면 먼저 OCR이 필요합니다.
나오는 .docx 안에 무엇이 있습니까?
zip에 3개의 파일이 있으며 이것이 진정으로 필요한 전부입니다.
.docx는 다음과 같이 표준화된 개방형 포장 컨벤션 아카이브입니다. ECMA-376: XML 부품과 각 부분이 무엇인지 알려주는 매니페스트가 포함된 ZIP. 마이크로소프트의 소유 형식 개요 같은 세 부분으로 걷는다. Word 문서로 열리는 최소값은 세 가지 항목입니다.
| 부분 | 목적 |
|---|---|
[Content_Types].xml |
패키지의 모든 부분의 미디어 유형을 선언합니다. |
_rels/.rels |
주 문서 부분의 포인트 |
word/document.xml |
콘텐츠 자체 |
다른 모든 단어 파일은 일반적으로, 스타일, 글꼴, 테마, 설정, 번호 지정 정의를 전달하는 선택 사항입니다. 그것들을 버리면 독자는 기본값을 적용합니다.
3페이지에 걸쳐 83단어인 테스트 문서가 1,305바이트에 도달했습니다. word/document.xml 1,169바이트입니다. TextEdit과 Pages가 사용하는 Apple의 자체 문서 리더로 열었고 페이지 나누기가 손상되지 않은 순서대로 모든 단락을 렌더링했습니다. 최소한의 패키지는 저하된 패키지가 아닙니다.
XML의 한 가지 세부 사항은 보기보다 중요합니다. 모든 실행은 다음으로 작성됩니다. xml:space="preserve". 그것 없이는 공백으로 시작하거나 끝나는 실행이 그것을 잃고, 원본에 싸여 있던 모든 줄이 다음 단어와 결합된 마지막 단어로 돌아옵니다.
이미지는 어떻게 됩니까?
그들은 삭제되고 단어 파일은 그것을 언급하지 않습니다.
여기에 작성된 패키지에는 세 부분이 있으며 그 중 어느 것도 미디어 부분이 아닙니다. 로고, 차트, 스캔한 서명, 보고서에 포함된 스크린샷: 모두 사라졌고 어디에 있는지 자리 표시자가 없었습니다. 그들을 둘러싸고 있는 텍스트는 마치 그들이 거기에 가본 적이 없는 것처럼 닫힙니다.
이것은 출력을 작고 안정적으로 만드는 동일한 디자인의 결과입니다. 이미지를 가로질러 PDF에서 이미지를 추출하고 형식을 결정하고 다음과 같이 작성하는 것을 의미합니다. word/media/, 콘텐츠 유형을 추가하고, 관계 부분을 추가하고, 흐름의 오른쪽 지점에 그리기 요소를 배치합니다. 각각은 독자가 파일을 거부하는 장소이며 .docx 워드 프로세서가 열기를 거부하는 것은 로고가 없는 것보다 더 나쁩니다.
이미지가 장식이 아닌 콘텐츠인 문서에서 가장 중요합니다. 보고서의 차트는 아무 것도 아닌 것으로 변환되며 Word 파일의 독자는 차트가 거기에 있는지 알 수 있는 방법이 없습니다. 산문에서 그림이 언급될 때 변환과 함께 원본을 확인하십시오.
파일이 때때로 열리지 않는 이유는 무엇입니까?
XML에 금지된 문자와 PDF가 포함된 문자를 제어합니다.
PDF의 텍스트 레이어는 생성된 모든 것에서 문자를 선택합니다. 양식은 인쇄 파이프라인에서, 깨진 인코딩에서 널 바이트, 문서에서 아무 의미가 없는 다른 C0 제어 코드입니다. XML 1.0 대부분의 경우를 허용하지 않으며 심지어 이스케이프 처리됩니다. 사양이 허용하는 문자 범위는 탭, 개행 및 캐리지 리턴에서 시작하고 나머지 c0 블록은 건너뜁니다.
실패는 우아하지 않습니다. Word는 문자를 경고하거나 삭제하지 않으며 파일을 열지 않고 내용을 읽을 수 없다고 말합니다. 따라서 변환기는 문자를 쓰기 전에 해당 문자를 탈출하려고 하지 않고 제거합니다. 그들은 출처에 의미가 없었고 전체 문서를 비용으로 지불했습니다.
워드 프로세서가 읽을 수 없는 것으로 거부하는 .docx를 받은 경우 이것이 가장 먼저 의심되는 문제이며, 이것이 바로 XML을 손으로 작성하는 변환기가 이에 대해 전혀 생각해야 하는 이유입니다.
단어로 변환해야 합니까 아니면 일반 텍스트로 변환해야 합니까?
워드 편집할 경우, 처리하려는 경우 텍스트를 입력하십시오.
그들은 동일한 추출을 공유합니다. 차이점은 마지막에 쓰여지는 것입니다. 하나는 XML의 ZIP에 단락을 쓰고 다른 하나는 .txt 파일에 씁니다.
| 당신은 원합니다 | 사용 | 왜냐하면 |
|---|---|---|
| 산문을 수정하고 보내십시오. | PDF에서 단어로 | 단락 구조, 페이지 나누기, 동료가 열 수 있는 것 |
| 스크립트에 검색, grep 또는 피드 | PDF에서 텍스트로 | 방법에 마크업 없음 |
| 레이아웃을 정확하게 유지 | 둘 다 아닙니다 | PDF 편집 또는 원본 파일 가져오기 |
| 스캔 읽기 | OCR 먼저 | 추출할 텍스트 레이어가 없습니다. |
3열은 함께 앉을 가치가 있는 것입니다. 레이아웃이 중요한 경우, Word로 변환하는 것은 잘못된 방향입니다. 변환은 레이아웃이 손실되는 곳이기 때문입니다. 내보낸 파일에 대해 PDF를 보낸 사람에게 물어보십시오. 하나의 메시지가 필요하며 서식을 유지하는 유일한 접근 방식입니다.
전환은 얼마나 걸립니까?
파일을 읽을 수 있을 만큼 길고 더 이상 없습니다.
인코딩 단계와 이미지 처리가 없습니다. 작업은 PDF 구조를 구문 분석하고, 각 페이지의 텍스트 콘텐츠를 가져오고, 실행을 그룹화하고, XML을 ZIP으로 직렬화하는 것입니다. 테스트 파일은 몇 밀리초가 걸렸는데, 이는 3페이지였기 때문에 유용한 숫자가 아닙니다. 200페이지 보고서는 PDF.js가 이를 구문 분석하는 것으로 제한되며, 이는 페이지 수가 대략 선형이고 빠릅니다.
큰 문서에서 알 수 있는 것은 전체 파일이 구문 분석된 구조와 함께 브라우저 탭에 보관되어 있기 때문에 메모리입니다. 이것이 속도보다는 실제 천장입니다.
출력에서 무엇을 확인해야합니까?
네 가지, 순서대로 틀릴 가능성이 있습니다.
- 모든 페이지의 첫 번째 단락. 이것은 열 인터리빙과 제목 병합이 표시되는 곳입니다.
- 어떤 테이블. 숫자가 있는지 확인한 다음 그리드가 사라진 것을 확인하고 필요한 경우 다시 빌드하십시오.
- 줄 끝에서 하이픈으로 연결된 단어. PDF의 한 줄을 가로질러 끊어진 단어가 중간에 하이픈과 함께 다시 나타납니다.
- 페이지 수. 공백 또는 스캔한 페이지를 포함하여 원본과 일치해야 합니다.
그 목록은 10페이지 분량의 문서에서 1분이 소요되며 보낼 수 있는 파일과 조용히 접합된 문장이 포함된 파일의 차이입니다.
이것이 브라우저에서 실행되는 이유는 무엇입니까?
사람들이 변환하는 문서는 계약, 명세서, 편지, 의료 결과 및 금수 조치에 따른 것입니다.
변환은 구문 분석과 zip이며 둘 다 브라우저가 완벽하게 잘 작동합니다. 파일은 디스크에서 페이지로 읽고, 웹용으로 컴파일된 PDF.js로 구문 분석되고, 메모리의 .docx로 어셈블되고, 다운로드로 다시 전달됩니다. 어떤 요청도 문서를 전달하지 않으며 서버에 저장된 것도 없으며 나중에 삭제할 수 있는 항목도 없습니다.
일반적인 대안은 PDF를 가져와서도 모르는 컴퓨터에서 변환하고 링크를 이메일로 보내는 사이트입니다. 공개 전단지의 경우 괜찮습니다. 고용 계약의 경우 의식적으로 내리도록 요청받지 않은 결정입니다.
비용은 매우 큰 파일에 대한 탭의 메모리이며 스캔한 페이지의 경우 서버 측 OCR이 없습니다. 둘 다 조용한 한계가 아니라 가시적인 한계이며, 이는 가치 있는 거래입니다.
