Sign Up for Free

RunKit +

Try any Node.js package right in your browser

This is a playground to test code. It runs a full Node.js environment and already has all of npm’s 1,000,000+ packages pre-installed, including mingkwai-typesetter with all npm packages installed. Try it out:

var mingkwaiTypesetter = require("mingkwai-typesetter")

This service is provided by RunKit and is not affiliated with npm, Inc or the package authors.

mingkwai-typesetter v0.3.0

A streaming MarkDown -> (Xe, Lua)LaTeX -> PDF typesetter

**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)*

MingKwai Type Setter 明快排字機

A streaming MarkDown -> LaTeX (i.e. XeLaTeX, LuaLaTeX) -> PDF typesetter, implemented in CoffeeScript.

Syntax

Level 1—MarkDown Syntax

MingKwai TypeSetter (MKTS) uses markdown-it* and, as such, supports all the parts of CommonMark, the Common MarkDown Spec that are supported by markdown-it core—or any available syntax plugin—offers, provided an adapter for the given feature has been integrated into the MKTS processing pipeline.

*) this may change in the future, since markdown-it does not currently support parsing sources in a piecemeal fashion as would be appropriate for an all-out streaming framework.

Level 2—HTML Tags

Since markdown-it accepts raw HTML tags, it is possible to 'escape to HTML' to quickly get features not available in MarkDown as such; however, this also presupposes that an HTML-to-TeX translation for the HTML tags has been implemented.*

*) at the time of this writng, no plug-in structure for syntax extensions has been establish, but that will hopefully change in the future.

Level 3—MKTS Tags (MingKwai TypeScript)

  • HTML:
  • Raw (i.e. <<(raw>>\TeX<<raw)>>/<<(raw>>\LaTeX<<raw)>>): <<<...raw material...>>>
* Regions: * Spans: `<<(span>>...<>` * Blocks: `<<[block>>...<>` * ... * ... * Actions: `<>` * Exec-Block: <<(!>>exec block<> * Value Interpolation: * Eval-Block: `<<(\$>>eval block<<\$)>>`

Fonts and Styles

The MKTS design philosophy rejects the idea of there being stylistic variations of a given typeface; instead, it treats each font (German: Schriftschnitt) as an entity in its own right.

  • what can be done algorithmically vs what can only be done by conscious choice by the designer

    • Italic: Nope—Oblique yes, but no Italic in the proper sense
    • Bold: Easier than Italic, but no thanks

It turns out that in present day digital typesetting, all the algorithmic type variation that you can both get and actually use in a serious publication is retricted to, basically, scaling ( type size). You can squeeze and stretch type a teenie-weenie bit, but that's about it.

In theory underlines are very well within the reach of algorithmic type modification, but, astoundingly, in practice almost all underlined text looks ugly. That should not be the case, given how straightforward it is to add an underline to text. The Shady Characters website is a the rare exception; there, the designers went to lengths and devised ways to ensure that underlined text look good.[^There's a very interesting proposal for a CSS property text-decoration-skip to provide for, inter alia, gaps in the underline where it would otherwise cross descenders; as of 2016, it hasn't been implemented in any browser, though.]

Some (like Knuth) would argue that even mere font scaling produces another font (Schriftschnitt), and this was indeed, by and large, the matter of affairs with movable type, where you had one case with, say Times Roman @ 12pt and a separate one with Times Roman @ 10pt.

But observe that (1) even Knuth probably did not provide hand-tailored separate masters for each of the envisioned type sizes, not even the several small and very small ones (citation needed); (2) Knuths multiple masters were probably done algorithmically with MetaFont (citation needed); and that (3) even in the olden days, designers used mechanical devices like pantographs to be able to just-so produce multiple sizes from the exact same urbild (some adjustments notwithstanding, like keeping hairlines to a certain minimum required widths—that's what we have font hinting and ClearType for in the digital world).

  • Algorithmic Variation vs Hand-Picked Matches
  • Convenient Packaging vs Freedom of Choice
  • Helps Simplicity, Ease and Clarity of Implementation
RunKit is a free, in-browser JavaScript dev environment for prototyping Node.js code, with every npm package installed. Sign up to share your code.
Sign Up for Free