You are viewing a single comment's thread from:

RE: Steem Keychain 简介和操作指南

in #cn5 years ago

如果是markdown中包含比较多的html,一个潜在问题是可能某些编辑由于完全不了解html语法会犯晕,不知道如何进行修改。steem上markdown的原生语法似乎更普及一些。

所以,主要是想了解下之前的编辑过程是否遇到过类似情况,是如何权衡的?

Sort:  

编译前写一个预处理脚本,提取其中的image url,自动下载图片到本地并替换路径。

bookdownplus::include_image() 干的就是这个。除此之外,如果图片是 gif 动图,它会自动截取第一帧,另存为 png,再插入 pdf。

之前没有遇到过混杂 html 的情况。当时大家都是以 markdown 格式投稿的。

大不了把 html 预处理一下,用 pandoc 转成 markdown 再合并进书稿。

好的,谢谢大鹏提供的信息 :)

代码commit以后,确实有一些工作是可以自动化的,至少保证最后输出结果无误是不困难的。

不过这里其实主要是人的问题:

由于我们现在的合作模型是作者写作+编辑提交代码,问题主要在源码阶段的作者的自由度编辑的工作量之间的权衡。

  • 如果作者都用不包含html的markdown会比较规范,但对于某些作者来说,则不自由(如不能用steempress写作),但对编辑来说格式相对统一;
  • 反之,则作者自由、且对某些作者来说写作效率和收益也会提高,编辑需要更多知识(学习成本)或工作(编写成本)。

我考虑了一下,可能还是在编辑这里加一道工序,将html格式通过在线工具(如这个,或者有其他更简易的方式)转换成markdown以后再提交。如此,作者自由,编辑的成本增加的也较少。

html 转 markdown 用 pandoc。说不定 travis-CI 可以自动完成。

wordpress 有 markdown 插件,可以在 wordpress 上用 markdown 写,虽然用 steempress 发布后会转成 html,但是 wordpress 的markdown 源文本可以提交到 github。

不过这依然是作者自由度的问题。作者书写方式越规范,编辑和后期维护越容易。越放飞自我,越麻烦。

嗯嗯,

  1. 第一点,我上面也提到了,commit以后,可以在build阶段做一些检测,这样可以保证结果是无误的。不过主要问题应该还是在编辑的阶段。。。
  2. 第二点,作者需要了解的细节还挺多的,比如markdown写作以后如何提交到GitHub,然后有的作者用wordpress也是为了少用markdown。。。

所以原则上,还是让机器能做的事情让机器做吧,只不过在编辑、合并、编译每个阶段可能要用到一些不同的工具。。。解放作者和编辑之间,根据具体情况再做一些协调吧~

大鹏,顺便请教一下,之前文档里的标题是不是最多支持到第三级?如果使用第四级标题是会在目录里增加新的一级吗?

标题3

标题4

意思是指在这个编辑的工作流中加一步,在GitHub的编辑器编辑之前,先将html转换为markdown

想得比较多、比较细,主要还是目前假设的编辑的技术基础比较薄弱一点。。。

当然,如果有 html --> rmarkdown 的converter的话会更好一些,之前书本编译的很多问题就是由于文档中的rmarkdown语法错误引起的。:P

Coin Marketplace

STEEM 0.33
TRX 0.12
JST 0.038
BTC 69789.16
ETH 3514.62
USDT 1.00
SBD 4.56