企业官网建设流程全解析

经常有人拿着论文和课程报告来问我：PDF到底怎么弄，为什么我交上去的PDF老师打开就变了样，为什么有的PDF在别人电脑上字变成一个个方框，为什么从网上下载的扫描版教材又歪又糊，根本没法做笔记。这些问题的答案其实都指向同一件事——PDF不是上网点一下“转换”那么简单，尤其在学术场景里，一份合格的PDF有其明确的制作规范。

这篇内容不打算讲那些大而全的“PDF百科全书”，只聚焦学术研究中最高频的几个痛点：从Word、LaTeX、Markdown生成PDF时怎么设选项，扫描版文献怎么校正和OCR还原，论文合并、字体转曲、权限设置这类交付前动作怎么做，以及本地免费工具链怎么搭。适合正在写论文的研究生、备赛的学生、需要归档课题材料的老师，也适合所有被PDF折腾过的人。

1. 送审和归档前，先检查PDF的“底料”：版本、字体与元数据

很多人在投稿或提交学位论文时，收到类似“PDF字体未嵌入”“文档属性缺失”的退修意见，第一反应是期刊系统出了问题。其实这是PDF最基础也最容易被忽略的三个底层问题：字体嵌入、元数据、PDF版本。它们不直接影响你电脑上的观感，却直接决定PDF到了别人手里还成不成立。

1.1 字体未嵌入，是PDF“换设备变样”的头号原因

PDF有一个特性叫“字体嵌入”。如果文档里用到的字体没有嵌入文件，阅读端打开PDF时就会用自己系统里的近似字体替代。Windows上好好的宋体楷体，到了Mac上可能变成其他字体，甚至变成黑方块。学术场景中这种情况尤其麻烦，因为论文里有大量生僻字、公式符号、特殊排版，替代字体一乱，全文就废了。

检查方法很简单：用Adobe Acrobat或Adobe Reader打开PDF，按Ctrl+D看“字体”选项卡，如果显示“嵌入子集”，说明字体是带进去的；如果显示“未嵌入”，就要返工。Word生成PDF时，默认会嵌入字体子集，但有个前提：生成方式要选对，不能直接用“快速打印”类的虚拟打印机，最好走“文件→导出→创建PDF/XPS”这条路径，并在选项里勾选相关字体设置。

不同字体处理也有区别。中文字体如宋体、黑体、仿宋通常没问题，但有些自定义英文字体、第三方数学字体，Word里即便勾了嵌入也可能失败。遇到这种情况，我通常直接改用LaTeX或去Adobe里做一次字体替换，再导出PDF/A，省得跟字体设置较劲。

1.2 元数据字段，决定文献管理软件认不认这篇论文

元数据就是PDF的身份证信息，包括标题、作者、主题、关键词等。Zotero、EndNote这类文献管理软件抓取PDF时，第一优先读的就是元数据。你辛辛苦苦下载的PDF，软件里显示一长串文件名，或者抓到一堆乱码，多半是这两个原因：要么元数据缺失，要么编码出问题。

在Word里生成PDF时，Word标题和文档属性会同步到PDF元数据；但很多人不设置“文件→信息→属性”里的标题、作者、关键词，所以导出的PDF头一片空白。标题里全是英文乱码的情况，则往往是字体编码不兼容导致的。解决办法是在Acrobat里“文件→属性→描述”手动补全标题、作者和DOI，再保存一次。批量处理时也能用pypdf这类Python库写脚本批量刷元数据，后面会讲具体做法。

1.3 PDF/A存档格式与版本下转换的取舍

学术存档和长期保存，推荐用PDF/A格式。PDF/A是一套专门为归档设计的PDF标准，特点是把所有资源内嵌、禁止外部依赖、不允许加密阻碍读取，从2005年到现在的PDF/A-1/2/3几个版本，基本能满足图书馆和档案馆的长期保存需求。Word的导出界面里有一个“PDF/A合规”选项，勾上即可。LaTeX用户则可以在编译时用\pdfa相关宏包或配置文件生成。

