图片的管理与运营

上下文无感知

一个图片不能在多个场合进行引用，主要体现在无法根据上下文条件进行自适应的调整，例如

• 矢量缩放
• 配色主题的更换
• 格式的自动转换
• 重构、抽取与局部引用

内容价值弱反馈，变更无感知

目前大部分的绘图工具的设计，都缺乏对「协作」的支持。

也就是说，他们都假设了，「产物的作者 就是 使用者」。

简而言之，就是用同一个工具进行编辑、修改和演示。

从协作的角度来说，「产物的作者 不是 使用者」

简而言之，就是进行编辑、修改的工具，和进行演示的工具不是同一个，是相互松耦合的。

即便是实现了松耦合的工具设计，目前也缺乏 「使用者」 对于上游 「作者」 进行内容更新的通知与提醒。

这些因素，导致了内容的分享变得困难，对内容的价值评价变得无法进行。

二进制图片的内容管理

二进制图片，是没有办法采用面向文本的 diff 工具，对的内容进行精准比较的。

图的重度依赖者，又非常希望能够看到两张图片在内容上的细节差异，不想在一张图片的若干版本中，重复的进行着「找不同」的游戏。

这也是二进制图片，表达「图意」的难点。在数据处理领域，称之为「无结构的数据」。

这种称呼，其实是站在图片的使用者角度，无法用计算机直接理解图片的「图意」。

目前的人工智能或者说是机器学习，对于图片的识别已经有了长足的进步，能够识别「日常」的一些「简单图片」。

不过，对于「工程制图」的结构识别、模型还原的应用，还不多见。

商业或者封闭的绘制工具

一般，商业的绘制工具，对图的物理格式，都采用特有的方式进行编码，即便是基于 XML 方式进行解析，大多数情况下，只能靠人猜测其含义。

同时，商业工具，还会持有一些「布局算法」，并可能以专利的形式进行保护。

这样，对于非官方的「图片浏览器」而言，则会产生布局效果差强人意的结果。

很明显的例子是，对于 Office 系列文件的图形化渲染， 用A工具绘制的图片，在B工具内打开，可能就会发生剧烈的变形。

也就是说，这些封闭的绘图工具，在产品设计的时候，有一个基本的假设，那么就是图片的绘制，与图片的浏览，都在本工具之内进行。 这可能是增加产品「用户粘性」的一个手段？

基于文本生成的例子

以git为代表的管理工具，是对文本文件，进行版本管理的最佳选择。

SVG 等等以 XML 为核心的文本格式矢量图，或者是以 PlantUML 为代表的，有自己特有语法的描述语言，可以进行多种输出图片格式的图形转换。

在软件领域，PlantUML ，是在设计阶段，最为「淳朴」的UML绘制工具，也就是说，整体布局由 PlantUML 自行通过算法完成，用户很多时候能够采取一些「小技巧」来实现布局上的「更高要求」。

可以说，PlantUML 是可以解决一些小规模程序的设计图的绘制问题。 同时还能够以文本的形式，对内容进行版本管理。

使用标记语言聚合内容

标记语言，是基于文本的，它很大程度上解决了内容与格式的紧耦合模式。

这种方式，相比传统的 Office套件（无论那个厂商），放弃了一些「所见即所得」的撰写体验（其实也有热心群众提供非官方插件支持），但释放了内容的「复用、分享」能力。

把修饰文字的「元信息」，通过简单的特殊符号，附加在特定的文字周围。

比较简单的和典型的有（按学习难度排序）

• Markdown
• reStructuredText
• AsciiDoc

这些标记语言，都是基于文本的，并且天然的支持以「URL」的方式对图片进行引用。

例如，本文，就是用 reStructuredText 编写的，引用图片时候，只需要写成：

.. image:: /images/2017/01-13/the-way-of-pubsub-diagram-4.png
    :height: 400px
    :width: 450px
    :align: center

就能够完成对一个图片的引用，当然，还可以是外链的URL。

