简介：Paper2Slides 是一款面向科研人员、教师与会议汇报者的开源演示稿生成工具，旨在解决从论文、报告到幻灯片与海报之间反复排版耗时的痛点。它支持 PDF、Word、Excel、Markdown 等多种文档格式，借助 RAG 技术精准提取关键内容并建立索引，确保生成内容与原文对应，避免信息偏差。资源包共 96 个文件，以 52 个 Python 源码与 13 个 JSX 前端组件为核心，辅以 9 张预览图、6 个启动脚本及 3 份示例 PDF，压缩包约 18.89MB，前后端结构清晰，便于二次开发与本地部署。工具内置多种主题风格，支持自然语言定制样式，可输出幻灯片与海报两种形式，并具备快速生成、实时预览与断点续作能力，中途切换样式也不丢失进度。命令行一条指令即可完成转换，适合科研展示、教学演示与会议汇报场景。目前已有 146 人学习关注，读者可借此掌握从文档解析、内容索引到自动排版的完整实现思路，并直接复用其脚本与前端界面。
1. Paper2Slides 到底解决什么问题：从一份 80 页 PDF 到 20 页演示稿的自动化路径
手里拿到一份 80 页的技术白皮书或者项目验收报告，领导说下午三点要拿一份 20 页的汇报稿出来。这种场景下，手动复制粘贴、调字号、对齐图片，两个小时都不一定搞得定。Paper2Slides 这类工具瞄准的就是这个痛点：输入 PDF、Word 等格式的文档，自动提取关键内容，按预设模板排版成幻灯片或海报。它适合经常做技术汇报、课程讲义、项目总结的工程师和产品经理，也适合想把文档处理流程自动化的后端开发者。核心链路其实就三步：文档解析、内容抽取与结构化、版面渲染。听起来简单，但每一步都有不少工程细节，下面按落地顺序拆开讲。
2. 文档解析层怎么选：PDF 与 Word 的提取方案对比
2.1 PDF 解析的三条路线与适用边界
PDF 解析是整个流水线的第一道关卡，也是最容易翻车的地方。常见做法有三条路线：基于文本层的直接提取、基于版面分析的区块识别、基于 OCR 的图片文字识别。如果 PDF 是原生电子版（比如 LaTeX 导出的），文本层完整，用 pdfplumber 或 PyMuPDF 就能拿到带坐标的文本块，速度快、准确率高。但很多实际文档是扫描件或者图片型 PDF，这时候文本层是空的，必须走 OCR 路线，常见组合是 PaddleOCR 或 Tesseract 加版面分析模型。
我一般会先判断 PDF 类型再决定路线。判断方法很简单：用 PyMuPDF 读第一页，看page.get_text()返回的字符数。如果超过 50 个字符，基本可以走文本层提取；如果接近零，就切到 OCR 分支。这个判断逻辑要写进代码里，不能靠人工选。
import fitz # PyMuPDF def detect_pdf_type(pdf_path, sample_pages=3): doc = fitz.open(pdf_path) total_chars = 0 for i in range(min(sample_pages, len(doc))): page = doc[i] text = page.get_text("text") total_chars += len(text.strip()) doc.close() # 平均每页字符数低于 50，判定为图片型 PDF avg_chars = total_chars / min(sample_pages, len(doc)) return "text_based" if avg_chars > 50 else "image_based"这段代码的逻辑是抽样前几页，统计纯文本字符数。参数sample_pages控制抽样页数，默认 3 页足够判断。阈值 50 是经验值，低于这个数说明文本层基本不可用。注意不要用get_text("rawdict")来做这个判断，那个返回结构复杂，统计字符数反而容易出错。
对于文本层 PDF，提取时还要保留坐标信息，因为后续排版需要知道标题、正文、图片的相对位置。PyMuPDF 的get_text("dict")会返回每个文本块的 bbox 坐标和字体大小，这些信息是判断标题层级的关键依据。字体大于 16pt 且加粗的块，大概率是一级标题；12 到 16pt 之间的是二级标题；正文一般在 10 到 12pt。这个规则不是绝对的，但覆盖大部分技术文档。
2.2 Word 文档提取：python-docx 的段落与样式读取
Word 文档的结构化程度比 PDF 高得多，因为段落样式是显式存储的。用 python-docx 可以直接读取每个段落的 style.name，比如 "Heading 1"、"Heading 2"、"Normal"。这比从 PDF 里猜字体大小靠谱得多。
from docx import Document def extract_word_structure(docx_path): doc = Document(docx_path) sections = [] for para in doc.paragraphs: style = para.style.name if para.style else "Normal" text = para.text.strip() if not text: continue # 根据样式名映射层级 if style.startswith("Heading 1"): level = 1 elif style.startswith("Heading 2"): level = 2 elif style.startswith("Heading 3"): level = 3 else: level = 0 # 正文 sections.append({"level": level, "text": text, "style": style}) return sections这段代码遍历所有段落，按样式名映射层级。参数方面，style.name是 python-docx 直接暴露的属性，不需要额外解析 XML。注意有些文档用的是自定义样式名，比如 "标题 1" 而不是 "Heading 1"，这时候需要加一个映射表做兼容。另外表格内容不在doc.paragraphs里，需要单独遍历doc.tables，否则会漏掉表格数据。
Word 提取的坑主要在两个地方：一是公式，python-docx 读不到 OMML 公式内容，只能拿到一个空段落或者占位符；二是图片，图片位置信息需要从 XML 的 drawing 节点里解析，python-docx 没有直接 API。如果文档里公式和图片多，建议先把 Word 转成 PDF 再走 PDF 解析路线，反而更稳。
2.3 统一中间格式：把异构文档转成结构化 JSON
不管输入是 PDF 还是 Word，解析完都要转成统一的中间格式，后面排版引擎只认这个格式。我一般定义一个简单的 JSON schema：
{ "title": "文档标题", "sections": [ { "level": 1, "heading": "第一章 概述", "content": ["段落1文本", "段落2文本"], "images": [{"path": "img1.png", "caption": "图1 架构图"}], "tables": [{"headers": ["列1", "列2"], "rows": [["a", "b"]]}] } ] }这个格式的好处是扁平化，每个 section 自带层级、正文、图片和表格，排版引擎按顺序消费就行。转换时要注意：PDF 解析出来的文本块需要按坐标排序后再合并成段落，否则顺序会乱。排序规则是先按 y 坐标从上到下，y 相近的按 x 从左到右。这个排序逻辑写起来不复杂，但漏了就会导致段落顺序错乱，输出来的幻灯片读起来前言不搭后语。
3. 关键内容抽取：从全文到演示要点的筛选策略
3.1 基于规则与统计的要点打分
文档解析完，下一步是从几万字里挑出适合放幻灯片的要点。全放上去肯定不行，一页幻灯片超过 6 行字就没人看了。常见做法是给每个段落打分，按分数排序取 top N。
打分维度我一般用这几个：段落是否在标题下方前三段（权重高）、是否包含数字和百分比（权重高）、句子长度是否在 20 到 80 字之间（太短没信息量，太长不适合幻灯片）、是否包含关键词如“结论”“核心”“关键”“总结”。这些规则叠加起来，能过滤掉大部分废话段落。
import re def score_paragraph(text, position, keywords): score = 0 # 位置分：标题后前三段加分 if position <= 3: score += 3 # 数字和百分比加分 if re.search(r'\d+[%％]|\d+\.\d+', text): score += 2 # 长度分 length = len(text) if 20 <= length <= 80: score += 2 elif length > 120: score -= 1 # 关键词加分 for kw in keywords: if kw in text: score += 1 return score这段代码里position是段落在其所属章节内的序号，keywords是自定义关键词列表。参数调优时注意：位置分的权重不要太高，否则每个章节都只取开头，后面有价值的内容会被漏掉。我一般把位置分上限设在 3 分，数字和长度分各 2 分，关键词每个 1 分但总分不超过 3 分。这样一篇文档跑下来，每个章节能选出 2 到 4 个高分段。
3.2 用 TextRank 做无监督关键词提取
规则打分有个问题：换一个领域的文档，关键词列表就得重新配。这时候可以用 TextRank 做无监督提取，不需要预设词表。TextRank 的思路是把文本拆成句子，构建相似度图，然后迭代计算每个句子的重要性。Python 里可以用 jieba 的 textrank 或者自己实现一个简化版。
import jieba.analyse def extract_keywords_textrank(text, topk=10): # 使用 jieba 的 TextRank 提取关键词 keywords = jieba.analyse.textrank( text, topK=topk, withWeight=True, allowPOS=('n', 'nz', 'v', 'vn') # 只保留名词和动词 ) return keywordsallowPOS参数控制保留哪些词性，技术文档里名词和动词最有信息量，形容词和副词基本是噪音。topK设 10 到 15 比较合适，太少覆盖不全，太多会引入无关词。提取出来的关键词可以反过来给段落打分用，也可以直接作为幻灯片的标签或摘要词。
TextRank 的局限是它对长文档效果更好，短文档（少于 500 字）的图结构太稀疏，排序结果不稳定。所以我的做法是：文档超过 2000 字用 TextRank，短文档用规则打分。两者也可以结合，TextRank 出关键词，规则打分做段落筛选，互补短板。
3.3 图片与表格的取舍逻辑
技术文档里的图片和表格往往比文字更有价值，但不是什么图都适合放幻灯片。架构图、流程图、对比表格优先保留；截图、装饰性图标、大段代码截图可以过滤掉。判断逻辑可以基于图片尺寸和位置：宽度小于 200px 的图大概率是图标，直接跳过；宽度大于 400px 且位于章节开头的图，大概率是架构图，优先保留。
表格的处理更麻烦一些。Word 里的表格可以直接读行列数，PDF 里的表格需要先做表格检测。常见做法是用 camelot 或 tabula 提取 PDF 表格，但这两个库对合并单元格和无线框表格的支持都不太好。如果文档里表格不多，我一般建议手动标注几个关键表格的位置，比全自动检测省心。表格转幻灯片时，行数超过 8 行的要拆分或者只保留表头和前几行，否则一页放不下。
4. 自动排版引擎：从结构化数据到幻灯片版面
4.1 模板定义与占位符替换
排版引擎的核心是模板加数据填充。模板可以用 python-pptx 定义，也可以用 HTML 加 CSS 再转 PPT。python-pptx 的好处是直接操作 pptx 文件，兼容性好；HTML 路线的好处是排版灵活，适合做海报类输出。
我一般用 python-pptx 做幻灯片，因为它的 API 稳定，社区资料多。模板定义方式是先手动做一个 pptx 模板文件，里面放好占位符文本框，然后用代码替换占位符内容。
from pptx import Presentation from pptx.util import Inches, Pt def fill_slide(template_path, slide_data, output_path): prs = Presentation(template_path) # 假设模板第一页是标题页 slide = prs.slides[0] for shape in slide.shapes: if shape.has_text_frame: for para in shape.text_frame.paragraphs: for run in para.runs: if "{{title}}" in run.text: run.text = run.text.replace("{{title}}", slide_data["title"]) if "{{subtitle}}" in run.text: run.text = run.text.replace("{{subtitle}}", slide_data.get("subtitle", "")) prs.save(output_path)这段代码演示了最基本的占位符替换逻辑。{{title}}和{{subtitle}}是模板里预埋的标记，代码遍历所有文本框找到并替换。参数方面，template_path是模板文件路径，slide_data是上一步生成的结构化数据。注意替换时要保留原 run 的字体格式，直接改run.text不会丢失格式，但如果跨 run 替换会出问题，所以占位符要保证在同一个 run 里。
4.2 版面自适应：文本溢出与图片缩放的处理
自动排版最容易翻车的地方是文本溢出。模板里预留的文本框大小固定，但实际内容长度不可控，字多了就溢出到框外，打印出来惨不忍睹。解决办法有两个：一是动态缩小字号，二是自动截断加省略号。
我一般用动态缩字号，因为截断会丢信息。逻辑是：先按模板默认字号填充，然后检查文本框的实际高度是否超过预设高度，如果超过就逐级降字号，直到放得下或者降到最小字号（一般 14pt）。python-pptx 没有直接计算文本渲染高度的 API，需要用text_frame.fit_text()方法，它会自动调整字号适应形状大小。
def auto_fit_text(text_frame, max_font_size=28, min_font_size=14): text_frame.word_wrap = True # 先设最大字号 for para in text_frame.paragraphs: for run in para.runs: run.font.size = Pt(max_font_size) # 调用 fit_text 自动缩放到合适大小 text_frame.fit_text( font_family="Microsoft YaHei", max_size=max_font_size, min_size=min_font_size )fit_text的参数里font_family要跟模板里实际用的字体一致，否则计算出来的尺寸不准。max_size和min_size控制缩放范围。这个方法对纯文本效果好，但如果文本框里有换行符或者多个段落，fit_text 的行为会有点玄学，建议填充前先把多余空行去掉。
图片缩放相对简单：按占位框的宽高比等比缩放，保证图片不变形。如果图片原始分辨率低于占位框尺寸，不要强行放大，否则会模糊。判断逻辑是：图片宽度小于占位框宽度的一半时，居中放置不缩放；大于占位框宽度时，等比缩放到占位框宽度。
4.3 海报输出：从幻灯片到单页大图的转换
海报和幻灯片的区别在于尺寸和排版密度。海报一般是 A3 或 A2 单页，内容更密集，视觉层次更丰富。如果已经有幻灯片内容，转海报的思路是把多页幻灯片的内容合并到一页，重新排版。
常见做法是用 HTML 加 CSS 做海报模板，然后用 playwright 或 wkhtmltoimage 截图输出 PNG 或 PDF。HTML 路线的好处是 CSS 对排版的控制力强，网格布局、弹性盒子都能用，做出来的海报比 pptx 好看。
from playwright.sync_api import sync_playwright def render_poster(html_path, output_png, width=2480, height=3508): with sync_playwright() as p: browser = p.chromium.launch() page = browser.new_page(viewport={"width": width, "height": height}) page.goto(f"file://{html_path}") page.wait_for_timeout(500) # 等待字体和图片加载 page.screenshot(path=output_png, full_page=True) browser.close()这段代码用 playwright 打开本地 HTML 文件并截图。width和height设的是 A4 300dpi 的像素尺寸，A3 的话宽高各乘 1.4 左右。wait_for_timeout是给页面加载留时间，如果海报里有网络字体或远程图片，这个值要加大。注意截图前要确保所有图片加载完成，否则会出现空白区域。
5. 避坑与排查：Paper2Slides 落地时最容易踩的五个坑
5.1 中文 PDF 提取出来全是乱码
现象：用 pdfplumber 或 PyMuPDF 提取中文 PDF，返回的文本是乱码或者空白。原因：PDF 内嵌字体没有正确的 Unicode 映射表（ToUnicode CMap），导致提取工具无法把字形映射回字符。解决：换用 pdfminer.six 的PDFPageInterpreter配合PDFResourceManager，它对 CMap 的处理更完整；如果还是不行，直接走 OCR 路线，用 PaddleOCR 识别，准确率反而更高。
5.2 Word 里的公式和图表全部丢失
现象：python-docx 读出来的段落里，公式位置是空的，图表也读不到。原因：python-docx 只处理段落文本和基本样式，OMML 公式和 drawing 节点不在它的 API 覆盖范围内。解决：把 Word 先转成 PDF（用 LibreOffice 命令行soffice --headless --convert-to pdf），然后走 PDF 解析路线。公式会变成图片，虽然不能编辑，但至少能保留在幻灯片里。
5.3 幻灯片文本框溢出但 fit_text 不生效
现象：调用了fit_text，但文本还是溢出，或者字号缩到很小但没缩到位。原因：fit_text依赖字体度量信息，如果模板里用的字体在运行环境里没安装，计算出来的尺寸是错的。解决：确保运行环境安装了模板用的字体，Linux 下可以用fc-list检查；另外fit_text对多段落文本框支持不好，建议每个文本框只放一个段落，多段落拆成多个文本框。
5.4 图片提取出来分辨率太低
现象：PDF 里提取的图片放到幻灯片上模糊不清。原因：PDF 里的图片可能被压缩过，或者提取时用了默认的低质量参数。解决：PyMuPDF 提取图片时用page.get_images(full=True)拿到原始 xref，然后用doc.extract_image(xref)提取原始数据，不要用get_pixmap渲染，后者会按屏幕分辨率降采样。如果原始图片本身就低清，考虑用 Real-ESRGAN 做超分，但这是最后手段。
5.5 排版后的幻灯片在 WPS 里打开错位
现象：用 python-pptx 生成的 pptx 在 PowerPoint 里正常，在 WPS 里打开文字和图片位置偏移。原因：WPS 对某些 XML 属性的解析和 PowerPoint 不一致，尤其是文本框的auto_size和word_wrap属性。解决：生成时显式设置text_frame.auto_size = None和text_frame.word_wrap = True，避免依赖默认值。另外图片位置用 EMU 单位精确指定，不要用相对定位。
6. 进阶技巧：用模板继承和批量处理把效率拉满
模板继承的思路是做一个基础模板，定义好母版、配色、字体，然后针对不同场景（技术汇报、产品介绍、课程讲义）做子模板，只覆盖版面布局。python-pptx 支持从现有 pptx 复制 slide layout，但 API 比较绕。我一般直接操作 XML：用copy.deepcopy复制 layout 的 XML 节点，然后替换占位符。这样一套基础模板可以派生十几个子模板，维护成本低很多。
批量处理是另一个提效点。如果手头有几十份文档要转幻灯片，逐份跑太慢。做法是用 concurrent.futures 做并行，每个文档一个进程，互不干扰。注意 PDF 解析和 OCR 是 CPU 密集型，并行数不要超过 CPU 核心数；排版和保存是 IO 密集型，可以适当多开。
from concurrent.futures import ProcessPoolExecutor import os def batch_convert(doc_paths, output_dir, max_workers=4): os.makedirs(output_dir, exist_ok=True) with ProcessPoolExecutor(max_workers=max_workers) as executor: futures = [] for path in doc_paths: output = os.path.join(output_dir, os.path.basename(path) + ".pptx") futures.append(executor.submit(convert_single, path, output)) for f in futures: try: f.result() except Exception as e: print(f"转换失败: {e}")max_workers设成 CPU 核心数比较稳妥，设太大反而会因为内存争抢变慢。convert_single是单文档转换函数，内部按前面的流程走。异常处理要加，否则一个文档失败会拖垮整个批次。
验证输出质量有个小技巧：生成完 pptx 后，用 python-pptx 反向读一遍，检查每页的文本框数量和文字长度，如果某页文字超过 200 字或者文本框超过 8 个，大概率排版有问题，需要人工复查。这个检查可以写成自动化脚本，跑在批量转换之后。
我自己做这类工具最大的教训是：不要追求一步到位的全自动。文档格式千奇百怪，全自动跑十份能有三份需要手动修。更务实的做法是自动生成初稿，然后留一个快速编辑的入口，人工花五分钟调整比调三天代码划算。希望帮到你。
本文还有配套的精品资源，点击获取
