修复：文档集成时首篇标题没有被正确解析，未提取为一级目录的 bug 。

完善：目录提取与生成时包含一级标题。单独生成文档目录时，目录中不含本文标题（默认为本文档第一行的一级标题）。但是，整个项目或某个目录下的文档集中输出为一个大的 html 时（文档集成），则自动提取每个文档的标题作为一级目录，每个文档中的二级和三级标题自动提取为二级和三级目录。此时，该文档原有的目录将不再单独提取并生成。

@TheKiteRunner 谢谢您：）

新增：非标准 Markdown 语法标记：“[TOC]”（目录）。可手工输入该标记，也可编辑器右键菜单插入。注：仅提取当前文档中的二级和三级标题。

一并更新了默认的样式表。

- 更新：软件自带模板的样式表。如打算用之，请先导出或备份您当前所修改并使用的样式表，而后点击系统菜单中的“ Reset/Repair Default Templates （重置 /修复系统模板）”。
- 本次更新的样式表，主要是对页面正文区的文字链接添加下虚线，使之醒目，起到引导用户去点击的作用。该样式对使用 WDTP 建站或建博客的用户可能有用。

• 智能包裹标记添加两个快捷键： Ctrl + 8 （等同于 Shift + 8 ）， Ctrl + `（等同于 Shift + `）。这个快捷键用于解决编辑器处于非“自然状态”下的键盘快捷键输入不被识别与认可的问题（比如处于中文输入状态时）
◦ 注： cmd + `在 macOS 安装了某些特定中文输入法的前提下不可用

• 修复： Markdown 行内代码解析与`转义方面的一个 bug

@TheKiteRunner 先生，网页渲染结果，也就是格式和样式，是通过 css 和模板来完成的，这个和程序本身没有关系。 css 中的 text indent 属性，很难兼顾中英混排或纯中 /纯英这种网页格式的文档需求。我对前端技术不是非常了解，但一个传统的解决思路是判断字符集属性，而后调用不同的 css 。您可以根据自己的需要来改。

网页前端这一块，我的想法是和目前流行的其他控制台静态生成器程序保持一致，交给用户和贡献者来负责。我个人非常希望能有更多的网页设计师、前端工程师和行业高手参与进来。按照 html 5 标准中新增的东西，包括这个标准以后肯定会不断丰富的拓展与规范，加上 js 和 css ，前端这一块可以实现很惊人的功能和效果，甚至完全可以写一个功能更强大的网页版 WDTP ，或其他各种类型的 app ，帮助人们更好的工作、学习、生活、娱乐。

说实话，这一块也确实不是程序母体维护者能做到的。太多专业领域，太多专业需求了，没办法兼顾。很多领域的专业常识我也不具备，没办法把握客户的真正所需。

WDTP 的模板制作和应用非常简单，这个模块是完全开放的。模板中可调用的标签，可在开发文档中找到。这个肯定不够，如有需要，请告诉我，我觉得可行或想法不错，就一定及时定义新的 Tag ，写出这部分代码，而后加到开发文档中供更多人使用。

开发文档：
https://github.com/LegendRhine/WDTP/blob/master/Source/memo.md

WDTP 开发的初衷有四大核心需求。基本功能和架构完善后，我想拿第一大块开刀：面向职业文艺家、小说家、剧作家和技术类作家的新一代创作利器。这个我本人也有强烈需求，平时也要用到。希望一切顺利：）

发布： 0.9.170211 Windows 32 位版本

使用 32 位 Windows 操作系统的用户请确保本机已安装了 IE 11 浏览器和微软雅黑字体。

发布： WDTP 0.9.170211 （内测版）

主要更新记录: http://underwaysoft.com/works/wdtp/updateList.html
下载页: http://underwaysoft.com/works/wdtp/download.html

@TheKiteRunner 先生，长链接碍眼的问题解决了：）可能思路和模式还不够理想，有点笨拙。欢迎提出宝贵意见和建议：）

实现：缩略语功能。详解如下：

编辑文档时，部分内容可能太“碍眼”，不想时时看到；或者无需经常改动（防止误编辑）；或者由于非阅读性字符太多、太难看而破坏编辑时版面的美感（比如包含非标字符的 UTF-8 转义或复杂参数的较长网址、代码等等），此时可用一个自定义的短语来代替这部分内容。

文档属性面板，“ Abbrev （缩略语）”专司其职。格式为：“缩略语（空格）所代表的原始内容”。一行一个，行与行之间可使用空行隔开，以便区别。
设置好缩略语之后，编辑模式下，可将要缩略显示的内容删掉，代之以刚刚自定义的缩略语。

原始内容虽然在编辑模式下看不到了（看到的是缩略语），但预览时会出现。即：原始的文档中虽然已经找不到这些内容，但预览并生成网页时，这些内容还是会出现（此时网页中不出现这些内容的缩略语）。

也可以用这个思路理解：编辑模式下，缩略语用来替代它所代表的原始内容；而预览并生成的网页中，原始内容反过来再替代它所对应的缩略语。
可在文档属性面板的“ Abbrev （缩略语）”中增删改已有的缩略语，即改即生效（预览模式下按 F5 刷新当前页面即可）。