老态龙钟的 Microsoft Office

其实，Apple家的Keynote也类似。只是Microsoft Office市场占有率更高一些。

• Microsoft Word Version 15.30 (170107)

不支持用URL引用一个「外部远程」图片。

• Microsoft Powerpoint Version 15.30 (170107)

不支持用URL引用一个「外部远程」Slide，图片也类似。

与时俱进的 Google Docs

在探查之前，就一定猜到，Google一定是支持引用「外部URL」的。

例如，可以在Google Docs中，插入一个URL形式的图片。

令人失望的 Office 365

可以看到，企业文化、产品理念的差异，很容易体现在「功能细节」上，用户的内心自然而然会有公道的评价。

意料之外的 PlantUML

可以说，PlantUML 是工具解耦上做的最充分的一个工具了（虽然任然有缺陷，例如对于中文的处理）

PlantUML 生成图片，可以基于「Web Service」进行。PlantUML 官方提供了一个演示的例子：

http://www.plantuml.com/plantuml/proxy?src=<your_puml_url>

http://www.plantuml.com/plantuml/proxy?src=https://raw.github.com/plantuml/plantuml-server/master/src/main/webapp/resource/test2diagrams.txt

Presentation领域的 SlideHub

虽然 SlideHub 不是直接对图片进行的分享，但是它基本上已经是除了 SlideShare 之外，自行搭建演示文稿分享的不二选择了。

SlideShare 和 开源的 SlideHub 都实现了对 Office Open XML 的解析，以及对于Slide的切片。

在 SlideShare 上，每个用户都可以收藏自己重点关注的 Slide ，而不用收藏 Presentation 的全文。

实际上， Office Open XML 是一个开放的 Office 文件标准。

Presentation的物理结构是基本上是这样的（用Zip解压工具，解压之后就能够看到，如果你不想看枯燥的标准的话）：

几个关键的目录：

• _rels : 组织整个Presentation的结构，完成内容的编排。
• diagrams : 是以 XML 为物理结构的矢量图。
• media: 外部的二进制图片，或者视频。
• slideLayout : slide的基本布局模板。
• slideMaster : slide母版的基本布局模板。
• theme: 基本的矢量图配色方案。

如果，一系列的 Presentation 作者，是同一个人或者组织，那么这些 Presentation 的风格、主题应当较为类似。并且能够有很多的 diagrams 能够复用。

再进一步地，应当能够基于已有的 Presentation 进行快速的内容编排，形成一份新的 Presentation 。

另一方面，如果一些 Slide 发生了版本变更，那么那些引用这些发生变更的 Slide 的 Presentation的作者，也应当能够收到「变更提醒」，进一步的有帮助他们完成内容的自动更新。

也许这是 SlideShare 企业版所拥有的能力。（ SlideShare 有企业版吗？）

不过，Google Slides 已经支持了 Import , 它缺的一个社区，缺一个对 diagram 这些素材的管理:

Document领域的 Mkdocs

企业，对于 Document 的需求是频繁的，例如：合同、使用说明书、设计说明书，或者出版物，都需要有「内容」与「排版」分离的素材管理模型。

MkDocs 是众多的「静态网站生成器」（SSG）中的一个 ( StaticGen 对他们有个简要的介绍 ) 。

另外，最著名的应当还要属于 gitbook ，但是它并不支持在企业中进行 on-premise 部署，只支持以 SaaS 的云模式提供服务。

它们好还是不好，这是个主观的判断，「合适」自身的特点，才是真的好。

新媒体渠道

新媒体渠道，可能会包括企业「自运营」的网站，以及由第三方托管的「内容平台」，例如，微信公众平台。

对于企业「自运营」的网站，可以使用一部分的 SSG 能力，实现对内容的版本化更新。

对于类似于「微信公众平台」，则可以使用 OpenAPI 进行素材的自动化管理。

这类非官方的素材非常多，可以去 GitHub 上进行搜索。