ConTeXt 内嵌文本的逐步显示

在 [1] 中讲述了基于 Buffer 的 ConTeXt 逐步显示效果的实现方案。这种方案因为依赖 Buffer 的逐级继承,所以只能满足尾部内容追加式的逐步显示需求,而无法实现内嵌文本逐步显示效果。

所谓内嵌文本的逐步显示,可以通过一个简单的示例获得直观认识。假设一份 PDF 文档,它的第一页内容如下图所示:

第二页内容如下图所示:

这两页内容在 PDF 浏览器中全屏切换时,便可以产生内嵌文本的逐步显示效果。

本文采用文本透明颜色与非透明颜色的切换实现上述内嵌文本的逐步显示。这样虽然很笨拙,但是好在几乎所有的 PDF 阅读器都支持这一方案。

继续阅读

使用 ConTeXt 的 buffer 制作逐步显示效果

用过 LaTeX Beamer 宏包的同学应当知道 Beamer 在制作步骤列表时,可将一块完整的内容分布于多个演示文档页面,以实现演示过程中逐步显示的效果。

ConTeXt 也有一些模块可以实现逐步显示效果,例如 Raw Steps 模块 [1],还有 Hans Hagen 基于 PDF 的 JavaScript 实现的 s-pre-60.mkiv 和 s-pre-61.tex [2]。前者与后者的详细的功能比较见 [3],简而言之,前者与 LaTeX Beamer 相似,通过静态页面的切换实现内容的逐步显示;后者是通过 PDF 内嵌的 JavaScript 程序控制页面元素的显示与隐藏。虽然后者可以充分利用 PDF 的性能,但现在也许只有 Adobe Reader 可以很好的支持 PDF 中嵌入 Javascript,作为 Linux 环境中的 Evince 用户,我对后者伤不起啊,因此我投前者一票。但是很不幸,Raw Steps 年久失修,现在基本上废掉了,其作者也不知所踪,而我现在还不具备修复它的能力。不过 Raw Steps 的原理很简单,它主要是利用 ConTeXt 的 buffer 功能实现的。

继续阅读

ConTeXt MkIV 的 pinpoint 模块

心怀文档 [1] 散发的余热,这两天折腾了一下 ConTeXt 与 Pinpoint 的结合,成果便是 pinpoint 模块,并在 github 上建立了一个项目:https://github.com/liyanrui/pinpoint

ConTeXt 与 Pinpoint 的结合效果如以下视频所示。

 

[1] http://garfileo.is-programmer.com/2011/6/20/using-pinpoint-with-tex-for-presentation.27455.html

TeX 与 Pinpoint 的结合

TeX 是用来排版科技文献的,也可以做科技方面的演示文档,例如 ConTeXt 以及 LaTeX 环境中的 Beamer 都具备这方面的能力,即生成 PDF 文件,通过  PDF 阅读器提供的全屏以及简单的演示画面切换等功能进行演示。可能 PDF 阅读器提供的演示画面切换效果不尽人意,而 impressive [1]可以弥补这一缺陷。这种制作演示文档的方式虽然可以胜任一般的科技内容的报告,但是仍然存在一些不足,例如无法实时调整演示内容,难以嵌入视频等。

最近在 linuxtoy 上看到有关 Pinpoint 的介绍 [2]。这个软件以前是 clutter 项目中的一个玩具 [3],最近迁移到了 gnome 的软件仓库。不严肃的说,Pinpoint 是一款制作及放映演示文档的工具。事实上,Pinpoint 的工作方式和 HTML 浏览器、TeX 类似,它自定义了一种标记语言——姑且称之为 Pin 标记,并负责将含有Pin 标记的源文档“翻译”为演示画面。我制作了一份 Pinpoint 演示过程的视频 [4] 可供观摩。

虽然 Pinpoint 的功能比较简单(确切的说应该是简陋),但是它有以下不俗之处:

  • 首先它的全部功能都不庸俗,因为是面向 geek 的,不是面向大众的。我不敢说是面向 hacker 的,因为月光博客正在喷黑和被黑 ing。
  • 可实时修改源文档,修改结果会在演示过程中实时刷新。这意味着我们可以一边做演示,一边做调整。
  • 可将视频文件作为演示画面的背景并播放。

也就是说 Pinpoint 所具有的一些功能恰好是 TeX 演示文档制作方式中所缺乏的。如果能够实现二者的结合,也许可以改善 TeX 演示文档一贯的呆板风格。本文讲述实现二者结合的一种方案。

继续阅读

ConTeXt 模块参数的获取

本文讲述了 ConTeXt 模块参数的传入与获取方法。

阅读全文

基于 ASCIIMathML.js 的 is-programmer 博客数学公式书写及显示

本来是为了解决实验室内部 Wiki(基于MoinMoin 引擎)的数学公式支持问题,在 MoinMoin 官方 Wiki 上看到了基于 ASCIIMathML.js 的解决方案,感觉这种方案要比使用 TeX 引擎更好一些[1]。当然,缺点也不是没有,最大的问题可能是这种方案需要网页的浏览者安装一些字体或软件。不过,由于网络上创造内容的人通常是无偿的劳动,如果浏览者觉得能够从所读内容中有所收获,他们也不至于懒到无动于衷的地步。所以,基于 ASCIIMathML.js 的数学公式支持所能带来的好处应当远大于它的缺点。

下面我根据实验室内部 Wiki 的解决方案,谈一下让 is-programmer 博客通过 ASSCIIMathML.js 获得数学公式支持的方法,希望对 is-programmer 博客的其他用户有所帮助。

继续阅读

运行在 nginx 与 uwsgi 之上的 moinmoin

这篇文章主要是面向 Gentoo Linux 用户,其他 Linux 发行版用户只能慎重参考。之所以这样讲,是因为如果对于 nginx 与 uwsgi 不熟悉,很容易被各个发行版对它们自作主张的部署搞的头昏,主要问题出在系统的初始化脚本方面 [1]、缺乏足够的耐心以及对陌生知识的恐惧等方面。

继续阅读

有趣的 M4

通过一个示例演示了 GNU M4 的基本用法。

阅读全文

GObject 信号机制——信号连接

文档 [1, 2] 讲述了 GObject 信号注册的相关细节,本文进一步分析信号与闭包的关联问题,即信号连接。

继续阅读

在 X11 中实现 GTK+ 3 的 OpenGL 支持

最近,开始思考 GTK+ 3.0 的 OpenGL 支持的问题。由于 GtkGLExt 现在还不支持 GTK+ 3.0,其维护者对此没有任何表示。现在最务实的办法是使用 clutter-gtk 库,通过 Clutter 的底层库 Cogl(OpenGL 的面向对象封装)在 GTK+ 3 的 Widget 中绘制 OpenGL 图形。但是,目前 Cogl 功能尚不完善,例如不支持用户自定义帧缓存格式,缺乏光照支持,以及图形渲染方式过于单调,仅支持顶点缓存(Vertex Buffer)渲染。考虑到 GTK+ 在 X11 是通过封装 xlib 实现的,而 xlib 可通过 GLX 实现 OpenGL 支持[1]。因此,通过 xlib 与 GLX 结合的途径,理论上必然可实现 X11 环境中 GTK+ 3.0 的 OpenGL 支持。

继续阅读