注 1 ：如果某个文档定义的缩略语太多，可能会出现缩略语重复的情况（此时它们所代表的原始内容有可能一致，也可能不一致）。此时，软件不进行校验、提醒或干扰，以第一个为准。

注 2 ：一个文档中，同一个缩略语可多次出现。所有出现的地方，在预览或生成网页时全部替换为该缩略语所代表的原始内容。

注 3 ：所定义的缩略语，请不要和文档中已有的语句或短语相同，否则，这些内容也将成为缩略语（原因见注 2 ）。此外，为了便于阅读、编辑和理解，可使用自己习惯的前缀和后缀来包裹缩略语。比如：“_长链 01_”、“@该处不宜改动 @”、“ AbbrevOfSomeFunnyThings ”……等等。

注 4 ：缩略语所代表的原始内容中可包含 Markdown 或任意 html 、 css 、 js 等标记 /代码。这些标记和代码在预览或生成网页时和普通内容一样，将被正确识别和处理。这一点在编辑高级功能的文档时非常实用（比如动态网页或格式与样式非常丰富的个性化 /专业性文档 /网页，编辑时不破坏版面的可读性与美观度）。还可以用该功能实现 Code snippets 展示……玩法很多，敬请摸索：）

注 5 ：采用缩略语后，无论整个项目的搜索替换，还是当前文档的搜索替换，都无法再针对缩略前的原始内容进行。这一点我稍后将予以改进。

注 6 ：下一步有可能拓展缩略语功能。目前先把大体的架构与功能拿出来。欢迎提供宝贵意见和建议。

• 新增：非标准 Markdown 语法标记：加粗同时斜体。语法格式：***要加粗并倾斜的文字***，效果：要加粗并倾斜的文字。因该格式不常用，故编辑器中没有定义其快捷键，也没有定义其智能化输入模式（比如选定文本后按三下*号完成自动包裹这个功能）。使用方法：可手工输入，也可利用编辑器右键菜单中的“ Format （格式）”菜单项来完成（当前有选择的文本时，该文本自动被三星包裹；如没有选择任何文本，则给出六个星，插字符光标自动定位到需要输入文本的六个星的最中间）。

• 实现：每个项目都可以记忆用户调好的窗口大小及屏幕位置并自动使用之。 WDTP 允许操作系统同时运行多个程序实例，这样可以同时打开并处理多个项目，每个项目都可以有自己的大小和位置。如果同时打开的项目较多， WDTP 会智能调整每个实例，在使用其自身所记忆的位置的同时，如可能有完全重叠或覆盖，则自动微调。微调结果并不影响该项目已经熟悉并记忆的原有窗口大小及位置。

以上这些都是程序内部运作的，用户无需设置或进行任何这方面的操作。甚至完全可以不知道有此功能。

- 改进： Ctrl + 回车在当前段落之前插入新段落，不再自动添加隔行，而是紧邻当前段落。即： Ctrl + 回车相当于正常回车键的反功能。正常回车是在下面插入新行，而 Ctrl + 回车则在上面插入新行。所不同的： Ctrl + 回车是以当前段落为单位，在段落之前插入新行，而不是在当前行之前插入新行。

@TheKiteRunner 先生，好的。您的建议总是很及时：）我昨天刚刚把脚注这个事加到 todo list 中：）

加粗同时斜体，当时写 Markdown 解析这个模块时考虑了。我个人觉得不是非常必要，页面中有这种样式的文字，看起来怪怪的，显得过分突出，不搭调。而且也不是“正统” Markdown 所定义的标准，于是就没有写这个标记的解析。实际上说来说去，还是 Markdown 这种标记语法的目的、应用场景与核心思路的问题。它不是追求专业级排版格式和样式的文本标记语言，在方便和简约的同时，肯定会牺牲并放弃一些这样那样的需求。也就是说，有些需求的解决方案，不能依赖于 Markdown 本身……

WDTP 的文本编辑器中可以直接输入 html 、 css 和 js ，能实现很丰富的效果。有些不常用但有需要的应用场景，可以用这三者解决，可以做到基本逼近完美：）

@dimlau 先生，谢谢您的推荐和文章：）我仔细地看了。我没有用过 thingamablog 这个软件，但相信一定非常优秀：）
更难得的是，一款优秀的软件被优秀的用户所发现、使用并向更多有需求的人们推荐介绍。这是一段佳话。

我想， thingamablog 的开发者非常幸运，能得到您的青睐和撰文。对一款产品的设计、开发和维护者来说，这是最高的荣誉。我很羡慕他（们）：）

这个工作日又干了 18.5 个小时了，实在撑不住了。下去眯一会。
稍后上来继续玩命：）

@TheKiteRunner 不，您的建议十足珍贵和及时，从产品方来说，遇到了非常有价值的黄金用户。我感到很幸运：）

我刚才一直琢磨如何用最简洁的办法，不用所见所得来实现您的需求（长链接缩略，不影响写作体验。确实，很长的链接看起来很头疼，非常影响编辑时的页面观感）。

我一定把这个事给您解决了，请放心：）