Typora?

范狂夫

所答非所问一把,目前Typora还没到1.0正式版,还会有这样那样的问题。不过呢,Markdown格式本身倒是比较成熟,日常使用差不多够了。

就比方说吧,《真・流水帐》或曰「日记」目前在Word当中是165页A4幅面,十八万字,里面有不少图片,还带着三级标题。

前一阵转换为Markdown版的时候,就不能在纯文本环境下复制粘贴了,否则格式需要重新调整很久。于是,直接贴在Typora当中,大部分格式都自动转换了,运用了剪贴板的HTML格式数据。

目前写日记同时更新Word版和Typora版,后者截图是这样的(han主题):

Typora 0.9.48(bata)
Typora 0.9.48(bata)

而其它几种字处理软件当中的情况,之前在《范版数学恶补记》流水帐中贴过了,这里再贴一遍:

Microsoft Word 2010
Microsoft Word 2010
LibreOffice Writer 5.4
LibreOffice Writer 5.4
WPS 2016抢鲜版
WPS 2016抢鲜版
Ashampoo TextMaker 2018
Ashampoo TextMaker 2018

日记摘抄

这《范版数学恶补记》「流水帐」也很久没有更新了,第四十篇还是2月22日。但这并不是说我一直闲着,在真・流水帐里面还在随时关注业内动向吖。就说符合本问题的Markdown相关内容吧,把这一段日记里面相关内容摘出来,列在这里。

3月6日(火),多云

下了一个「Kate」,作为传统编辑器还是可以的,就是没有预览Markdown格式。又搜了一圈,发现了正在开发中的「KTextEditor Document Preview Plugin」可以给Kate和KDevelop提供预览支持,今年2月12日有个「KMarkdownWebView 0.5.0」的发布,截图是预览压缩包当中的「*.md」文件,不是「源码」而是渲染过的「网页」。那么只要等就可以了也,KDE「应用」的内置支持会在下一个更新版本中出现吧。

3月16日(金),多云

顺便记个脑洞,之前提到了「不等长分页」的码字环境,主要还是由于写日记的时候看着这堆标题和图片经常被推到下一页去而在当前留下大片空白很不顺眼。这里就提供个刚想到的名字,「卷轴」(Scrolls),因为苹果的那个字处理程序叫「页面」(Pages)而微软的那个叫「单词」(Word),复数形式使用与否很有趣嘛。

另外,就按照西方语源最初的设定,罗马纸草或羊皮卷轴篇幅大约四百到八百行,估计有内容的「网页」最大也就这个规模了,再大就该「翻页」或者说「下一卷」了也。还有,按照行数计算稿费的规矩是欧洲才有,之前解释过法兰西钦定文豪大仲马钻空子的典故了。而兲朝是按照字数计算,那么兲朝规矩的「卷轴」是竹简,篇幅可以参考先秦古籍当中分卷,每「卷」字数也能知道。

补充,刚想起来,Windows自带的附件当中有个「写字板」(WordPad),最初也是处理RTF的,没装Word的时候默认「.doc」就用这东西打开。印象里以前见过一堆「.wri」文件,据称是写字板专用格式,可能是Win9x时代的事,记不清了。还记得原来用PDA的时候,WinCE版Word文件就是RTF,扩展名是DOC而已。

想起来就打开现在Win7下面的写字板,发现「不分页」,随着篇幅扩展,并且有余白,与Word里面「Web版式视图」或「草稿」还不一样。编辑文字的常用格式差不多也够了,有「删除线」「上标」「下标」,怀疑Markdown的某个扩展,以「~^_」提供这三种格式,就是参考「写字板」实现的,也就是RTF即可支持的格式。

这「富文本」RTF格式太古老,不过Windows内置「富文本编辑」控件,以前提到过,被.Net包装了一层,到了WTF之下,直接支持「流文档」格式了也。上网搜了一圈,发现「*.wri」是最早的「书写器」(Windows Write)格式,Win95开始内置了「写字板」,「源代码」也已经公开。这里说的源代码,应该还是使用「富文本编辑」控件的其余部分,而不是控件本身的源代码。