不过PDF/A也有局限：它不允许某些动态属性，比如音频视频、JavaScript，所以如果论文里有交互元素，归档版和流通版可以分开做。投稿系统如果不要求PDF/A，只要求PDF 1.4或1.7，那么Acrobat里“文件→另存为→优化器”可以调整兼容性版本。我见过不少同学往IEEE、Elsevier投稿时被系统提示版本过高，现场临时学下转换，所以在交付前把版本确认清楚，能省很多来回。

2. 三种常见生成路径：Word/WPS、LaTeX、Markdown+引擎怎么选

PDF的制作方式决定了后续所有操作的复杂度。文章初稿、课程作业、学位论文、读书笔记，不同需求对应不同生成工具和参数，我分别说一下各自门道。

2.1 Word/WPS：别用默认设置，导出选项要勾对

Word是大多数人接触PDF的第一站，但多数人只用了最粗暴的方式——“另存为PDF”。这通常够用，但进阶需求满足不了。比如论文需要目录书签、超链接、交叉引用，这些在导出时要勾选“使用书签创建导航”和“文档结构标签”。在Word的“文件→导出→创建PDF/XPS→选项”里，把这些逐项打开。

WPS的导出路径类似，但也有细节值得注意：WPS在部分Linux版本上默认字体替换策略激进，容易导致导出的PDF和原文档排版面目全非。如果你在WPS里写了一篇中文论文，导出后建议用Acrobat做一次字体嵌入和页面渲染检查，不要只看WPS内置预览。另一个高频坑是分节符和页码。学术论文前几页罗马数字、正文阿拉伯数字，WPS导PDF时如果不勾选“保留分节符和页码”，就会出现“第1页”不是封面而是目录的情况。

2.2 LaTeX：中文场景为什么绕不开xelatex与ctex

LaTeX生成的PDF质量通常最高，参考文献、公式、交叉引用都是自动排版，字体嵌入、超链接、书签这些几乎是开箱即用的品质。但新手入门踩的第一个坑就是中文环境：pdflatex编译中文容易报错，而xelatex直接支持系统字体，配合ctex宏包就能稳定输出。

以最常见的ctexart文档类为例，源代码第一行写成\documentclass[fontset=windows]{ctexart}即可调用Windows下的中文字体，Mac或Ubuntu则换成mac或ubuntu。务必用xelatex编译（VSCode或TeXstudio里切换编译器），而不是默认的pdfLaTeX。编译后生成的PDF通常自带书签，目录、标题、图表都有超链接，这对学位论文和期刊投稿很友好。

LaTeX里另一件容易忽略的事是字体子集。用\usepackage[subfont]{...}或者编译后检查，确保没有未嵌入字体。绝大多数情况下xelatex会把字体子集自动嵌入，但如果你在系统里用了某款没有嵌入权限的收费字体，就可能出问题。稳妥做法是编译完成后，用qpdf或Acrobat检查一遍字体状态。

2.3 Markdown/Pandoc：写综述和代码笔记时的进阶玩法

现在很多研究者的初稿和阅读笔记都用Markdown写，最后要交付成PDF。Markdown本身不是排版语言，需要借助Pandoc加LaTeX引擎转换。这个流程我试过很多次，体验非常舒服，尤其是搭配Zotero插件做参考文献引用。生成中文PDF时，Pandoc的命令大致是：

pandoc paper.md -o paper.pdf \ --pdf-engine=xelatex \ -V mainfont="SimSun" \ -V CJKmainfont="SimSun" \ -V geometry:margin=2.5cm \ --citeproc

这里指定了中文字体SimSun，如果没有安装，换成你系统里的中文字体名即可。Pandoc生成的PDF相对简洁，适合综述、课程报告和代码文档，但如果你的内容里有复杂的页眉页脚、学位论文封面，Pandoc不是好选择，它更适合快速输出干篇幅文档。

