编译前写一个预处理脚本，提取其中的image url，自动下载图片到本地并替换路径。
bookdownplus::include_image() 干的就是这个。除此之外，如果图片是 gif 动图，它会自动截取第一帧，另存为 png，再插入 pdf。
之前没有遇到过混杂 html 的情况。当时大家都是以 markdown 格式投稿的。
大不了把 html 预处理一下，用 pandoc 转成 markdown 再合并进书稿。
You are viewing a single comment's thread from:
好的，谢谢大鹏提供的信息 :)
代码commit以后，确实有一些工作是可以自动化的，至少保证最后输出结果无误是不困难的。
不过这里其实主要是人的问题：
由于我们现在的合作模型是作者写作+编辑提交代码，问题主要在源码阶段的作者的自由度和编辑的工作量之间的权衡。
我考虑了一下，可能还是在编辑这里加一道工序，将html格式通过在线工具（如这个，或者有其他更简易的方式）转换成markdown以后再提交。如此，作者自由，编辑的成本增加的也较少。
html 转 markdown 用 pandoc。说不定 travis-CI 可以自动完成。
wordpress 有 markdown 插件，可以在 wordpress 上用 markdown 写，虽然用 steempress 发布后会转成 html，但是 wordpress 的markdown 源文本可以提交到 github。
不过这依然是作者自由度的问题。作者书写方式越规范，编辑和后期维护越容易。越放飞自我，越麻烦。
嗯嗯，
所以原则上，还是让机器能做的事情让机器做吧，只不过在编辑、合并、编译每个阶段可能要用到一些不同的工具。。。解放作者和编辑之间，根据具体情况再做一些协调吧~
大鹏，顺便请教一下，之前文档里的标题是不是最多支持到第三级？如果使用第四级标题是会在目录里增加新的一级吗？
标题3
标题4
意思是指在这个编辑的工作流中加一步，在GitHub的编辑器编辑之前，先将html转换为markdown
想得比较多、比较细，主要还是目前假设的编辑的技术基础比较薄弱一点。。。
当然，如果有 html --> rmarkdown 的converter的话会更好一些，之前书本编译的很多问题就是由于文档中的rmarkdown语法错误引起的。:P