要严密的考虑问题,「网页」本来就不分页,打印的时候才会作出适合实体纸张的拆分,而RTF应该也一样,为了适合各种纸张规格才「不得已」有分页的设定。换句话说,在RTF基础上提供HTML六级标签之类「样式」,可以迅速形成「网文码字环境」,还所见即所得。而缺陷也早就提到了,没有动态内容,针对实体的格式当中允许插入的图片都是静态的,何况视频音频。于是,目前网上那些允许插入图片视频的「富文本」编辑器更合适,而「markdown-it-video」这种扩展还没形成共识。

但是呢,有些文件格式注定是要形成实体的,就看纸张规格当中的美帝灯塔国专用「Letter」「Legal」也知道。前者专用于信件,折叠成「Z」字型把开头右上角的收信人地址暴露于信封开窗处,这是「英语学到初一」的家伙就知道的「常识」。那么就是说,如果类似《少年维特之烦恼》那种体裁,以通信体创作的内容,为了逼真起见,哪怕在网上发表,也应该按照「信纸」面积「设计」内容,包括字体段落甚至剪报、涂鸦简笔画在内。这就肯定不是「流文档」了。

3月22日(木),晴

上午九点起,沏茶。在煎蛋继续与活跃网友谈笑风生,顺便把评论进行备份。对于文章来说,有链接存在,可以按照备份知乎评论的格式;而对于贴图和段子区,没有链接,只能同时截图一起保存。约十二点,在知乎找了个Markdown相关问题,把这些感想整理一下回复上去,并在简书备份。

顺便发现了一个「CommonMark」项目,据称是准备「标准化」的时候,「Standard Markdown」字眼被原作者投诉,所以改了这个名字。因为原作者认为自由的发展哪怕出现一批互不兼容的方言,才是Markdown活力之所在。

之前一直没注意到这个项目,上去看了一眼,规范当中确实考虑了很多情况并准备了很多测试用例。而我在对此一无所知的时候,实践中已经发现了一些「书名号方引号为边界情况下」格式不正确,因为用的是VS Code插件,编写者遵守的就是CommonMark主要推动者GitHub用户群的共识,恐怕这些问题在如今仍然存在。

从文档中也发现,其它语种的例子是希腊字母和基里尔字母,没考虑到东亚各语种中「没有空格作为定界符」的场合吧。不过呢,实践中还发现,若是发现解析有误,手动加个空格就可以了,在最终的HTML文件中不出现。

3月23日(金),阴

还有个问题,因为最新发言是关于markdown的,也是最近一直使用并有了一堆感想的。之前曾经设想连同网页和附件一起打包压缩,但是刚才忽然又想起一个古老格式「Web档案,单个文件(*.mht)」只能用IE「另存为」,是以类似电子邮件的MIME格式转码的,其中二进制内容使用base64编码。以前工作中接受到附件「被错误编码」而打不开的邮件,也曾经手动重新转码成二进制。并且印象里似乎有些网页当中的嵌入图片也是使用base64编码直接写在页面当中的,比方说SVG。那么之前设想的「妈的智障」(mdzz)文件似乎又多了一种可能,采用的也是公开标准。

3月25日(日),晴

发现VS Code预览的相对路径,是依赖「当前目录」的,也就是打开两个不同目录的md文件,按照「./插图/」这种写法,肯定至少一个预览不了。目前还没找到比较好的解决办法,不过对目前的使用来说这种情况比较少见,先关闭「工作区」再打开文件就解决了。

然后换了另外两种Markdown专用编辑器。其中MarkdownPad不能预览本地图片,并且预览渲染太慢,最开始由于「快捷键」的方便,用来转换了所有发言的格式,后来一直没怎么用。而Typora还没到正式版,内置LaTeX公式倒是很方便,但因为「所见即所得」反而稍微有点不习惯。知道有个功能是直接粘贴图片自动复制到文本文件相同目录之下,但是也不适合我这里单独一个目录存放所有图片的情况,准备再等几次更新之后再说。

