The current best way to start using Patoline is to refer to its GitHub repository, but more informations will be added here soon.

Patoline is a collection of typesetting libraries designed to be combined into a variety of possible applications.

Its primary goal is not to offer the definitive answer to all typesetting problems, but rather to write the painful and boring parts of the job, so that interesting tools could be written easily.

Obviously, a related (but much smaller) project is the Patoline compiler, which compiles a mixed Wiki/LaTeX/Ocaml syntax into a variety of output formats, including traditional PDF files, but also web servers that deliver dynamic contents, synchronized for instance with a talk.

Technical facts

• Patoline is mostly written in Ocaml, the reasons for this choice are explained below.
• It is designed to handle fonts well, in a uniform and simple framework.
• It uses fast state-of-the-art numerical methods to compute optimal spacing. Our algorithms will be published soon (although their implementations probably need some tuning).
• It can export the same documents to many output formats.
• Functions can be written with a general purpose programming language, which makes it easy to query for instance online bibliographic databases.
• It is designed with portability, long term archiving and forward compatibility in mind. For instance, the various encodings of unicode are already a builtin feature.
• The Patoline compiler uses a parser that can also parse maths, making it easy to detect syntax or type errors.

What's modularity?

Right now, the various parts of Patoline use common Ocaml constructors to communicate (hence the importance of static typing and module constructs). There are:

• Output formats, including libraries to output PDF, SVG (with typographic features portable across browsers), or more exotic formats such as OpenGL executables and web servers.
• A library to handle OpenType and TrueType (for the moment). The goal is to allow the user to explore, edit and use all the features of their fonts, in all possible scripts.
• Typesetting algorithms, that place figures and metal boxes (simulations thereof). Several typesetting algorithms could be written, to optimize size or learn beautiful typography using machine learning.
• A math library, that turns formulae into drawings using numerical methods.
• A library to edit document structures.
• A bibliographic tool, that can be extended in several ways, including more efficient and portable file formats, handling character encoding and names well.

Of course, all these components need to talk to each other nicely, which is the purpose of common data types included in the libraries.

Design choices

Writing a new typesetting system implies making a lot of design choices. They are all questionnable, by definition of a choice. Nevertheless, our goal, while writing the foundations of Patoline, has always been to make choices as transparent as possible to the user, by designing as many pieces as we could in a modular, replacable way.

Why OCaml?

Every computer user has their own preferences about the best language to communicate with a computer: some prefer graphical user interfaces (with preferences on the exact toolkit used), others like 3D gaming interfaces, others like object-oriented programming…

Choosing a common language for typography is a tough task. Our choice was constrained by the goal to let the user program inside the document, if they wished to do so. To achieve the long-term goals of:

• Modularity
• Backwards compatibility
• Portability

we decided to use a functionnal programming language, with types checked by the compiler (ensuring modularity and portability), and whose authors would also have backwards compatibility in mind. Concretely, the choice of OCaml means that even if you don't "test" documents extensively (whatever "testing a document" means), the programs inside your documents will never segfault or crash. Since most users of traditional typesetting systems are not expert programmers, we tried to avoid relying on their knowledge of software engineering "good practices" to achieve this goal, and chose to use a compiler to do that job for them.

And if you do not like OCaml, you can still write a compiler from your favorite typesetting language to OCaml. Ours compiles Patoline code to OCaml in a few hundred lines of OCaml code.

Can I use Patoline to produce commercial documents?

Short answer: for most document formats, yes.

Long answer: the current Patoline compiler produces binaries linked with a GPL-licensed library, and uses these binaries to output documents. This means that when distributing the binaries, you must respect the terms of the GPL. The documents produced, however, have no restriction on their license. Beware: in some cases, the binaries are the final production (such as in the case of webservers). In other cases though, the binaries produced by Patoline could produce source code for other binaries, that are only restricted by the licenses of their source code and linked libraries.

Can I use Patoline for a huge, ten years long project that I'm starting now?

Although one of the authors has written his PhD. thesis (120 pages, in computer science) with it, we don't recommend it now. The reason for this is that small adjustements and bugfixes are being made all the time, and working on such an unstable system can be frustrating. However, for documents that are not meant to last forever in time, we would be happy to help you with it: feel free to contact us for help.
Stay tuned: we do plan to release a long term supported version of Patoline soon.

Your code does not seem too documented, or does not respect good practice "x" of software engineering.

For most values of "x" that you have in mind, that is probably true, unfortunately. After two years and about 60.000 lines of OCaml code, Patoline is still under heavy development, simply because the task of writing and testing good foundational libraries such as font libraries, in a portable and safe way, is large. However:

• This does not mean that we don't plan to re-organize and document our code; we have already done it with each new order of magnitude in the size of our project.
• Languages with type inference and garbage collection (like OCaml) provide certain guarantees that probably make practice "x" less necessary to get a working program. But we will document our code, don't worry.

Where are you going with all this?

Our long term goal is to make it easy for anyone to quickly produce high quality documents. This is an ambitious goal, but we have made huge progresses towards it. This page lists some of our next projects:

Improving the language

We are currently developping a new parser, using a completely different parser generator. This is one of the main priorities, since we cannot really document a language bound to disappear in the upcoming months.

Making modularity apparent

Patoline is modular, even in its current version. However, all the modules are packed together in a giant single module, for historical reasons: the architecture was envisionned since the beginning, but we wrote the code with an actual document (a PhD. thesis) in mind.
It made us define and focus on the real problems that a typesetting system must solve, but had this drawback of producing monolithic code.
The next step is: unpack all the modules in module Typography, and rely on ocamlfind to solve the dependencies.

Modular configure

Patoline uses a new idea for its configure script: we wrote it in the same language as the code (OCaml). We must push this idea forward, and write configure scripts that can be stacked on top of each other. This would allow to compile several otherwise independent modules in just one command.
Moreover, it would make the production of distribution packages easy.

Faster typesetting algorithms

One problem with the current optimization algorithm is that it keeps recompiling old versions that have not been modified. Possible solutions include:

• an algorithm that keeps track of already optimized portions,
• a faster algorithm, removing unused branches early (e.g., useless hyphenations),
• draft versions based on the traditional Knuth and Plass algorithm.

If you want to learn more about Patoline, you can read:

• the current version of the Patobook,
• for developers, the generated API documentation.

Like many young projects, the authors focused less on documenting than on implementing new features. As a result, current documentation is in a bad state: while it can provide a good starting point, the Patobook is outdated on more advanced topics, while the API documentation lacks many descriptions. We are working hard on improving both resources.

In the meantime, the Patobook source itself, which can be found inside Patoline main repository, is a good example of a document built by Patoline.