Among the features I’ve had the most requests for are the ability to add footnotes to documents, as well as custom page headers and footers. These are standard features of print-oriented word processors and many people naturally expect to find them in UX Write. So I thought I’d give an outline of my plans for supporting these. There’s some rather tricky issues involved due to the web-oriented nature of the app, but fortunately these are solvable.
WebKit for editing
UX Write actually doesn’t do any layout itself; it is entirely dependent on the WebKit rendering engine, as used in Safari and Chrome, for displaying all content. WebKit is based on HTML and CSS, the document structure and formatting languages of the web, which work somewhat differently to the file formats used by print-oriented word processors such as Microsoft Word and OpenOffice Writer. The differences — in particular, HTML’s continuous, non-paginated nature — have important implications for the feature set that is possible to support in UX Write.
Writing a (sufficiently capable) custom layout engine is a task that takes a sizeable team of people and many years of effort, which simply wasn’t a viable option for this app. Relying on WebKit makes it possible to invest all development resources entirely on editing capabilities, rather than all of the logic to calculate where each piece of text goes and how it’s formatted. This is why UX Write possesses so many more features than its competitors — all the hard work of layout is already taken care of. WebKit is also built in to iOS, which makes it a very convenient choice for use in an iPhone/iPad word processor.
By using WebKit, UX Write inherits both the capabilities and limitations of HTML. Although HTML has a lot of great features — styles, tables, images, lists, hyperlinks, and a ton of formatting options — it’s not particularly good at paginated, print-based output. On the web, there’s no notion of a document being divided into a series of (virtual or real) sheets of paper like in a traditional pure-WYSIWYG word processor. I’ve previously discussed why relying on explicit pagination during editing doesn’t make sense in the context of writing for e-books or the web, but it is relevant for documents that are ultimately destined for print output only. Unfortunately, among the features HTML lacks are — you guessed it — footnotes, headers, and footers.
Currently, UX Write uses WebKit for both editing and print/PDF output — but there’s some changes on the way for the latter.
LaTeX for printing
WebKit isn’t the only layout engine out there of course. Another popular one is Donald Knuth’s famous TeX typesetting engine, which was designed in the early 1980s for high-quality presentation of scientific and mathematical publications. It was later used by Leslie Lamport as the basis for LaTeX, a high-level set of macros for structuring documents that are ultimately typeset by TeX to produce printed output. I’ve used LaTeX for producing all of my academic publications (though doing my writing in LyX, a graphical front-end), and it’s pretty much the de-facto standard for academic publishing in computer science, mathematics, physics, and other scientific fields. After being around for more than 25 years, LaTeX is still regarded as one of the best quality typesetting engines out there.
LaTeX provides excellent support for print-oriented features such as footnotes, headers, and footers, plus many others such as page-number references and embedding of hyperlinks and outline navigation elements in PDF files. It’s a much better option than WebKit for generating print output, and making use of it in UX Write will make it possible to provide these features.
There’s one major problem with LaTeX however — it is only able to run in batch mode, and cannot provide real-time updates to the typeset document during editing, as WebKit can. What batch mode means is that a document is supplied to LaTeX, it goes away and does its thing, and then a few seconds later you get back a PDF file with the output. This means that it can only realistically be used for printing or exporting PDF files, and leaves us with WebKit as the only viable option for actual editing.
It’s always been a goal of mine to have built-in LaTeX support in UX Write. My hopes were initially dashed after I read about the immense difficulties the developers of Texpad had encountered while attempting a port to iOS due to the complexity of the codebase, however they eventually achieved success with a much simpler LaTeX distribution than that which is typically used on desktop systems. Upon learning of this I realised two things — that it is viable to do, and that I should work with them.
So LaTeX provides the solution to the problem of producing high-quality print output with all the layout features typically expected. However because getting this integration working is quite an involved task, I’m going to be doing it in two separate stages:
Stage 1 (soon): External typesetting
Initially, UX Write will provide an option to export the current document as a .tex file, which can either be converted to a PDF directly on your iPad or iPhone using Texpad, or on your desktop system using an existing LaTeX distribution such as TeX Live.
Installing and using LaTeX on a desktop system requires a fair bit of technical proficiency, and is something I only recommend for advanced users who are already familiar with the process. Texpad is a much easier solution, as it’s just as easy to install as any other iOS app, and will integrate seamlessly with UX Write. I’ve been working with the Texpad developers over the past couple of months on getting this integration working, and we’re getting fairly close to having it available.
Stage 2 (later): Built-in typesetting
Eventually, UX Write will contain a built-in version of LaTeX that it will run directly when you print or export to PDF. Everything will be done within the app, without requiring any third-party software, and it will be just as seamless and easy to use as the current print/PDF option. You won’t even realise there’s anything special going on behind the scenes.
Given that Texpad provides a very good solution to the problem, I’m going to be leaving this second stage until much later on, and focus on other features like find & replace, spell checking, EPUB support, and better file management over the next few months.
In summary
I know all this sounds awfully complicated — and, well, it is. I understand and sympathise with those of you who are waiting for these features and I’m just as keen as you are to have them in place. Unfortunately these things take a lot of time and effort — even Microsoft, with all the resources at their disposal, are at least 18 months away from having a working release of Word on the iPad, if recent rumours are to believed. The important thing to know is that I’m very much aware of the needs of professional writers and have a solid roadmap in place for the future of UX Write.
Peter, your original post barely brushed the title (footnotes, headers and footers) and you haven’t responded to any of the posts asking questions about footnotes, headers and footers. While, as a programmer, I appreciate the value of support for LaTex, can you answer at least some of the other responses and provide and some thoughts on when we’ll be able to see footnote, header and footer support in UX Write?
The value of LaTeX support is that it will make these things possible – HTML has no support for either of these three important features, and it’s impossible to do them in a web browser (or web browser layout engine such as WebKit, which is what UX Write uses).
The question of how to represent these features in a HTML file is an interesting one. One approach I’ve though of is to come up with a custom mechanism (i.e. one unique to UX Write) which would work for the cases of docx files (which could be translated appropriately behind the scenes to use this mechanism) and HTML files that are only edited in UX Write itself. However this solution would not provide interoperability with other HTML editors.
I recently became aware of O’Reilly’s work on HTMLBook (https://github.com/oreillymedia/HTMLBook), which is an attempt to standardise extensions to HTML that allow a program to store information about additional structural elements such as these. Unfortunately, while it does support footnotes, it doesn’t include any constructs for headers and footers. When time permits, I’m considering getting involved with the standardisation effort however, and this is one of the most important things I would suggest as an improvement.
With a lot of these features, the problem fundamentally arises from limitations in HTML. I picked this as the native file format for the app because of it’s standardisation, widespread support, and (most importantly) the ability to use an existing layout engine (WebKit) for displaying content; the project would not have been viable without the latter. However, this also means that anything which is a limitation of HTML is also a limitation of UX Write. The lack of these features is something that is common to all web browsers and web-based editing tools in general, not something specific to UX Write. And one of my priorities is to do things according to widely standardised file formats, rather than come up with a proprietary format which might include these extra features but would not be compatible with anything else.
I’m sorry if I’ve missed some of the posts – I thought I’d answered them all but I do get a *lot* of emails and occasionally I miss one here and there (my inbox went from 180 emails to 8 this evening). If you can point me to questions I’ve missed or have any others I’ll be happy to answer them.
Also with regards to timeframes – the most honest answer I can give you is that I don’t know. There’s a huge number of things on my to do list at the moment (one of which is spending a great deal of time on marketing, which I hate, but is unfortunately necessary to make this work as a viable business). I’ve recently had a couple of people start working with me and they’re currently about to begin implementation of ODF support; depending on priorities LaTeX may come after that, but it’s complex set of variables to evaluate.
I appreciate your frustration. All I can say is that I’m committed to getting this all in eventually, I just have to do what I can with limited resources.
Peter, sorry for the delay on responding to your invitation on my thoughts on a way to support endnotes/footnotes.
Right off the bat, I’ll admit your point about standards. They who create these things have not addressed the problem. And, in the meantime, I’ve found a relatively straightforward way to address the issue when I’m (semi-)manually setting html. The actual notes can be handled by inserting an ordered list () at the end of the document. I’ve found putting the ol in a div (with an appropriate class like “endnotes”) can be useful for css purposes. And, yes, someone is probably screaming about the excess markup as they read this.
I preface each endnote with two things. First, an anchor tag (e.g. ) that can be linked to. Second, a return tag (e.g. return) that can be hidden in print/pdf.
Within the text proper, the footnote/endnote number needs comparable tagging: a link, an anchor and superscript. So, 1
The one fly in the ointment is, of course, handling automatic renumbering. The ol/li approach solves that for the notes themselves. If a footnote was added/removed in the middle of the document proper, UXWrite would have to renumber the remaining ones below that.
Hopefully some variant of that seems like a workable solution until standards catch up.
OK, I am now impressed! This blog promises to solve in a serious way a serious interest that I have to be able to compose scientific docs on the iPad in ??? (UX Writer) and compile them on the desktop with LaTeX.
Certainly, I can get UX Writer, create the document on my iPad, export it as HTML to a Dropbox file, and do HTML -> LaTeX via a desktop converters. I understand converters can leave something to be desired.
So …
How soon to complete Stage 1 where UX Writer will output the document in a .tex format?
And dare I presume that, having a .tex output option in UX Writer means the user will have some backdoor to change how he/she wants to convert HTML5 some text to \texcommand{some text}?
Thanks!
I learnt a long time ago not to make promises on timeframes, as I inevitably end up not meeting them 🙂
LaTeX support is one of the many things on the to do list – and it’s an important one – but I’m not certain exactly when it will be done. Developer time is a problem right now, and I’ve just had two other people join the project to help me out who are working on ODF support. We may look at doing LaTeX next (there’s a partial implementation but not yet working properly).
Regarding customisation, I’m not sure at this stage, but I think there’ll need to be some options here, e.g. to tell it whether h1 should be \chapter or \section. This will require a lot of thought about how to do appropriately 🙂
Hi,
Do you have and integration with MathJax?? Based on HTML5 I can guess that it is possible to have such integration.
There’s no MathJax support, but we do plan on adding MathML support in a future version.
As much as I would like to see these features (and bibliographical references) integrated in UX Write, I can understand and agree with your will to do it right not just technically, but for the average end-user as well. The beauty of UX Write lies in his simplicity at tackling complex tasks left out by other iPad editors and I think it should remain this way.
For much of what I do, simple endnotes would be a great addition. I’d even settle for a way to fake; e.g. add anchors () and links to them (1) with either as a styling option or the ability to add arbitrary css key/value pairs to a style.
Hi Peter, Look forward to LaTeX integration in UX Write. But many TeX devotees (I know you’re one) would bridle at the suggestion that the installation of a TeX system on a desktop takes “a fair bit of technical proficiency”. On the Mac it takes just one download from tug.org/texlive/: installation is completely automated. Alas, it’s after the installation that “technical proficiency” becomes an issue. But, even without LyX props, I reckon you need no more markup skills than the Markdown kiddies have to produce beautiful things in, say, XeTeX..
Well, I was erring on the side of caution with that comment 😉
In general yes, it is relatively easy to set up, and like Linux, when it *does* work it’s great. But sometimes you can run into some issue or another that in order to solve you need a certain degree of understanding of how your OS configuration works (which many people lack), and I don’t want to be fielding support questions about that 😉 And things like having to do three separate runs of LaTeX to get all references & citations correctly displayed are a pain to deal with (I know there are tools to get around this but that’s another thing to deal with).
I’ve also encountered people who are violently opposed to LaTeX and command line interfaces, and want to take their needs into account as well. The Texpad/UX Write integration currently in beta works really smoothly and even someone without any knowledge of LaTeX or markup languages will find it seamless to use.