回家先写日记,然后忽然想起刚才看到Typora目标是取代Word于是有「大纲」侧边栏,那么立刻动手把日记转换成Markdown格式。因为「所见即所得」,所以复制粘贴过去,包括标题和表格在内的排版格式都可以保留,应该是从剪贴板的「html内容」解析的。接下来把图片从docx里面一个个保存出去再插入到markdown里面,保存之后再换成VS Code打开。发现开头加了两行typora设定,删掉也没问题。并且typora支持路径以「/」开头而VS Code只支持「./」,统一成后者。

3月26日(月),晴

发现今后日记需要在docx和markdown俩文件当中同步更新了,而markdown还得在typora和VS Code俩环境当中都预览合格。目前「所见即所得」(还免费)的Markdown编辑器也就typora一个,除去那些插入的「设置」内容之外,也就是「主题」可以切换,实现成什么样就是什么样。而VS Code不是Markdown专用,主题之类设计还需要照顾其它所有模式。

为什么这么想?因为在Word版日记里面的这个样式,尤其是几级标题的风格,是当初从一堆内置样式当中挑出来比较简约清爽的。如果要在Markdown版日记里面使用,需要自己修改CSS。而我虽然对CSS很熟悉,但对「字体及配色方案」之类「专业」技能还是比较薄弱的,多一事不如少一事。

顺便,看到「CommonMark」之后,之前惦记着用「扩展ASCII字符」当标签以避免与正文混淆的脑洞又浮现出来了。比如用「§」取代标题的「#」,用类似边框线的「‡」取代引用的「>」,用正经的圆点「•」取代无序列表的「+-*」,用欧元「€」或英镑「£」取代数学公式的「$」,用「©®¤¶」之类实现其它什么功能。

就看应景的上面这段,在VS Code的源代码窗口当中显示是这样的:

VSCode解析源码失误
VSCode解析源码失误

在当前这堆Markdown插件环境下,只要是出现了美元符号「$」肯定会当成「公式」着色,加了反斜杠也一样,虽然解析和预览都是正常的。作为不入流码农,我当然知道这个「无伤大雅」的八阿哥处理起来未必那么容易,但是「多一事不如少一事」,所以才惦记着换成「不会与正文混淆的」符号吖。

想到这里补充一点,因为「LeTiX」或「LaTeX」的缘故,最初倾向用长得像「L」的英镑符号「£」标记公式。然后就想起了还有德国马克符号「Ð」但是与字母「D」太像了所以应当尽量避免使用。再然后就想起了「马克」就是「Mark」吖,那么这「CommonMark」看上去适合英语国家,而我设计的方案需要「西欧键盘」可以直接敲出符号来,难道叫「EuroMark」不成?于是不经意间又可以使用不涉及政治和意识形态的纯粹技术讨论,引领政治和意识形态斗争新动向了也。

顺便,刚才备份评论的时候发现,typora和VS Code对于行末「反斜杠硬回车换行」的处理不一样,typora很明显不区分「硬回车」与「空行」,在这个细节上没有遵守Markdown「共识」。

3月27日(火),霾兼沙尘暴

刚才因为临时追加「几个字」,就没启动Typora或VS Code,使用「文本编辑器」打开直接写,这本来也是Markdown「轻量级」的宗旨。其中Typora打开这将近一百五十页的文档并解析格式且渲染,需要时间比Word要长;而VS Code虽然也是「编辑器」,但不是「文本」专用,最起码核心功能当中提供了针对「代码」的附加内容,解析这两千五百多行(按硬回车计算,其实是「段」)也需要时间。

虽然之前提到「卷轴」篇幅四百到八百行,但是也想看看到底极限在哪里,三年日记写下来至少也是市面上「实体书」的篇幅。

4月2日(月),多云

