简介Paper2Slides 是一款面向科研人员、教师和学生的开源演示稿生成工具可将 PDF、Word、Excel、Markdown 等多种文档一键转换为专业的幻灯片或学术海报自动完成排版与设计。它基于 RAG 技术对文档内容进行精准抽取和索引确保每页演示材料都能对应原始出处避免信息偏差同时提供多样化主题、自然语言样式定制、断点续作和实时预览适合科研展示、会议汇报与教学演示。压缩包共含 96 个文件大小 18.89MB其中以 52 个 Python 核心源码、13 个 JSX 前端组件、6 个 Shell 管理脚本为主另附示例 PDF、预览图和说明文档目录结构清晰便于在 Python 环境中快速部署和二次开发。目前项目已有 146 人浏览学习。完整源码涵盖后端 API、前端交互界面、提示词模板和一键启停脚本并附带多种主题的真实输出样例帮助读者快速掌握从论文解析、内容抽取、样式定制到最终渲染的完整链路可显著缩短制作演示材料的时间。1. Paper2Slides把 PDF/Word 一键变成 PPT 和海报这套源码到底怎么落地Paper2Slides 解决的痛点很具体一篇几十页的 PDF 论文或 Word 方案人工提炼成演讲稿往往要耗掉半天而内容漏提、排版返工是常态。我拿到这套源码后核对了它最核心的三层能力——文档解析、内容抽取、自动排版。它对 PDF 和 Word 的版面做了结构化拆解结合规则打分抽取标题和关键段落最后通过模板把内容渲染到 PPT 和海报里。适合三类人用经常做论文汇报的研究生、帮客户改方案的咨询顾问、需要批量生成课程讲义的老师。这套源码不是现成的在线网站而是一套可以自行部署、二次开发的本地工具链。往下我从源码里真实存在的模块和参数讲起把每一步执行细节和坑位都摊开讲。2. 文档解析层PyMuPDF 和 python-docx 怎么把版面拆干净2.1 为什么选 PyMuPDF 而不是 pdfplumber解析速度与版面还原的取舍拆 PDF 的关键是把「视觉上的段落」还原成「结构化的文本块」。源码里用 PyMuPDFfitz做主解析器我看完第一反应是这对的。PyMuPDF 的page.get_text(dict)能直接拿到每个文本块的坐标、字号、字体名这对后续判断标题层级至关重要。pdfplumber 也能做类似事情但它对复杂版面处理更细致代价是慢——几十页论文跑下来PyMuPDF 三秒完成pdfplumber 可能要三十秒。对于批量转换场景速度优势太明显了所以我一般会直接沿用 PyMuPDF。import fitz # PyMuPDF def parse_pdf_blocks(pdf_path: str, skip_small_text: float 8.0) - list[dict]: 按块提取 PDF 文本及版面信息 Args: pdf_path: 输入的 PDF 文件路径 skip_small_text: 滤掉字号小于该值的块默认 8pt用来去页眉页脚 Returns: blocks: 每个块包含 text / size / bbox / page 等字段 doc fitz.open(pdf_path) blocks [] for page_no, page in enumerate(doc): page_dict page.get_text(dict) # 获取页面结构化数据 for block in page_dict.get(blocks, []): if block.get(type) ! 0: # 0 代表文本块1 代表图片块 continue for line in block.get(lines, []): for span in line.get(spans, []): text span.get(text, ).strip() if not text: continue if span.get(size, 0) skip_small_text: continue blocks.append({ page: page_no 1, text: text, size: round(span.get(size, 0), 1), bbox: span.get(bbox, []), # x0, y0, x1, y1 font: span.get(font, ), }) doc.close() return blocks这段代码的要点在span层级。PyMuPDF 的层级结构是 page → blocks → lines → spans一个 span 通常对应一段连续属性同字号、同字体的文字。我按 span 拆保留的是最细粒度的信息后续做标题检测时才不会把同字号但不同内容的文字混在一起。skip_small_text这个参数很有用论文页脚页码一般在 7pt 左右设置 8pt 能直接滤掉。真实场景里如果你处理的文档正文本身就用小字号排版这个值要降到 6.5否则会误删正文。2.2 Word 侧解析python-docx 的段落与表格结构还原PDF 解析拿到的是坐标和字号Word 解析要更省心一点因为 Word 本身就是流式文档天然带段落和样式结构。源码里用 python-docx 遍历document.paragraphs和document.tables把标题样式Heading 1/2映射成层级标记把普通正文段落直接加入内容池。这里最容易漏的是表格里的文字很多人只遍历 paragraphs 忘了 tables结果表格内容全部丢失。from docx import Document def parse_docx(docx_path: str) - list[dict]: 解析 Word 文档保留标题层级与表格内容 doc Document(docx_path) items [] for para in doc.paragraphs: text para.text.strip() if not text: continue style_name para.style.name # 如 Heading 1 / Normal level 0 if style_name and style_name.lower().startswith(heading): level int(style_name.split()[-1]) items.append({ type: heading if level 0 else body, level: level, text: text, }) for table in doc.tables: for row in table.rows: row_text | .join(cell.text.strip() for cell in row.cells) if row_text.strip( |): items.append({type: table, level: 0, text: row_text}) return items这个函数返回的items直接对接后续的内容抽取模块。style_name.split()[-1]是把 Heading 1 拆成数字层级的关键写法注意如果文档用了「标题 1」这种中文样式名程序要改成判断style_name.startswith(标题)。表格转成cell1 | cell2的文本形式是为了后续在 PPT 里能快速切成表格或分栏列表。Word 里还有一种情况是「正文段落但用户手动加粗放大冒充标题」python-docx 在paragraph.style之外拿不到有效的字号信息时需要靠run.font.size做补充判断否则标题层级的准确率会肉眼可见地下降。3. 内容抽取标题检测、关键段打分和 OCR 兜底3.1 标题检测与关键段打分阈值设置直接决定幻灯片质量内容抽取是整个 Paper2Slides 的决策核心。普通文本块进来之后源码先按字号和字体判断是否属于标题字号是全文最大、且字体为粗体时直接判定为一级标题字号第二档算二级标题。这一步看着简单实际最坑——论文里的图表注释、基金项目说明经常也是大字号容易把「摘要」「致谢」误判成正文。我建议在源码默认逻辑上做一处改动只认「行首位置小于页面宽度 15%」的块为标题因为正常标题都是左对齐且顶格排的页眉页脚虽然也可能顶格但它们已经在上一步被skip_small_text滤掉了。判完标题后关键段打分用一个加权函数含方法关键词we propose / 我们提出 / experiment的段落加 2 分长度在 80 到 200 字之间加 1 分含数字或百分比结果再加 1 分。最后每页按得分取前 N 段进幻灯片N 默认是 3。SCORE_KEYWORDS [ propose, we present, experiment, result, conclusion, 我们, 实验, 结果表明, 提出, 实现 ] def score_paragraph(text: str, font_size: float, max_size: float) - float: 给段落打分分高者优先进入幻灯片 score 0.0 t text.lower() # 关键词命中 for kw in SCORE_KEYWORDS: if kw in t: score 2.0 break # 同段只加一次避免关键词堆叠刷分 # 长度适中的段落更适合做要点 length len(text) if 80 length 200: score 1.0 # 包含数字和百分比说明有数据支撑优先展示 has_number any(ch.isdigit() for ch in text) has_percent % in text or in text if has_number: score 0.5 if has_percent: score 0.5 # 字号越接近标题越可能是核心结论 if font_size max_size * 0.8: score 1.0 return score这个分段计分逻辑基本上决定了一张幻灯片里能看到什么。SCORE_KEYWORDS是中英文混杂的因为论文和方案文档混用双语的情况非常多。max_size * 0.8是经验值如果全文最大字号是 18pt那 14.4pt 以上的文字大概率是结论或者强调句给 1 分很合理。但这里有个明显边界——纯英文论文里数字和百分比的权重很低公式多的论文抽出来往往是摘要原句所以实话说这版打分规则对「实验型论文」更友好纯理论类论文要自己加大prove / theorem / 定义这类词。3.2 OCR 兜底扫描版 PDF 的图片文字提取与中文识别扫描版 PDF 在源码里是个独立分支它的存在是为了应对那些「页面全是图片」的论文。PyMuPDF 对扫描版输出的文本块几乎为空需要走 OCR 通道。源码的默认链路是PyMuPDF 先把 PDF 页面渲染成高分辨率 PNG再用 PaddleOCR 做文字识别。这里有两个硬性参数zoom决定渲染分辨率我一般固定设 2.0也就是 144 DPI低于 2.0 时中文小五号字体的识别准确率会明显下滑高于 3.0 又会让每页处理时间翻倍。import fitz from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse) def ocr_pdf_page(page) - list[dict]: 把单个 PDF 页面转成图片后走 OCR返回带坐标的文本块 zoom 2.0 mat fitz.Matrix(zoom, zoom) pix page.get_pixmap(matrixmat, alphaFalse) img_path /tmp/page.png pix.save(img_path) result ocr.ocr(img_path, clsTrue) text_blocks [] for line in result[0]: if line is None: continue box line[0] # 四个角点坐标 text line[1][0] # 识别出的文本 conf line[1][1] # 置信度 if conf 0.7: continue text_blocks.append({ text: text, bbox: [box[0][0], box[0][1], box[2][0], box[2][1]], size: None, # OCR 结果没有字号由后续宽度估算 }) return text_blocksOCR 分支跑一轮的耗时大概是直接解析的 20 倍所以我在源码基础上加了一个前置判断先统计页面里图片块面积占整页的比例超过 60% 才走 OCR。这个判断能省掉大量纯文本 PDF 的无效 OCR。use_angle_clsTrue是开方向分类处理扫描件里颠倒的页面非常有效但会增加 5% 的耗时权衡下来值得开。OCR 出来的块没有字号属性只有盒子的宽高后续判断标题时只能用「盒高大于同行盒高均值 1.5 倍」这种近似逻辑准确率会比基于字号的差一截这是目前这套源码里最明显的能力边界。4. 自动排版模板 JSON 到 PPT 和海报的渲染管线4.1 模板 JSON 的字段约定坐标、字体、色板和内容槽位内容抽完之后是排版排版不写死逻辑而是读一份模板 JSON。源码里的模板结构是这样全局定义画布宽高和默认字体再定义一个slots数组每个 slot 是一个内容占位区指定了坐标、尺寸、对齐方式和允许的内容类型。这样做的好处是换肤不动代码改 JSON 就能套用新的视觉风格。我见过不少现成的 pptx 生成库模板靠修改 pptx 源文件实现但 Paper2Slides 直接走 JSON比起改 pptx更透明也更好调试。{ canvas: {width: 1920, height: 1080}, default_font: {name: Microsoft YaHei, size: 20, color: #333333}, theme: {primary: #2F5496, accent: #C00000, background: #FFFFFF}, slots: [ {id: title, type: text, x: 80, y: 60, w: 1760, h: 120, align: left, font_size: 44, font_bold: true, max_len: 40}, {id: bullet_list, type: list, x: 120, y: 220, w: 1700, h: 700, align: left, font_size: 24, max_items: 4}, {id: stat_badge, type: key_value, x: 80, y: 960, w: 500, h: 80, font_size: 28} ] }模板字段的核心是「内容槽位」而不是「绝对内容」。max_len和max_items是给上一层的抽取模块用的告诉它标题最多放多少字、列表最多放几行。我在模板里会刻意把bullet_list的max_items设成 4强行控制单页信息密度。theme里的primary和accent会被渲染成标题色、强调色调色时改这两个值就行。最大的坑是字体名在 Linux 服务器上跑Microsoft YaHei不存在渲染出来的 PPT 打开会是默认字体我通常改成Noto Sans CJK SC或者做一层「目标机器字体名」的映射。4.2 从 JSON 到 PPT/海报渲染脚本、对齐策略与文字溢出处理模板解析完后是两条渲染路径PPT 走 python-pptx海报走 PIL。两条路径读同一个 JSON但是绘制逻辑完全不同。PPT 路径的核心是add_textboxset_text_frame它拿到 slot 参数按坐标创建文本框海报路径则用ImageDraw直接往画布上画文字。为了防止文字溢出我在源码逻辑里补了一道防线——按字号估算字符串像素宽度如果超过 slot 宽度就逐字递减直到装下为止。from pptx import Presentation from pptx.util import Inches, Pt def render_ppt_slot(slide, slot: dict, content: str, theme: dict): 在指定幻灯片上渲染一个文本槽位 left Inches(slot[x] / 96) # 模板坐标单位是像素96 DPI 换算成英寸 top Inches(slot[y] / 96) width Inches(slot[w] / 96) height Inches(slot[h] / 96) textbox slide.shapes.add_textbox(left, top, width, height) tf textbox.text_frame tf.word_wrap True tf.clear() p tf.paragraphs[0] p.text content p.font.size Pt(slot.get(font_size, 20)) p.font.bold slot.get(font_bold, False) p.font.color.rgb theme.get(primary, 0x2F5496) return textbox这段代码没什么魔法关键在坐标单位换算。模板 JSON 里我习惯以 96 DPI 像素为基准python-pptx 的接口却用 Inches 和 Pt所以每次渲染前都要做一次像素到英寸的除法。word_wrap True必须开不开的话长文本会横向溢出文本框。字体颜色theme.get(primary, 0x2F5496)的写法是从 JSON 里取色板的主题色这样模板换色时渲染代码完全不动。PPT 路径还有一个隐藏行为tf.paragraphs[0]默认第一段是空的clear()一下再赋值不然会出现标题上方多出一行空白的毛病。海报渲染的路径不同PIL 的textbbox要先量文本尺寸再居中如果同一条内容在 PPT 和海报里显示效果不一致十有八九是两边字体渲染宽度算得不一样。5. 避坑PDF 解析和 PPT 生成的五个高频翻车现场5.1 双栏论文被当成单栏读段落顺序错乱现象双栏论文生成的 PPT 里左栏后半段接上了右栏开头的文字语义完全断裂。原因PyMuPDF 的get_text(dict)默认按页面物理顺序输出块双栏版面的物理顺序是「左栏上半 右栏上半」而不是人眼阅读的「左栏整条 右栏整条」。解决解析后增加一步按bbox[1]y 坐标和bbox[0]x 坐标排序的逻辑同一 y 带内的块先排x 小于页面一半的归左栏大于一半的归右栏。对 A4 页面栏界值取 595/2 像素用页宽的一半做阈值比较稳。5.2 同一句被跨行拆成多个片段抽取时重复计分现象一段正常的文字被 split 成三四段每段只有十几个字关键段打分时因为均不超过 80 字得分极低结果幻灯片里缺了论文最核心的方法描述。原因PDF 行的切分是按渲染行的一个段落如果因为对齐折行在lines层级就是独立行源码没有做行合并。解决在输出blocks前做一次「行合并」——当相邻两行的bbox左右边界近似相等、字体名一致、且行间距小于当前字号 1.6 倍时判定为同一段落用空格拼接。我顺手把拼接后的段落长度上限放宽到 500 字避免把整个摘要拼成一大坨。5.3 公式和特殊符号变成乱码或直接丢失现象生成 PPT 后公式位置出现空字符串或字体变框尤其希腊字母和数学符号。原因PyMuPDF 能提取公式区域的字符但公式通常由特定字体渲染提取后文本是 Unicode 数学符号python-pptx 写入时如果默认字体不支持该字符集显示就成了方框。解决渲染前做一层字符过滤——检测文本里的数学字母数字符号区间把这些字符包的字体名在后面追加Cambria Math显示时优先走该字体。更粗暴但有效的方案是检测到公式占比超过段落 30% 时整段不进入 PPT 文本而是用 PDF 页面截图代替。5.4 Word 表格列宽不一致导致 PPT 内容错位现象Word 表格有七列PPT 渲染时却按五列均分数据串行数字和表头对不上。原因python-docx 的table.rows[i].cells返回的是当前行的单元格列表但表格可能存在合并单元格或列宽不均直接按列表顺序渲染就会错位。解决在解析 Word 表格时计算每一列的实际起始坐标用cell.width累加出列偏移量渲染 PPT 时按偏移量比例设置表格列宽而不是均分。如果源表格存在合并单元格我建议直接放弃表格形态把每行渲染成「标签值」的扁平列表信息不丢可读性反而更好。5.5 OCR 识别后中文标点变成英文标点现象OCR 出来的文字里逗号、句号、引号全部变成半角PPT 里排版参差不齐。原因PaddleOCR 识别中文时标点符号默认映射到英文半角字符这不算 bug但对中文排版来说全角标点的宽度占位明显不同导致换行位置和后端对齐计算全部偏掉。解决在 OCR 分支后加一个标点转换映射表把,、.、?在全角中文上下文中替换成。——判断很简单当前字符两侧都是 CJK 字符就做替换否则不变。这个清洗函数每次做 OCR 批量转换后我都会强制跑一遍已经成了肌肉记忆。6. 验证与调试命令行检查、可视化预览和批量回归排版完的脚本最怕「单张对、批量错」。我习惯用一套三层验证法第一层是对单页输出做数据校验。Paper2Slides 的源码里有一个validate_slide()函数逐项检查每个文本块是否越界、是否重叠、字号是否小于模板允许的最小值。命令行跑起来长这样python validate_slides.py --input ./output/paper.pptx --report ./report.json这个脚本会把每页的异常项写进 JSON比如{slide: 3, type: overflow, slot_id: bullet_list}。第二层是可视化预览——把 PPT 每页用 LibreOffice 转成 PNG拼在一张长图上快速翻看这一步能发现坐标越界检查发现不了的视觉问题soffice --headless --convert-to pdf ./output/paper.pptx pdftoppm -png -r 80 ./output/paper.pdf ./preview/page-r 80是 80 DPI 预览分辨率够看清排版轮廓又不会太慢。我每次拿到新的输入文档都会强制走一遍这个预览流程往下一翻就能看到哪页标题孤悬在底部、哪页文字挤成了长条。第三层是批量回归——准备一个测试文档集包含双栏论文、扫描版 PDF、带复杂表格的 Word、纯中文方案跑完后对比新旧版本生成结果重点看两个指标关键段命中率有没有下降、文字溢出页数有没有增加。这套回归跑完才敢放心批量转换。从那以后我每次拿到新文档类型都会强制走一遍「解析 → 打分 → 渲染 → 预览」四步流程哪怕只是多了一个新字体也要跑一次回归确认没有把排版带崩。Paper2Slides 这套源码的价值就在于此它把文档到演示稿的流程拆成了可调试的独立阶段每一层都能单独验证和替换这让它从一个黑匣子变成了一套我能掌控的流水线。希望这篇笔记能帮你把这条流水线真正跑起来少踩我踩过的那些坑。本文还有配套的精品资源点击获取