2.4 三条生成路径的对比与选择逻辑

选工具的原则很简单：如果文档规范和排版要求严格，直接上LaTeX；如果时间紧迫要交作业，那就用Word并检查好上面提到的导出选项；如果是自己阅读和分享用的综述，Markdown+Pandoc最省心。工具不是越高级越好，匹配场景才最重要。

3. 扫描件与历史文献：校正、清晰化和OCR还原三步走

学术研究绕不开历史文献和扫描版教材。很多图书馆扫描件本身就歪、暗、带黑色边缘；还有些PDF是纯图片，完全不能复制和检索。这一节的思路是：先做图像预处理，再做OCR识别，最后把文本层嵌回去。三步走完，一份“又歪又糊”的扫描PDF基本能变成可搜索、可标注的电子文档。

3.1 扫描参数与歪斜校正的实操建议

扫描参数是很多人忽略的第一关。做OCR和存档用途，建议300dpi起步，古籍和复杂版面可以上600dpi。彩色页面如果只是为了文字识别，灰阶就够，还能减小体积；只有需要保留原图色彩时才用彩色。扫描时如果边缘有大量黑色边框，后期可以裁切掉，用Acrobat的“优化扫描页面”或ImageMagick都能裁。

歪斜校正是“老书扫描件”最常见的处理动作。如果你手上只有一张图，用ImageMagick就能快速纠偏：

magick input.jpg -deskew 40% output.jpg

40%是允许的斜度阈值，可根据实际歪斜程度调整。核心原理是检测图像里的文本行角度，然后逆向旋转回正。对于整本PDF，可以用OCRmyPDF的--deskew参数在批量环节一并处理。遇到书本中缝文字被压弯的情况，单纯deskew解决不了，需要在扫描时用书籍扫描仪或后期配合专门软件，但大多数人到偏差在3度以内就够用了。

3.2 漂白加深清晰：让旧书页从灰糊变可读

所谓漂白，本质是把偏黄的背景压白；所谓加深，是让文字笔画的灰阶更黑。学术圈做文献扫描时，很多老书印刷质量差，整页灰蒙蒙，直接OCR识别率不高。用一个非常简单的Python PIL脚本就能处理：

from PIL import Image img = Image.open("scan_page.png").convert("L") # 阈值漂白：大于190的像素视为背景，直接置白 threshold = 190 img = img.point(lambda p: 255 if p > threshold else p) # 自动对比度增强，加深文字 from PIL import ImageOps img = ImageOps.autocontrast(img) img.save("scan_page_cleaned.png")

这里的阈值选取很关键：太高会删掉文字笔画，太低则漂不干净。我一般先对样张跑一次，找“背景灰与文字浅灰”之间的分界线。背景偏黄的页面通常建议先做灰度转换，再调阈值，不然黄底对灰度值影响很大。漂白不是每次都该做，遇到本来就清晰的扫描件，强加漂白反而会造成笔画断裂，降低OCR准确率。

3.3 OCR选型：Tesseract还是PaddleOCR

OCR识别是整个流程里的技术核心。开源方案里，Tesseract是老牌工具，5.x版本对中文支持已经不错，安装时把chi_sim中文语言包装上即可。但它对复杂排版和古籍竖排文字的弱点是明显的，竖排检测基本要额外调模型。PaddleOCR对中文场景更友好，检测和识别分离，新版PP-OCRv4的准确率明显更高，尤其在复杂背景、低分辨率、多栏排版下更稳。

我的经验是：处理期刊扫描PDF、现代书籍扫描件，优先用PaddleOCR；处理纯文本老书，Tesseract够用；如果页面里有表格、公式、分栏，任何单模型都不太可能完美，需要配合版面分析再做拼接。深度学习模型虽然在进步，但学术文献里大量标题、页眉页脚混杂，OCR结果必须人工抽查。