然后闲得慌,想起「故事线」就下载了「写手咖啡」,装上之后大概看了一遍。惦记着全套「解决方案」没必要,具体某项功能还是可以照搬的。就比方说「故事线」,在Markdown当中没有现成的插件绘图,如果有需求,还得自己用JavaScript往Canvas上面画。但是呢,正如流程图序列图那样,实现也不困难(但测试等工作比较麻烦)。有需求就会有产品,没准钦定红客看我写完这段日记就准备纠集码农开发「StoryLine.js」了呢。仅限这次这里没有贬义,我现在的身份是「普通用户」,等着用现成的开源或免费的产品呢。

顺便多写几句,「故事线」功能既可以是流程图那样单独的「flow」代码块,也可以在Mermaid下面作为一个「子功能」,建议还是单独存在。因为「故事线」其实就是个二维表格「稀疏矩阵」,脚本都可以参考FlowChart那样,定义好「角色」「场景」然后用箭头链接就是了。并且默认应该是纵向的,除了通常地点比人物多之外,还是为了适应浏览器表现形式,与「写手咖啡」那种「宽屏」界面不同。

4月4日(水),阴有雨夹雪

早六点半起,沏茶。到九点回复了昨天下午到晚上的来自其它网友的评论,然后在本地备份并上传「各站」备份。整理过程中看到之前有些网友直接使用Unicode的emoji字符,想起输入法的候选列表当中也会出现emoji但在Word里面显示不正常(或许是字体缘故),又想起昨天下午临出门前更新了Typora,更新日志除了换行之外似乎还提到了emoji相关内容,然后顺便上网乱搜。

果然,Unicode当中的emoji极大充沛还是从2010年开始,之前只有零星几十个,但是符号总是有的,所以用「Word 2010」码字的时候偶尔也可以直接用输入法插入特殊符号。在Typora里面试验的结果,可以通过助记符(也就是Unicode规范中的命名,把空格替换成下划线基本上就是Github的约定)输入也可以直接输入。

4月6日(金),多云扬沙

七点半到十点半上床小憩。约十二点在知乎回复私信并备份。之前VS Code更新了一版,看更新日志,别的没注意,但是Markdown可以按标题折叠内容这个功能很不错,尤其是《真・流水账》这种在Word里A4纸157页的篇幅。关闭文件再打开还能记住折叠状态,不过关闭程序之后再打开就记不住了,毕竟纯文本格式当中没有保存设置的位置。解决方案也有,可以考虑追加一个「全部折叠」命令,然后从最下方展开,就能获得想要的结果(定位在当前日期的日记内容)。

又想起一件事。前天吧,因为银行卡的缘故,想起最近这些年经常很久才启动「Microsoft Outlook」收一次电子邮件,每次打开发现不过是一堆「通知」,包括但不限于信用卡消费记录,所以找了个当年用过的「nPop」邮件检查工具。因为相关各种协议简单,新世纪以来「网络助手」之类东西多得很,大部分都是开源或免费的,但是不好找,上班时还用「.Net Framework」写过一段。

然后呢,发现「预览」邮件内容是按照「纯文本」打开的,里面一堆html标签,找不到正文内容,想也知道「简单的工具」再引用浏览器对象没必要。这时候就想起Markdown本来用途了,尤其是作为「电子邮件插件」的时候,就是以纯文本的方式发送带格式的内容,在客户端转换并渲染也可以。而Markdown的「源码」看着也不费劲。所以,对于这种需要快速预览正文内容的场合,刚好有必要。

结论

好了,现在活跃的年轻帐号,尤其是那些在九省通衢活蹦乱跳的,疑似「华中科技大学」或「武汉理工大学」出身的,以膝盖生根磕头认爹保证学位证书的,信息技术领域的精英,大概能体会到我等老迈年高的「精神病仆街写手不入流码农数学渣」惯用台式机的历史唯物主义的尘埃,与它们这帮娱乐至死的童年才俊移动互联网民,之间的区别了吧?

2018.04.21