-
-
Notifications
You must be signed in to change notification settings - Fork 98
No. Forget TeX. We only mention TeX because that's the easiest way to explain to people what a typesetting engine is. SILE is a typesetting engine. It uses some of TeX's algorithms because they are the best way we know of to get computers to typeset. But it's not TeX.
The first thing that should be said is that if TeX works for you, use TeX. We don't see the need to take over the world. TeX has a lot of benefits including decades of work, community building and the CTAN code repository. TeX is great.
But there are some things where TeX doesn't do what you want, and since SILE is written in Lua, an interpreted language, it gives you the ability to make substantial changes to the underlying typesetting algorithms.
For document class and package authors, it also gives you the ability to write your class and formatting code in a high-level language, instead of grubbing around in TeX's macro language.
If you've never had to write a LaTeX package yourself, you probably won't find SILE interesting. And that's OK.
To a certain degree, yes, but whereas LuaTeX provides you with certain hooks to interact with certain parts of the system, the whole of the SILE typesetter is written in Lua and so can be interacted with. As an example, typesetting on a grid in TeX is a hard problem (ConTeXt solves some of it reasonably well, but will not give you flowed frame support) but it is a very simple package to implement in SILE.
The other compelling two features of SILE are its support for complex frame-based layouts - you can change how a page is laid out on the fly, creating columns, frames, insertions and so on - and the decoupling of the input format from the typesetting process; (you can't read TeX files without processing the macros) the practical effect of which is that you can feed SILE XML files and it will process them.
Yes, both in TeX-like format and in (as a subset of) MathML, although not all possible mathematical notations are implemented yet. See the documentation of the math package in the manual for more information.
Electronic publishing is definitely the way of the future, so this is an important question. It's certainly possible to create a package which replaces the print "outputter" with something which emits HTML instead of PDF. (It would probably need lots of monkey-patching into the insertion/headers/etc. classes too.)
But it would be like drilling a hole with a screwdriver. SILE is designed to implement the print part of production workflow; if you have a SILE document which needs to be transformed for electronic publishing, then something has probably gone wrong somewhere. Redesign your workflow so that you are authoring in a format that can be converted to HTML/EPUB, and then write SILE classes for that format.
There aren't classes for HTML/EPUB at the moment, and partly that's because I don't need them. It would not be hard to base something off the existing DocBook classes to cover the HTML element set. The biggest problem (as with all open source projects) is user expectation management - people would call you names if you didn't implement CSS, and the CSS Print Extensions, and there would be no end of it.
We wanted an interpreted language to allow for modifying the internals on the fly. Initial drafts were done in Javascript (and this can still be found in the repository history!) but Lua allowed for easier interface with external shaping and output libraries, and of course the fact that there is already a community of people messing about with typesetting in Lua is quite helpful.
Urgh! The space between lines is inconsistent!
Yes; I bet you never noticed that TeX does this too. Spacing between lines is governed by the descenders in the upper line, the value of the baselineskip and lineskip parameters, and the stretch value of the parskip parameter. If you want consistent interline spacing, you could set parskip's stretch component to zero; you could also try turning on grid typesetting.