3.4 生成带文本层的可搜索PDF：ocrmypdf一键成型

OCR还原流程最好的落点，不是得到一串文字，而是把文字层嵌入原PDF。这样既能保持原始页面图片不丢，又能复制、搜索、标注。开源工具OCRmyPDF把图像预处理、OCR识别、文本层合成封装在了一条命令行里，这是我最推荐的一条路。它支持Tesseract和PaddleOCR后端，安装后基本用法是：

ocrmypdf --deskew --clean \ --language chi_sim \ input.pdf output.pdf

--deskew做歪斜校正，--clean做图像清理，合起来相当于把前面三步全包了。如果你已经把某页漂白加深过，可以把处理后的页替换进PDF。需要注意，OCRmyPDF对超大PDF比较吃内存，几百页的老书我通常先拆分成几个部分跑，再用后面要讲的合并工具拼回去。

4. 论文合并分割、字体转曲与交付前的最后检查

到了论文定稿阶段，大家最常遇到的是这几件事：把若干章节的PDF合成一部完整论文，给出版社提交字体兼容的最终版，以及给PDF加密、签名、设置权限。这些动作看似琐碎，实际每个都有讲究。

4.1 用qpdf和pypdf完成分页级操作

qpdf是我在命令行里最常调用的PDF工具，跨平台、免费、离线，处理合并拆分超级干脆。把一本书的第1到5页、另一本的第6到10页合成一个新PDF，一条命令搞定：

qpdf --empty out.pdf --pages a.pdf 1-5 b.pdf 6-10 --

当需要精确控制页码范围时，qpdf比图形界面里的拖拽合并快得多。它的性能很好，几百兆的PDF也不会卡死在内存里。如果要做更复杂的操作，比如把某页旋转、提取第3页的文本、给所有页加页码水印，qpdf也都能做，但更适合用Python的pypdf库。比如合并：

from pypdf import PdfReader, PdfWriter writer = PdfWriter() for fname in ["cover.pdf", "main.pdf", "appendix.pdf"]: reader = PdfReader(fname) for page in reader.pages: writer.add_page(page) writer.add_outline_item("主论文", 1) # 添加PDF书签 with open("thesis_final.pdf", "wb") as f: writer.write(f)

pypdf还能批量提取元数据、替换页面、写书签，对学术档案整理特别实用。比如我要把一学期开题、中期、预答辩、终稿PDF合并成一个文件，写一个脚本十几秒就搞定。

4.2 字体转曲：什么时候该做，什么时候别做

字体转曲是把文字变成矢量路径，让PDF不再依赖任何字体文件。好处是到任何设备上显示都绝对一致，不会缺字乱码；代价是文字不再能被复制、检索，某些阅读器里的文本选择和朗读功能也会失效。所以“转曲”这个操作必须分场景使用。

出版印刷、打印店冲印、商业交付这类场景，转曲是标准动作，因为印刷厂不一定有你用的字体。但学术场景里，导师和评审还要在PDF上批注、复制摘要、查重，这时候转曲就是灾难。我的原则是：给导师传的版本绝不转曲，给打印店出印前样张时再转曲。Acrobat里可以通过“印前检查”功能做字体转轮廓，也可以用Ghostscript做批量转曲，但转曲前一定备份原始PDF。

4.3 权限、加密与提交前的检查清单

学术交付时加密不是必须的，但有些机构或导师要求PDF不可随意编辑。在Acrobat里“文件→属性→安全”设置密码，可以限制打印、复制和修改。但必须清楚，这种权限保护是软件层限制，不是加密保护，懂工具的人很容易绕开。它只能防止误操作，不能防止刻意侵权，敏感数据不能只靠它。

