补充一下，这里是我用来测试的文档。
wangdoc/es6-tutorial: 一本开源的 JavaScript 语言教程，全面介绍 ECMAScript 6 新引入的语法特性。

另外，想请教一下，目前 PDF 打印功能是如何实现的？是 Electron 提供的 API 还是像 docx 一样调用 pandoc 呢？我能不能自己写命令行参数来实现批量导出，并在导出时使用思源中的主题呢？

第一点

可以理解，有 issue 提到，有一个自动标题自动降级的逻辑。

但只是在 PDF 以目录的形式呈现的话，并不需要搞自动降级这么复杂。
PDF 中的目录只以缩进来表示 Level，完全不受笔记标题 H1~H6 的限制。

举例来说，存在如下文档结构：

• 阮一峰 TypeScript → 点击这里导出 PDF
  • 第一章.md → 这是一篇笔记
    • H1 概述 → 这是笔记中的 H1
      • H2 历史
    • H1 理论
  • 第二章.md → 这是另一篇笔记
    • H1 语法
      • H2 变量
      • H2 常量

那么，导出为 PDF 时，保留同样的目录结构就可以了

• 阮一峰 TypeScrip
  • 第一章
    • 概述
      • 历史
    • 理论
  • 第二章
    • 语法
      • 变量
      • 常量

实际上，手动导出单篇笔记，再合并的逻辑也是如此。

确实有的人喜欢在笔记中写一个 H1 作为标题，但是用思源写笔记的话，这种作法应该相对较少。
而且只要保证目录结构不错乱，有些目录的小细节修改起来也比较容易。

第二点

所以我在下面回帖补充了关于这个功能的设想：在思源笔记内部模拟用户单篇笔记导出 PDF 再合并的逻辑，然后再修改 PDF 目录
导出时每次就导出固定页面数的 PDF，比如 100 页；

可能会慢一点，也可能需要阻塞用户操作。
但是只要以适当的方式显示导出进度给用户应该还算可以接受。

当然，可以预见到，这是个大工程。

第三点

我以默认主题 daylight 导出，并以两种代码块配色，都可以复现。

据观察，在打印窗口中，代码块一开始是不渲染的，是在几乎导出完成时才以黑白的方式渲染。
不知这个信息是否有用。

我导出 PDF 的环境是：

• Win10x64
• 思源 v3.0.14
• 官方内置主题 daylight
• 代码块主题：
  • base16/papercolor-light
  • default

补充：目前导出用的 AHK 脚本

#Requires AutoHotkey v2.0
#SingleInstance Force
CoordMode 'Mouse', 'Screen'

itemH := 28 + 1 ;上下maring各1，margin塌陷=1
loops := 32 ; 笔记个数
looplast := loops ; 剩余笔记个数
offitem := 0
offH := 0
newY := 0

/*
一次点击的示例：
右键：433，95
导出：599，506 → +166，+411
PDF：779，632 → +180，+126
*/

F9:: {
    global
    MouseGetPos &itemX, &itemY
    loop loops {
        looplast -= 1
        offH := itemH * offitem
        newY := itemY + offH

        Click itemX, newY ; 点击条目
        Sleep 1000
        MouseMove 580, 220 ; 点击文件中空白处
        Sleep 2000
        Send '{Alt Down}'
        Sleep 300
        Send '{F8}'
        Sleep 300
        Send '{Alt Up}'

        Sleep 4000
        Click itemX, newY ; 点击条目
        Sleep 1000
        Click itemX, newY, 'Right' ; 右键条目
        Sleep 1000
        MouseMove itemX + 166, newY + 411 ; 移动到导出 ;
        Sleep 1000
        Click ; 点击导出
        Sleep 1000
        MouseMove itemX + 166 + 180, newY + 412 + 126 ; 移动到PDF ;
        Sleep 1000

        ; send "{Esc}" ; 与clickPDF两者存一，send Esc为测试状态

        Click ; 点击PDF

        Sleep 4000
        MouseMove 3094, 1264 ; 点击打印的确定
        Sleep 1000
        Click ; 点击确定
        Sleep 3000
        MouseMove 2385, 885 ; 移动选择文件夹
        Sleep 3000
        Click ; 点击选择文件夹
        Sleep 5000


        offitem += 1

        ; 每搞7个向下滚2下
        if offitem == 7 {
            Click "325 90 wheeldown 2"
            Sleep 100 ; 滚动间隔时间，单位为毫秒，可以根据需要调整

            ; 滚两下的精确距离是200，因此需要手动补偿3
            ; itemH的精确高度是29，29*7=203
            ; 重置itemY并修正偏移
            itemY := itemY + 3

            offitem := 0
        }
    }
}

