문서 변환에 대해 사람들을 놀라게 하는 것은 변환할 파일에 페이지가 없다는 것입니다. .docx에는 용지 크기에 대한 단락, 스타일 및 메모가 포함되어 있으며 화면에 표시되는 페이지는 Word를 열면 레이아웃을 수행하는 방식으로 생성됩니다. 다른 프로그램은 자체 글꼴과 자체의 줄 바꿈을 사용하여 해당 레이아웃을 다시 수행해야 하므로 두 변환기가 하나의 파일에서 두 개의 다른 페이지 수를 제공하는 이유입니다. 한 가지 사실이 PDF에서 추적된 삭제가 사라졌다고 생각한 것을 포함하여 출력의 모든 놀라움을 설명한다는 것을 이해합니다.
TL;DR: .docx는 실제 구조를 전달하는 XML의 zip이므로 제목, 단락 및 목록이 추론되지 않고 올바르게 도착합니다. 도착하지 않는 것은 모양입니다. 글꼴, 열, 표, 탭 중지, 번호 매기기 및 정확한 간격 부분의 라이브 간격 변환기는 명예를 위해 워드 프로세서를 구현해야 합니다. 실제 입력에서 측정된 추적 삭제가 삭제되어 편집된 문서가 최종 문구로 읽히고 번호가 매겨진 목록이 다시 글머리 기호로 표시되고 테이블이 읽기 순서대로 셀이 되며 탭이 공백이 됩니다. 서유럽 텍스트는 PDF 글꼴이 Winansi이기 때문에 키릴 문자, 그리스어, CJK 및 이모티콘은 그렇지 않습니다. 그만큼 워드로 PDF 변환기 브라우저에서 조판을 수행합니다.
.docx 내부에는 무엇이 있습니까?
XML 부품의 zip이며 그 중 하나가 여기에 중요한 모든 것을 담고 있습니다.
아카이브 도구가 있는 모든 .docx를 열면 찾을 수 있습니다. word/document.xml 매니페스트와 함께 관계 부분 및 일반적으로 스타일, 글꼴, 테마, 정의 및 설정 번호 지정. 형식은 ECMA-376, Microsoft의 소유 구현 노트 그 위에 단어가 하는 일을 다룹니다.
문서 부분은 순서입니다. <w:p> 요소. 각 항목은 단락이며, 선택적 속성이 사용되는 스타일과 목록에 속하는지 여부를 알려주는 옵션 속성이 있으며 그 안에 실제 텍스트를 전달하는 일련의 실행이 있습니다. <w:t>.
PDF가 제공하는 것보다 진정으로 낫습니다. PDF에서 단락은 선 사이의 수직 간격에서 추론해야 합니다. 다른 방향으로의 전환 열과 표를 잃게 됩니다. 여기서 단락은 파일이 그렇게 말하기 때문에 단락이고 단락이 제목 스타일을 지정하기 때문에 제목이 제목입니다.
캐치는 변환기가 읽지 않는 부분에 있습니다.
결과가 Word에서와 같지 않은 이유는 무엇입니까?
모양이 워드 프로세서에 해당하는 부분에 걸쳐 퍼져 있고 변환기가 대신 텍스트를 새로 입력하기 때문입니다.
텍스트는 문서 부분에 있습니다. 11의 줄 간격이 있는 11의 Calibri에 텍스트가 표시되는 이유는 다음과 같습니다. styles.xml. 목록이 "A., B., C."가 아닌 "1., 2., 3."이라고 읽는 이유는 다음과 같습니다. numbering.xml. 제목 색상을 제공하는 테마는 다른 부분에 다시 포함되며 섹션 속성은 섹션당 여백, 열 및 페이지 크기를 제어합니다.
이 모든 것을 존중하는 것은 Word의 의미론을 사용하여 레이아웃 엔진을 구축하는 것입니다. 이 도구가 대신하는 작업은 구조를 읽고 깔끔하게 배치하는 것입니다. 본문 텍스트의 경우 Times Roman, 제목에 대한 Times Roman, 선택한 페이지 크기의 56포인트 여백, 1.4줄 간격으로 구조를 읽습니다.
따라서 출력은 원본과 같지 않은 읽을 수 있는 올바른 순서로 정렬된 문서입니다. 이 개종을 찾는 사람들이 두 그룹으로 나뉘고 그 중 하나만 섬기기 때문에 그것은 진정한 한계이며 매장하기보다는 분명히 말할 가치가 있습니다. 누구나 열 수 있는 PDF로 텍스트를 원한다면 이것이 맞습니다. 당신이 원한다면 그 페이지, 글꼴과 간격을 사용하여 Word 자체 내보내기에 대한 섹션을 계속 읽으십시오.
전환에서 살아남은 것은 무엇입니까?
구조와 읽기 순서, 안정적으로. 다음은 가정이 아닌 코드에 대해 측정된 전체 목록입니다.
| 요소 | 결과 |
|---|---|
| 단락 | 문서 순서대로 보존됨 |
| 제목 | 보존, 크기별 크기, 굵게 설정 |
| 항목 나열 | 텍스트 보존, 글머리 기호로 대체된 마커 |
| 테이블 셀 | 읽기 순서대로 별도의 단락으로 보존 |
| 추적 삭제 | Word가 표시할 때 삭제됨 |
| 탭 및 줄바꿈 | 하나의 공간이 되다 |
| 굵은, 기울임꼴, 색상, 글꼴 | 운반되지 않음 |
| 이미지 | 운반되지 않음 |
| 머리글, 바닥글, 페이지 번호 | 운반되지 않음 |
| 각주 및 미주 | 운반되지 않음 |
그 표의 위쪽 절반은 이 변환이 여전히 가치가 있는 이유입니다. 그 안에 아무 것도 추측할 필요가 없었습니다. 하반부는 Word를 구현하지 않는 가격입니다.
추적된 변경 사항은 어떻게 됩니까?
삭제가 사라지고, 맞습니다. 그리고 그것이 말해야 한다는 사실이 흥미로운 부분입니다.
변경 추적으로 편집된 문서는 파일에서 제거된 텍스트를 내부에 유지합니다. <w:delText> 이내 <w:del> 요소. Word는 현재 텍스트로 표시하지 않는다는 것을 알고 있습니다. 누군가가 그것에 대해 생각하지 않는 한 모든 텍스트 노드를 걷는 변환기는하지 않습니다.
원래 "Deadline은 3월 31일"이라고 읽은 단락에서 측정되고 "4월 30일"로 편집되었습니다.
with the rule: The deadline is 30 April.
without the rule: The deadline is 31 March30 April.
그 문장의 모든 버전은 누구나 타이핑하고 함께 실행하고 그들 사이에 공백이 없습니다. 계약서나 제안서에서 이것은 미용 버그가 아닙니다. PDF를 받는 사람에게 문서의 협상 이력을 게시합니다.
어떤 도구를 사용하든 그 자체로 알 가치가 있습니다. 변환된 문서를 외부로 보내는 경우 변경한 날짜나 그림이 두 번이 아니라 한 번 표시되는지 확인합니다.
번호 매기기 목록은 어떻게 됩니까?
숫자가 단락에 없기 때문에 글머리 기호로 돌아옵니다.
목록 단락이 전달하는 <w:numPr>, 다른 부분의 번호 매기기 정의를 가리킵니다. 이 정의는 형식, 시작 값, 들여쓰기 수준 및 이 목록이 이전 목록을 계속 유지하는지 여부를 보유합니다. 단락 자체에는 텍스트가 있고 다른 것은 없습니다.
따라서 문서 부분만 읽는 변환기는 단락이 목록 항목이며 어떤 마커를 가지고 있어야 하는지를 알고 있습니다. 글머리 기호를 렌더링하는 것은 정직한 기본값입니다.
• First point
• Second point
Ordinary paragraph
이것은 숫자가 의미를 지닐 때 중요합니다. "4단계 참조" 절차 또는 계약서의 번호가 매겨진 절은 참조를 잃습니다. 문서의 번호에 따라 달라지는 경우 이 변환은 잘못된 전환이며 Word 자체 내보내기가 올바른 것입니다.
테이블에 무슨 일이?
세포는 살아남고 그리드는 그렇지 않습니다.
테이블 셀에는 다음이 포함됩니다. <w:p> 다른 것과 마찬가지로 요소가 있으므로 텍스트는 읽기 순서대로 일반 단락으로 도착합니다. 지역과 그림의 두 열 테이블은 다음과 같이 나옵니다.
Region | Q2 | EMEA | 412
처음 두 개의 단락이 헤더 행이라는 것을 기록하는 내용이 없는 4개의 단락이 차례로 있습니다. 테이블을 가로질러 테이블을 가로질러 열 너비, 행 구조, 병합된 셀 및 테두리를 전달한 다음 페이지를 매기는 그리드를 배치하는 것을 의미합니다. 이는 다른 훨씬 더 큰 도구입니다.
이것은 양방향에서 동일한 거래입니다. PDF는 PDF에 PDF가 없었기 때문에 PDF를 워드로 평평하게 하고, 하나를 다시 작성하는 것이 레이아웃 엔진이기 때문에 PDF로의 Word가 평평해집니다. 두 경우 모두 정직한 조언: 테이블이 요점이라면 스크린샷을 찍거나 원본을 유지하십시오.
탭 정렬 레이아웃이 축소된 이유는 무엇입니까?
탭은 위치 명령이고 탭 정지가 없으면 보낼 곳이 없기 때문입니다.
<w:tab/> "다음 탭 정지로의 진행"을 의미하며, 정지는 단락의 속성에 정의되거나 해당 스타일에서 상속됩니다. 자신의 여백이 있는 텍스트를 배치하는 변환기는 점프할 의미 있는 중지가 없으므로 탭이 단일 공백이 됩니다. 에 대해서도 마찬가지입니다 <w:br/>:
input: Name <tab> Value <br> Next line
output: "Name Value Next line"
두 개의 열 목록, 서명 블록 또는 탭이 있는 간단한 목차를 만든 사람은 정렬을 완전히 잃습니다. 변환된 문서가 잘못되어 보이는 가장 일반적인 방법 중 하나이며 소스에서 보이지 않습니다. 파일이 원래의 단락처럼 보입니다.
정렬이 중요한 경우 원본 문서의 실제 테이블이 더 나아지지 않지만 최소한 더 명확하게 실패합니다.
내장 PDF 글꼴이 렌더링되지 않는 문자는 무엇입니까?
서유럽 라틴어 이외의 모든 것, 그리고 실패는 어떤 성격이 잘못되었는지에 대해 침묵하곤 했습니다.
PDF 표준은 모든 독자가 가지고 있는 14개의 기본 글꼴을 정의하며, 이 글꼴은 부록 D에 문서화된 256자 세트인 WinAnsiEncoding으로 인코딩됩니다. PDF 사양. 그것들을 사용하면 글꼴이 내장되어 있지 않아도 되며, 이는 출력을 작게 유지하며 알파벳이 고정되었음을 의미합니다.
테스트 pdf-lib, 그리기를 하는 라이브러리:
| 텍스트 | 결과 |
|---|---|
Quarterly report |
렌더링 |
"Revenue" rose, he'd said 곱슬 따옴표로 |
렌더링 |
| em 대시를 사용하는 문장, u+2014 | 렌더링 |
Chiffre d'affaires réalisé en Août |
렌더링 |
Total: €1,249.50 |
렌더링 |
Отчёт за квартал |
실패: WinAnsi cannot encode "О" (0x041e) |
Αποτελέσματα |
실패: WinAnsi cannot encode "Α" (0x0391) |
季度报告 |
실패: WinAnsi cannot encode "季" (0x5b63) |
四半期報告 |
실패: WinAnsi cannot encode "四" (0x56db) |
Revenue up 🚀 |
실패: WinAnsi cannot encode "🚀" (0x1f680) |
프랑스어, 독일어, 스페인어, 포르투갈어, 이탈리아어 및 북유럽 언어는 괜찮으며 유로 기호, 곱슬 인용 및 EM 대시도 마찬가지입니다. 러시아어, 그리스어, 중국어, 일본어, 한국어, 아랍어, 히브리어, 힌디어 및 모든 이모티콘은 그렇지 않습니다.
이 도구는 문서를 변환할 수 없다고 말하는 대신 오류에 문자를 지정합니다. "이 문자를 제거"는 조언이고 "뭔가 잘못되었습니다"가 아니기 때문입니다. 이러한 스크립트 중 하나의 문서에는 해당 글꼴을 포함하는 변환기가 필요합니다. 이는 더 큰 PDF와 다른 도구를 의미합니다.
.doc 파일이 거부되는 이유는 무엇입니까?
.doc 및 .docx는 세 글자를 공유하는 다른 형식이기 때문입니다.
.docx는 2007년에 도입된 XML의 ZIP입니다. .doc는 90년대 초반으로 거슬러 올라가는 레이아웃의 복합 이진 파일이며, 파서가 걸어야 하는 구조물 사이에 텍스트가 인터리브되어 있습니다. 하나를 읽는 것은 다른 것을 읽는 변형이 아니라 별도의 구현입니다.
따라서 변환기는 읽을 수없는 zip에서 실패하는 대신 확장을 확인하고 그렇게 말합니다.
| 파일 | 그것이 말하는 것 |
|---|---|
.doc |
그것은 이전 형식입니다. 열고 .docx로 저장 |
.rtf, .odt, .pages |
워드 문서가 아닙니다. .docx로 내보내기 |
.pdf |
이미 PDF입니다. 편집 가능한 파일에 대해 다른 방향을 사용하십시오. |
Word, LibreOffice 또는 Google 문서에서 .doc를 열고 .docx로 저장하는 데 몇 초가 걸리며 이러한 프로그램이 잘 수행하는 변환입니다.
제목의 크기는 어떻게 구성되며 얼마나 깊이 들어가는가?
레벨별로, 세 번째 레벨을 지나는 모든 것이 세 번째 수준으로 처리되는 굵게.
두 철자가 모두 야생에 존재하기 때문에 스타일 이름은 단락에서 읽고 정규화됩니다. 단어 쓰기 Heading1; 여러 문서 생성기가 쓰기 heading 1. 둘 다 같은 수준으로 해결하고 Title 1급으로 취급됩니다.
| 파일의 스타일 | 사용 레벨 |
|---|---|
Title, Heading1, heading 1 |
1 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 100 X 1 |
Heading2 |
2 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X 2000 X |
Heading3 |
3 X 1000 X 1000 X 1000 X 100 X 100 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X |
Heading4 통해 Heading9 |
3 X 1000 X 1000 X 1000 X 100 X 100 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X 30 X |
ListParagraph, BodyText, 다른 무엇이든 |
본문 텍스트 |
세 가지 시각적 수준은 의도적인 중지 지점입니다. 세 번째 수준과 구별할 수 있는 네 번째 수준은 본문과 충돌하기 시작하는 또 다른 크기 단계 또는 기본 글꼴이 제공하지 않는 가중치 또는 스타일 변경이 필요합니다.
PDF는 몇 페이지입니까?
숫자 단어가 당신에게 보여주지 않았고 그 차이는 버그가 아닙니다.
줄 바꿈은 글꼴에 따라 달라지므로 Times Roman의 12 점에서 동일한 단락이 11의 Calibri에서와 다른 줄의 줄을 차지합니다. 여백이 다릅니다. 선 간격이 다릅니다. 줄 끝점을 결정하는 모든 것이 변경되므로 페이지 매김이 변경됩니다.
측정된 실행에서 1개의 제목과 약 40개의 단어로 구성된 10개의 단락이 각각 2개의 A4 페이지로 배치된 문서: 첫 번째 줄에 39줄, 두 번째 줄에 2줄, 제목이 12포인트 본문에 대해 굵게 20.4점으로 설정되어 있습니다.
실질적인 결과는 페이지 참조가 중단된다는 것입니다. "7페이지에 설명된 대로" 변환된 문서의 "6" 또는 8" 페이지가 될 수 있다. 자체 페이지를 상호 참조하는 문서는 레이아웃이 참조가 작성된 Word에서 내보내야 합니다.
대신 Word의 자체 내보내기를 언제 사용해야 합니까?
모양이나 페이지 매김이 콘텐츠의 일부일 때마다. 그것은 소리보다 짧은 목록이지만 그에 대한 항목이 중요합니다.
| Word의 내보내기 사용 | 변환기를 사용 |
|---|---|
| 디자인 문서:레터헤드, 이력서, 브랜딩이 있는 보고서 | PDF로 필요한 일반 텍스트 문서 |
| 표, 이미지, 머리글 또는 바닥글이 있는 모든 것 | 메모, 기사, 초안, 성적표 |
| 번호가 매겨진 절 또는 상호 참조 페이지 | 읽기 순서만 있으면 되는 모든 문서 |
| 비라틴어 스크립트의 문서 | 어디에도 업로드하지 않는 문서 |
Word의 파일, 다른 이름으로 저장, PDF는 진정한 내보내기입니다. 페이지를 그린 동일한 레이아웃 엔진이 PDF를 작성하므로 보는 것이 얻는 것입니다. 브라우저의 레이아웃 엔진이 브라우저의 어떤 것도 없기 때문에 브라우저의 어떤 것도 일치하지 않습니다.
변환의 경우는 해당 테이블의 마지막 행이며 Word to Hand가 없습니다.
이것이 브라우저에서 실행되는 이유는 무엇입니까?
문서는 사람들이 변환하는 가장 개인적인 파일이기 때문에 이 변환에는 서버에 아무것도 필요하지 않습니다.
zip 읽기, XML 구문 분석 및 텍스트 그리는 것은 브라우저가 기본적으로 수행하는 모든 것입니다. 파일은 디스크에서 탭으로 읽고 압축을 풀고 거기에 배치하고 PDF에 기록하고 다운로드로 다시 전달합니다. 문서를 전달하는 요청이 없으며 어디에도 사본이 남아 있지 않습니다.
문제의 문서는 계약서, 이력서, 의료 서신, 법률 초안 및 논문입니다. 기존의 대안은 서비스에 업로드하고, 당신이 전혀 알지 못하는 컴퓨터에서 변환하고, 아무도 읽지 않는 정책에 설명된 일정 기간 동안 유지합니다.
한계는 정직한 것입니다. 서유럽 텍스트만, 이미지 없음, 제목 및 글머리 기호 이상의 서식 지정이 없습니다. 그것들은 당신이 더 이상 제어할 수 없는 문서의 더 멋진 PDF일 때 취하는 것이 가치가 있는 거래입니다.
