1. 为什么“PDF/Word 转可编辑 PPT”是个真需求先说说我自己的经历。上个月帮一个做培训的朋友整理课件他丢过来一份 60 多页的 PDF 讲义外加一份 Word 版的大纲说“你帮我弄成 PPT 吧明天要用”。我当时第一反应是复制粘贴呗。结果打开 PDF 一看全是图文混排表格、流程图、公式一样不少手动搬一页至少五分钟60 页就是五个小时还不算排版对齐的时间。那天晚上我干到凌晨两点第二天顶着黑眼圈去交付心里就一个念头——这事儿必须得有更聪明的办法。后来我陆续试了不少方案也踩了一堆坑最后摸索出一套相对稳定的思路也就是今天要聊的ppt-master这类工具背后的核心逻辑把 PDF/Word 里的内容结构化提取出来再映射成 PowerPoint 能识别的对象模型最终生成真正可编辑的 PPT 文件。注意这里的重点词是“可编辑”——不是把 PDF 每页截个图贴进幻灯片那种“假 PPT”谁都会做但改一个字都改不了等于白干。这篇文章适合谁看如果你是经常要做课件、做汇报、做方案的人手里攒了一堆 PDF 和 Word 资料又不想一页一页手动搬或者你是做自动化办公、文档处理的开发者想搞清楚这类工具到底是怎么实现的、有哪些坑那这篇内容应该能帮到你。我会从整体设计思路讲起然后拆解核心技术点再给出一套可复现的实操流程最后把我踩过的坑和排查经验整理成速查表。全程说人话不堆术语能抄作业的地方直接给方案。2. 整体设计思路为什么不能“直接转”而要“重建”2.1 先搞清楚 PDF、Word、PPT 三者的本质差异很多人以为格式转换就是“换个后缀名”这是最大的误解。PDF、Word、PPT 这三种格式底层的数据模型完全不一样理解这一点后面所有的技术选型和坑点就都能想通了。PDF 的本质是“打印描述”。它不关心你这段文字是标题还是正文它只关心“在 A4 纸的这个坐标位置用这个字体、这个字号画这几个字”。所以 PDF 里没有“段落”这个概念只有一堆带坐标的文本片段和图形指令。你从 PDF 里提取出来的文字顺序可能是乱的因为它是按绘制顺序存的不是按阅读顺序。Word 的本质是“流式文档”。它关心的是内容的逻辑结构——这是标题、这是段落、这是表格至于具体显示在页面的哪个位置是排版引擎根据页面大小动态算出来的。所以 Word 里有清晰的样式层级提取结构相对容易。PPT 的本质是“对象画布”。每一页幻灯片是一个画布上面摆放着一个个独立的对象文本框、图片、表格、形状。每个对象有自己的位置、大小、层级关系。PPT 关心的是“这个对象放在这个位置”而不是“这段文字属于哪个段落”。理解了这三者的差异你就明白为什么“一键转换”这么难了PDF 转 PPT本质上是从“坐标描述”反推“逻辑结构”再重建“对象模型”这是一个信息损失后再重建的过程。而 Word 转 PPT 相对简单因为逻辑结构还在主要工作是做“结构映射”和“版式重排”。2.2 ppt-master 这类工具的核心思路拆解我研究过几个类似工具的实现包括 ppt-master 这个方向上的方案核心思路基本可以归纳为三步第一步内容提取与结构化。从源文件里把文字、图片、表格、图形分别抽出来并且尽量还原它们的逻辑关系。PDF 走的是“版面分析”路线通过文字块的坐标、字号、字体加粗等特征推断哪些是标题、哪些是正文、哪些是表格。Word 则直接读样式和文档对象模型省事很多。第二步版式映射与重排。把提取出来的结构映射到 PPT 的版式上。这里有个关键决策是“保真优先”还是“可编辑优先”保真优先就是尽量还原原文档的视觉效果但可能生成一堆图片和文本框编辑性差可编辑优先就是牺牲一点视觉还原度把内容拆成规范的文本框、表格对象方便后续修改。ppt-master 这类工具通常走的是可编辑优先路线因为用户的核心诉求就是“能改”。第三步生成 PPTX 文件。PPTX 本质上是一个 ZIP 压缩包里面是一堆 XML 文件描述了每一页幻灯片上有哪些对象、每个对象的属性是什么。生成 PPTX 就是按照这个规范把内容写成对应的 XML 结构。这一步用 python-pptx 这类库可以大大简化工作量。2.3 为什么选择“可编辑优先”而不是“截图保真”这里我要重点说一下这个决策背后的逻辑因为这是很多人做这类工具时最容易走偏的地方。我早期试过一个方案思路很简单把 PDF 每页渲染成高清图片然后一张图一页塞进 PPT。这个方案实现起来十分钟搞定视觉效果百分百还原。但问题在于用户拿到之后想改一个错别字发现改不了因为那是图片。想调整一下某段话的位置也调不了。最后用户还是得手动重做等于这个工具没解决问题。所以真正有价值的方案必须是可编辑优先。这意味着你要接受一定的视觉损失——比如原来 PDF 里那种复杂的图文环绕排版转成 PPT 后可能变成上下结构原来精确到像素的对齐转过来可能有几像素的偏差。但换来的是每一个文字都能改、每一个表格都能编辑、每一张图片都能替换这才是用户真正要的。提示如果你做这类工具是给自己用先想清楚你的核心场景。如果是“一次性展示、不需要改”截图方案最省事如果是“后续还要反复修改”那必须走可编辑路线前期多花的时间后面都能省回来。3. 核心技术点深度拆解从 PDF/Word 到 PPTX 的每一步3.1 PDF 内容提取版面分析是绕不过去的坎PDF 提取文字本身不难PyMuPDF、pdfplumber 这些库都能干。难的是还原逻辑结构。我给你举个例子一个典型的 PDF 页面提取出来的原始数据大概长这样# 用 pdfplumber 提取的原始文字块示例简化 blocks [ {text: 第三章 数据分析, x0: 72, top: 100, size: 18, bold: True}, {text: 3.1 数据清洗, x0: 72, top: 140, size: 14, bold: True}, {text: 在进行数据分析之前需要先对原始数据进行清洗..., x0: 72, top: 170, size: 11, bold: False}, {text: 图 3-1 数据清洗流程, x0: 200, top: 400, size: 10, bold: False}, ]你看这些块本身没有“标题”“正文”的标签只有坐标、字号、是否加粗这些特征。所谓版面分析就是根据这些特征去推断字号 18 且加粗的大概率是一级标题字号 14 且加粗的可能是二级标题字号 11 不加粗的是正文字号 10 且位置在图片下方的可能是图注。我实际用下来这套推断规则不需要搞得太复杂几个核心特征就够了特征推断规则备注字号比正文平均字号大 1.3 倍以上需先统计全文正文字号分布加粗字体名包含 Bold 或字重 600部分 PDF 字体名不规范需容错位置左侧缩进小于正文或居中居中且字号大的通常是主标题行间距与上下块间距明显大于正文行距用于判断段落边界编号模式以“第X章”“X.X”“一、”等开头正则匹配辅助判断层级这里有个坑我要特别提醒不要试图用一套规则适配所有 PDF。不同来源的 PDF字体嵌入方式、字号体系、排版习惯都不一样。我的做法是先跑一遍统计算出这份文档的“正文字号基准值”然后再用相对值去判断而不是写死“字号大于 16 就是标题”。这个自适应逻辑能让准确率从六七成提到九成以上。3.2 Word 内容提取结构清晰但版式是难点Word 这边就舒服多了python-docx 可以直接遍历文档的段落、表格、图片而且每个段落都有 style 属性直接告诉你这是 Heading 1 还是 Normal。from docx import Document doc Document(input.docx) for para in doc.paragraphs: style_name para.style.name # 如 Heading 1、Normal text para.text # 根据 style_name 直接映射到 PPT 的标题层级但 Word 转 PPT 的难点不在提取而在版式重排。Word 是流式的一页可以很长PPT 是分页的每页容量有限。你不能把 Word 的一整段直接塞进一页 PPT那样字会小到看不清。所以需要做内容分页根据段落长度、标题层级把内容切分成一页一页的幻灯片。我的分页策略是这样的一级标题强制新起一页作为章节页二级标题如果当前页内容超过 60% 就新起一页正文段落累计超过一定字数比如 300 字就考虑分页。这个阈值可以根据实际效果调没有绝对标准。3.3 图片与表格的处理最容易翻车的环节图片处理相对简单从 PDF 里提取图片用 PyMuPDF 的get_images()就行Word 里用 python-docx 也能拿到。但有两个坑坑一图片位置丢失。PDF 里图片和文字的环绕关系很复杂提取出来的图片往往不知道应该放在哪段文字旁边。我的做法是记录图片的坐标然后找距离它最近的文字块作为它的“锚点段落”转 PPT 时把图片放在对应文字附近。坑二图片清晰度。有些 PDF 里的图片是压缩过的提取出来放大就糊。如果原图分辨率不够转成 PPT 后投影出来效果很差。这个没办法完全解决但可以在提取时优先选原始嵌入的图片流而不是渲染后的位图。表格处理更麻烦。PDF 里的表格本质上是一堆线条和文字你需要先识别出表格的边框线再推断行列结构。pdfplumber 有extract_tables()方法对规整表格效果不错但遇到合并单元格、无边框表格就容易出错。我的经验是能识别就转成 PPT 原生表格识别不了就退化成图片不要硬转否则生成一堆错位的文本框更难看。3.4 PPTX 生成python-pptx 的正确打开方式生成 PPTX 这一步python-pptx 基本是标配。它的核心对象模型很清晰Presentation 包含 SlidesSlide 包含 ShapesShape 可以是文本框、图片、表格、形状。from pptx import Presentation from pptx.util import Inches, Pt prs Presentation() # 使用空白版式避免默认占位符干扰 blank_layout prs.slide_layouts[6] slide prs.slides.add_slide(blank_layout) # 添加标题文本框 title_box slide.shapes.add_textbox(Inches(0.5), Inches(0.3), Inches(9), Inches(0.8)) title_frame title_box.text_frame title_frame.text 第三章 数据分析 title_frame.paragraphs[0].font.size Pt(28) title_frame.paragraphs[0].font.bold True # 添加正文文本框 body_box slide.shapes.add_textbox(Inches(0.5), Inches(1.3), Inches(9), Inches(5)) body_frame body_box.text_frame body_frame.word_wrap True body_frame.text 在进行数据分析之前需要先对原始数据进行清洗... body_frame.paragraphs[0].font.size Pt(16) prs.save(output.pptx)这里有个关键技巧用空白版式layout 6而不是默认版式。默认版式带一堆占位符位置和大小都是固定的你往里塞内容经常对不齐。用空白版式所有对象都自己用坐标定位反而更可控。另一个技巧是文本框自动调整。PPT 的文本框有个auto_size属性可以设置成根据内容自动调整高度。但实测下来这个功能不太靠谱经常算错。我的做法是手动估算中文字符按每个字 0.35 厘米宽算一行能放多少字需要几行再乘以行高得出文本框高度。虽然土但稳定。4. 完整实操流程从零搭一个可用的转换脚本4.1 环境准备与依赖安装先把环境搭起来。我用的 Python 3.10依赖库就四个核心的pip install pymupdf pdfplumber python-docx python-pptx pillow简单说下各自的分工PyMuPDF 负责 PDF 的文字和图片提取速度快pdfplumber 负责表格提取准确率比 PyMuPDF 高python-docx 处理 Wordpython-pptx 生成 PPTpillow 处理图片格式转换。注意PyMuPDF 的包名是pymupdf但导入时是import fitz这个历史遗留问题坑过不少人别装错了。4.2 PDF 转 PPT 的完整代码框架下面这套框架是我实际用下来比较稳的核心逻辑是“提取-分析-分页-生成”四步走。代码做了简化但关键环节都在。import fitz # PyMuPDF import pdfplumber from pptx import Presentation from pptx.util import Inches, Pt, Emu from PIL import Image import io import re class PDFToPPT: def __init__(self, pdf_path): self.pdf_path pdf_path self.doc fitz.open(pdf_path) self.body_font_size self._estimate_body_font_size() def _estimate_body_font_size(self): 统计全文正文字号基准值 size_count {} for page in self.doc: blocks page.get_text(dict)[blocks] for block in blocks: if lines not in block: continue for line in block[lines]: for span in line[spans]: size round(span[size]) size_count[size] size_count.get(size, 0) len(span[text]) # 取出现次数最多的字号作为正文基准 return max(size_count, keysize_count.get) def _classify_block(self, span): 根据字号和字重判断块类型 size span[size] is_bold bold in span[font].lower() or span[flags] 2**4 ratio size / self.body_font_size if ratio 1.6 and is_bold: return h1 elif ratio 1.25 and is_bold: return h2 elif ratio 1.1 and is_bold: return h3 else: return body def extract_structured_content(self): 提取结构化内容 structured [] for page_num, page in enumerate(self.doc): blocks page.get_text(dict)[blocks] for block in blocks: if lines not in block: # 图片块 structured.append({ type: image, page: page_num, bbox: block[bbox] }) continue for line in block[lines]: for span in line[spans]: text span[text].strip() if not text: continue block_type self._classify_block(span) structured.append({ type: block_type, text: text, page: page_num, bbox: span[bbox], size: span[size] }) return structured def generate_ppt(self, output_path): structured self.extract_structured_content() prs Presentation() prs.slide_width Inches(13.333) # 16:9 prs.slide_height Inches(7.5) blank_layout prs.slide_layouts[6] current_slide None y_cursor Inches(0.5) for item in structured: if item[type] h1: # 一级标题新起一页 current_slide prs.slides.add_slide(blank_layout) y_cursor Inches(0.5) self._add_text(current_slide, item[text], Inches(0.5), y_cursor, Inches(12), Inches(1), font_size32, boldTrue) y_cursor Inches(1.2) elif item[type] in (h2, h3): if current_slide is None: current_slide prs.slides.add_slide(blank_layout) font_size 24 if item[type] h2 else 20 self._add_text(current_slide, item[text], Inches(0.5), y_cursor, Inches(12), Inches(0.8), font_sizefont_size, boldTrue) y_cursor Inches(0.9) else: if current_slide is None: current_slide prs.slides.add_slide(blank_layout) # 估算文本框高度 char_count len(item[text]) lines max(1, char_count // 40 1) height Inches(0.4 * lines) if y_cursor height Inches(7): current_slide prs.slides.add_slide(blank_layout) y_cursor Inches(0.5) self._add_text(current_slide, item[text], Inches(0.5), y_cursor, Inches(12), height, font_size16, boldFalse) y_cursor height Inches(0.1) prs.save(output_path) def _add_text(self, slide, text, left, top, width, height, font_size, bold): box slide.shapes.add_textbox(left, top, width, height) frame box.text_frame frame.word_wrap True frame.text text para frame.paragraphs[0] para.font.size Pt(font_size) para.font.bold bold para.font.name 微软雅黑这段代码跑下来基本的文字内容能转得七七八八。但你会发现图片没处理表格也没处理这就是为什么我说“框架”而不是“成品”。实际用的时候图片和表格要单独加逻辑下面说。4.3 图片提取与插入的实操细节图片这块PyMuPDF 提取出来的是字节流需要转成 PIL 能处理的格式再存成临时文件或者直接塞进 PPT。def extract_images(self): images [] for page_num, page in enumerate(self.doc): img_list page.get_images(fullTrue) for img_index, img in enumerate(img_list): xref img[0] base_image self.doc.extract_image(xref) image_bytes base_image[image] image_ext base_image[ext] # 过滤掉太小的图片通常是图标或装饰 pil_img Image.open(io.BytesIO(image_bytes)) if pil_img.width 50 or pil_img.height 50: continue images.append({ page: page_num, bytes: image_bytes, ext: image_ext, width: pil_img.width, height: pil_img.height }) return images插入 PPT 的时候用slide.shapes.add_picture()传入 BytesIO 对象就行。这里有个尺寸问题原图可能很大直接插进去会超出幻灯片边界。我的做法是按幻灯片可用宽度等比缩放最大宽度设为 10 英寸高度按原图比例算。实操心得提取图片时一定要过滤小图。PDF 里经常有一堆 1x1 像素的透明占位图、分隔线、项目符号这些提取出来插进 PPT 就是一堆没用的东西还会把版面搞乱。我一般设 50x50 像素作为阈值低于这个的直接丢掉。4.4 Word 转 PPT 的差异化处理Word 转 PPT 的代码结构和 PDF 类似但提取部分简单很多重点在分页逻辑。from docx import Document from docx.shared import Pt as DocxPt def word_to_ppt(docx_path, output_path): doc Document(docx_path) prs Presentation() prs.slide_width Inches(13.333) prs.slide_height Inches(7.5) blank_layout prs.slide_layouts[6] current_slide None y_cursor Inches(0.5) body_char_count 0 for para in doc.paragraphs: text para.text.strip() if not text: continue style para.style.name if style.startswith(Heading 1): current_slide prs.slides.add_slide(blank_layout) y_cursor Inches(0.5) body_char_count 0 add_text(current_slide, text, Inches(0.5), y_cursor, Inches(12), Inches(1), 32, True) y_cursor Inches(1.2) elif style.startswith(Heading 2): if current_slide is None or body_char_count 200: current_slide prs.slides.add_slide(blank_layout) y_cursor Inches(0.5) body_char_count 0 add_text(current_slide, text, Inches(0.5), y_cursor, Inches(12), Inches(0.8), 24, True) y_cursor Inches(0.9) else: if current_slide is None: current_slide prs.slides.add_slide(blank_layout) char_count len(text) lines max(1, char_count // 40 1) height Inches(0.4 * lines) if y_cursor height Inches(7) or body_char_count 400: current_slide prs.slides.add_slide(blank_layout) y_cursor Inches(0.5) body_char_count 0 add_text(current_slide, text, Inches(0.5), y_cursor, Inches(12), height, 16, False) y_cursor height Inches(0.1) body_char_count char_count prs.save(output_path)Word 转 PPT 有个额外的好处样式信息是现成的不用像 PDF 那样去猜。所以准确率会高很多。但要注意有些人写 Word 不规范全篇都用 Normal 样式标题只是手动加粗放大。这种情况就得退回到 PDF 那套特征分析逻辑根据字号和加粗来判断层级。4.5 参数选择与效果调优这套流程跑通之后效果好不好主要看几个参数怎么调。我整理了一个对照表方便你按自己的场景调参数作用建议值调整影响正文字号基准判断标题层级的参照自动统计设错会导致标题正文误判标题字号倍率h1/h2/h3 的阈值1.6/1.25/1.1调低会多识别标题调高会漏每页最大字数控制分页300-400 字太小页数多太大字太小图片最小尺寸过滤装饰图50x50 px调高会漏掉小图表文本框行高估算高度0.4 英寸/行影响排版紧凑度幻灯片尺寸页面比例13.333x7.5 英寸16:9 是主流4:3 用 10x7.5这些值不是拍脑袋定的是我反复试出来的。比如每页最大字数我试过 200 字结果 60 页的 PDF 转出来 80 多页 PPT翻页翻到手酸试过 600 字结果字小到投影看不清。300 到 400 字之间是个比较舒服的区间一页大概 8 到 10 行正文看着不累。5. 常见问题与排查技巧实录5.1 转换后文字乱序怎么办这是 PDF 转 PPT 最常见的问题没有之一。表现就是明明原文是“第一段、第二段、第三段”转出来变成“第三段、第一段、第二段”或者一句话被拆成好几段。根本原因PDF 里的文字是按绘制顺序存储的不是按阅读顺序。有些 PDF 生成工具会先画右边的批注再画左边的正文提取出来顺序就乱了。排查思路先看乱序的范围。如果是整页乱那是绘制顺序问题如果是段落内乱那是文字块拆分问题。解决方法按坐标排序。对同一页的所有文字块先按纵坐标top排序纵坐标相近的差值小于行高的一半再按横坐标x0排序。这样基本能还原阅读顺序。如果遇到分栏排版需要先判断栏边界再分栏排序这个复杂一些但原理一样。# 按阅读顺序排序的核心逻辑 def sort_blocks(blocks): # 先按 top 粗排 blocks.sort(keylambda b: (round(b[top] / 10), b[x0])) return blocks那个round(b[top] / 10)是关键把纵坐标按 10 像素分组同一组内按横坐标排。这个 10 可以根据实际行高调行高大的文档用 15 或 20。5.2 表格转换错位怎么处理表格转换的翻车率很高典型表现是单元格内容跑到别的格子里或者合并单元格变成一堆空格。排查思路先用 pdfplumber 的extract_tables()看看识别出来的表格结构对不对。如果识别出来的行列数就和原表对不上那是表格线识别的问题调参数也没用直接退化成图片。解决方法分两种情况。规整表格有完整边框线用 pdfplumber 提取转成 PPT 原生表格不规整表格无边框、合并单元格多直接截图插入。判断标准很简单提取出来的表格如果每个单元格的文字都能对上就转原生表格如果有超过 20% 的单元格内容错位就放弃转图片。提示PPT 原生表格的编辑体验远好于图片所以能转原生就转原生。但不要为了转原生而硬转一个错位的表格比一张清晰的图片更让人抓狂。5.3 字体丢失与乱码的预防字体问题在跨平台场景下特别常见。你在一台机器上转出来的 PPT拿到另一台机器上打开发现字体全变了排版全乱了。根本原因PPT 里指定了某个字体但目标机器上没装这个字体系统就用默认字体替代字宽变了排版自然就乱了。预防措施生成 PPT 时字体尽量用通用字体比如“微软雅黑”“宋体”“Arial”这些。如果原文档用了特殊字体要么嵌入字体PPT 支持字体嵌入但会增加文件体积要么转成图片。我的做法是正文统一用微软雅黑代码用 Consolas特殊字体只在标题上用并且做好降级预案。5.4 大文件转换卡死或内存溢出处理几百页的 PDF 时很容易遇到内存爆掉或者程序卡死。排查思路看是提取阶段卡还是生成阶段卡。提取阶段卡通常是某个页面有超大图片或者复杂矢量图生成阶段卡通常是幻灯片数量太多python-pptx 在保存时内存占用高。解决方法分批次处理。提取阶段按页处理处理完一页就把数据存到临时文件不要全堆在内存里。生成阶段也是每生成 50 页就保存一次然后重新开一个 Presentation 对象继续。虽然麻烦点但能避免程序跑到一半崩掉前功尽弃。5.5 常见问题速查表问题现象可能原因排查方法解决方案文字乱序PDF 绘制顺序非阅读顺序检查提取块的坐标按坐标排序表格错位表格线识别失败对比原表行列数退化为图片字体乱码目标机器缺字体换机器打开测试用通用字体或嵌入图片模糊原图分辨率低查看提取图片尺寸优先提取原始图片流程序卡死内存溢出监控内存占用分批处理及时释放标题误判字号基准算错检查正文字号统计手动指定基准字号分页过多每页字数阈值太小统计平均页字数调大阈值到 300-400排版错乱文本框高度估算不准检查行高计算按字符数动态估算6. 进阶优化让转换效果更接近“手工制作”6.1 用模板提升视觉一致性前面生成的 PPT 都是白底黑字能用但不好看。如果你经常做这类转换建议做一个 PPT 模板把母版、配色、字体都定好生成时直接套模板。python-pptx 支持从现有 PPTX 文件加载模板prs Presentation(template.pptx) # 后续添加幻灯片时用模板里的版式 layout prs.slide_layouts[1] # 假设版式1是标题内容模板里可以预设好标题样式、正文样式、页脚、页码位置。这样生成出来的 PPT 直接就是成品不用再手动调格式。我自己的模板里定了三套版式章节页、内容页、图文页覆盖 90% 的场景。6.2 智能分页的进一步优化基础版的分页是按字数切的比较粗暴。进阶做法是结合语义分页在段落边界切不在句子中间切遇到列表项尽量把同一个列表放在同一页遇到“如下图所示”把图和说明文字放在同一页。这些逻辑实现起来不复杂就是在分页判断时多加几个条件。比如检测到当前段落以“如下”“见图”“如表”开头就标记一个“需要跟图”的标记分页时优先把后续的图片拉过来。6.3 批量处理的工程化建议如果你要处理大量文件建议把整个流程封装成命令行工具支持批量输入输出。python convert.py --input ./docs --output ./ppts --format pdf --template ./template.pptx内部用多进程处理每个文件一个进程互不干扰。日志要记清楚哪个文件成功了、哪个失败了、失败原因是什么。我一般会把失败的文件单独放到一个failed目录方便后续排查。实操心得批量处理时一定要加超时机制。有些 PDF 结构异常提取时会卡死没有超时的话整个批处理就挂在那里了。我一般设 60 秒超时超时就跳过并记录不耽误其他文件。7. 我踩过的坑与最后分享的几个技巧先说几个我实际踩过的坑都是血泪教训。第一个坑以为所有 PDF 都能提取文字。有些 PDF 是扫描件里面根本没有文字层全是图片。这种情况提取出来是空的。解决办法是先检测如果一页提取出来的文字少于 10 个字符就判定为扫描页走 OCR 流程。OCR 我用的是 Tesseract中文识别率还行但排版还原度差只能保证内容不丢。第二个坑忽略了 PPT 的文本框边距。python-pptx 添加的文本框默认有内边距大概左右各 0.1 英寸上下各 0.05 英寸。你按坐标算好的位置实际显示会偏。解决办法是把text_frame.margin_left这些属性全设为 0自己控制间距。第三个坑中文字体在 PPT 里显示为方框。这个通常是因为字体名写错了。python-pptx 设置字体时要用字体的英文名或系统识别的名称。比如“微软雅黑”要写Microsoft YaHei写中文名有时候不认。最稳的办法是在模板里预设好字体生成时继承模板样式不手动设字体。最后分享一个小技巧生成完 PPT 后用 python-pptx 再读一遍检查每页的对象数量和文字内容。如果某页对象数为 0说明这页是空的肯定是哪里出问题了如果某页文字特别多说明分页没生效。这个自检步骤能帮你快速定位大部分问题比人工一页页翻效率高得多。这套方案我用了大半年处理了上千份文档准确率大概在 85% 到 90% 之间。剩下的 10% 到 15% 主要是扫描件和极端复杂的排版这些确实需要人工介入。但相比纯手工效率提升是数量级的。如果你也在做类似的事情希望这些经验能帮你少走点弯路。