F10:: {
    global
    ; 重置脚本
    offitem := 0
    offH := 0
    newY := 0
    loops := looplast
    MsgBox "脚本已停止运行。"
    ExitApp ; 停止脚本运行
}


F12:: {
    ; 用于测试
    CoordMode 'Mouse', 'Screen'
    Click "325 90 wheeldown 2" ; 滚两下正好是200px
    Sleep 100 ; 滚动间隔时间，单位为毫秒，可以根据需要调整
}

我还观察到，有时候单篇大笔记导出 PDF 的时候，有时候也会有目录缺失的现象。
这个时候只需要手动点一下优化排版，就恢复正常了。

不知道导出多层笔记是不是会面临内存问题。
我觉得宁可导出速度慢一点，也要功能完整。
最好是能有个导出进度条，或者预估时间之类的东西，要不然不知道是导出失败了还是单纯的导出慢。

如果受打印 PDF 的 API 限制，能否在思源内部模拟手动导出单篇笔记的脚本，最后再合并到一起呢？
体验上类似手机上的长截图的感觉，即用户可以看到每篇笔记的操作流程，但阻塞除暂停和退出外的一切用户操作。

目前为止唯一提供了有用信息的回复。谢谢你。

如果我没记错的话，之前 D 的签名是“基础不牢地动山摇”。

那“复制粘贴”的体验，应该算是一个文本编辑器的基础了吧。

Block 才是那个锦上添花的东西。

现在“复制粘贴”的体验有点奇怪，期待改进优化。

我不认同你对于第 4 条的观点。

以 block 作为笔记内容的“检索”和“引用”的基本单位，的确是思源的特色，请保持。
但是我的建议是，复制时应以字符作为基本的“选中单位”，实现“准确”的复制。
这是两回事。

也就是我选中了多少，就可以复制多少；
而不是我选中了多少，自动扩展到最后一行所在的整个 block。
尤其是这个 block 非常大的时候，体验非常割裂，非常反直觉。

以下图为例：

当我只想复制到 777 一行时，实际复制结果是一直复制到 999 一行。
即第 777 一行的父级 444 行及其所有子级内容都被复制了。
这还只是一个随手写下的简单例子。
如果是一个非常大的 List 呢？
比如一个大纲笔记《幕布》迁移过来的新用户呢？
很可能笔记通篇就是用 List 来组织的。
那得多复制多少内容？

而且，这是存在于引用、代码、段落等所有块级结构中的通病！
而且，这个通病发生在用户最常用的功能上！
尤其是对于有大量复制粘贴需求的新用户，5 分钟之内就能发现，开幕雷击属于是。

对于任何文本编辑器的用户来说，选中多少复制多少，都是第一直觉。
如果内容不太多，即使多复制了额外内容，也可以当场检查出问题；
但是如果内容多到来不及检查呢？那给用户的感觉就是，你这个软件多少带点雷。

如果说其它几条建议是关于《跨页复制》，那第 4 条则是强调《跨块复制》的功能异常。
两者有所联系，但并不完全相同。

当然，页面加载不全导致的复制不全，也好不到哪儿去。
作为一个文本编辑软件，居然连 Ctrl+A，接 Ctrl+C，接 Ctrl+V 这一套连招都会失效，确实是有点惊世骇俗了。
至少，同生态位的 Obsidian 没有以上这 5 个问题。

如果是技术上有难度，大可慢慢想办法。
但是当作 Feature 的话，那就实在太奇怪了。

其实还有一种实现方式，就是当直接粘贴 URL 的时候，思源在后台去访问这个 URL，获取页面的 title 标签当作链接的文本，然后给用户一个提示是要直接粘贴 URL 还是当作链接插入笔记中。

不过这种做法可能需要用户授权。

果然有人提出这样的问题

添加链接时，由其他应用返回思源会失去焦点 - 链滴
添加链接时，由其他应用返回思源会失去焦点

默认在列表中折叠这部分就可以了啊。

• 没有开关
• 引用数对得上
• 低权重内容不占用用户心智
• 提供低权重内容的用户可达性，而不是直接删除

啊这…

这不巧了么…

Typora 里图片的缩放就是通过 <img> 标签实现的啊…

Typora 的用户基数还是挺大的，如果不能在导入的时候完美兼容，感觉很亏啊 D 大！！！