我建议每份要交付的PDF都过一遍检查清单：1）全文能否正常打开，没有损坏报错；2）字体全部已嵌入；3）目录书签是否完整；4）页面尺寸统一（学位论文一般A4）；5）元数据里的标题和作者正确；6）有没有残留的审阅批注——这个最容易被忽略，Word转PDF前没删除修订记录，到了PDF里虽然不直接显示，但元数据或文本层里有时会留下痕迹；7）文件大小是否合理，超大PDF在邮件附件和投稿系统里都可能被拦截。

5. 免费本地工具链与在线转换的取舍套路

最后聊工具链。学术场景下我强烈建议至少搭一套免费、离线、本地运行的PDF处理环境，因为你处理的是论文、未发表数据和课题材料，把它们上传到不明在线服务风险不小。

5.1 我的日常工具组合与安装要点

下面是我这几年稳定在用的组合，全部免费，跨平台：

• Acrobat Reader/Adobe Acrobat：查看、基础属性修改。虽然Pro收费，但有些学校会提供机构授权。
• qpdf：命令行合并、拆分、加密、修文件，最稳的瑞士军刀。
• OCRmyPDF（配Tesseract/PaddleOCR）：扫描件统一处理，一键出可搜索PDF。
• pypdf：Python批处理脚本，适合复杂定制。
• Ghostscript：PDF/A转换、压缩、修复损坏文件。PowerShell下安装注意加入环境变量。
• PDF24 Tools：图形界面备选，处理一些小批量操作不碰命令行。

这套组合的意义在于：数据全程留在本地，处理同样的任务，速度通常也比上传下载再等排队快得多。特别是几十MB的扫描书，在线服务常常超时，命令行几秒钟就能完成合并和去黑边。

5.2 为什么学术场景我不推荐在线转换服务

不是所有在线工具都不可信，但学术材料偏偏是最不该随手上传的类型。论文里有未发表的数据、实验原始结果、导师未公开的课题思路，这些内容一旦上传到第三方服务器，你完全无法控制谁能看到、会不会被缓存、会不会被拿去训练模型。很多在线PDF网站的隐私政策写得很含糊，并且可能长期留存上传文件。无论从学术诚信还是数据安全角度，都不值得冒这个风险。

本地工具虽然需要一点学习成本，但都是花一两次就熟悉的事。你只需要记住一条：学术办公场景，默认本地处理，除非涉及跨设备远程协作或确需在线分享，再考虑上传，而且要选机构或平台官方的安全通道。

5.3 一个能提升效率的批量处理思路

当你手上有一整批PDF要做同样的事情，比如把一门课的十份参考文献统一加上标注书签、把一年的实验记录扫描件全部生成可搜索文本层，手动逐个处理会让你崩溃。我的做法是攒一个常驻脚本，用pypdf配合OCRmyPDF做流水线。

#!/bin/bash for f in *.pdf; do ocrmypdf --deskew --clean --language chi_sim "$f" "ocr_$f" done

或是在Python里循环处理元数据：

from pypdf import PdfReader, PdfWriter for fname in ["p1.pdf", "p2.pdf"]: reader = PdfReader(fname) writer = PdfWriter() writer.append_pages_from_reader(reader) writer.add_metadata({ "/Title": "课题中期报告", "/Author": "张三", "/Keywords": "PDF, 学术规范, OCR" }) with open(f"meta_{fname}", "wb") as f: writer.write(f)

这种思路的好处是：你只需要写一次脚本，之后每次批量处理都是执行一条命令的事。对我这种经常处理大量文献档案的人来说，省下的时间非常可观。

回想最开始被PDF折磨的那几年，其实所有问题都归结为一件事：没有把PDF当作一种有规范、有结构的格式来对待。它不是一个被动承装文字的容器，而是一套有字体、元数据、页面结构、权限控制的多层文档系统。把这些基本命令和设计原则吃透之后，你会发现学术研究里那些最让人抓狂的PDF问题，百分之八十都可以在几分钟内解决。至少在我这里，这套流程已经稳定跑了两年多，几乎没再因为PDF本身浪费过时间。