# Some TeX Developments

Coding in the TeX world

## Customising TeXworks auto-completion

TeXworks is a very flexible editor, and one of the things you can customise, if you want, is the set of auto-completion values it knows. For those of you who are not familiar with it, TeXworks uses a simple list of simple completion options, so when I type

\doc


I can press the Tab key and be offered

\documentclass{}


and if I press Tab again,

\documentclass[]{}


That’s very useful, but some of the auto-complete options are not ones I use a lot. There are also a few inconsistencies in how the results are formatted: while TeXworks inherited a basic set from TeXShop, it also comes with some additions and they don’t always quite agree on how things should work! So I’ve been looking a bit at sorting out my own custom set, adding things I use, removing ones I don’t and so on.

The basic format for the auto-complete files is to have a first line for the encoding

%% !TEX encoding = UTF-8 Unicode


then one or more lines for each completion. Each line can either just have a completion vale

\alpha


or have a ‘shortcut’ text version

xa:=\alpha


There are then a few bits of ‘helper’ syntax. You can use #INS# to show where the cursor should end up, #RET for a return and • as a marker you can jump to using Ctrl-Tab (Option-Tab on the Mac). So for example the \documentclass lines read

\documentclass{#INS#}#RET#
\documentclass[#INS#]{•}#RET#


I’m told that TeXShop has extended the syntax a bit, but at least at the moment in TeXworks that all there is to know.

So what have I done to customise the files? TeXworks comes with four auto-complete files, but the values offered simply come from them all together (you can’t currently select only some files). (You might wonder where these files live: they are ‘hidden away': TeXworks will tell you how to find them from Help -> Settings and resources.) So my first move was to create one new file, after first backing up the originals of course! I then did a few experiments, thinking about what I use a lot, what I’m used to, etc. I did wonder about some of the choices in the standard files, but a bit of experimentation suggests they are not so bad! So I’ve currently ended up mainly just adding a few things, for example

{tikzpicture}[#INS#]#RET#•#RET#\end{tikzpicture}•


for TikZ pictures and

cs:=\cs{#INS#}
pkg:=\pkg{#INS#}
\cs{#INS#}
\pkg{#INS#}


for package development work. I’m also not too keen on having too many of the ‘shortcut’ values, which don’t start \, so I’ve removed most of them and have just a core set (things like bf and em). If you want to see my current full set, you can of course download it.

So is there anything I’d like to see added to the way auto-complete works? I have a few ideas! From my questions on the TeXworks mailing list, I’ve picked up that TeXShop maintains indentation when doing auto-complete: TeXworks doesn’t, and I think it would be a good addition. TeXShop also allows an extended syntax

\documentclass[#INS#•#INS#]{•}#RET#
\rule[#INS#•‹lift›#INS#]{•‹width›}{•‹height›}


where you can always have a • for ‘fill in’ and have ‘reminders’ about what the values are. That looks useful too.

Written by Joseph Wright

September 1st, 2013 at 9:45 am

Posted in TeXworks

## TeX Live 2013 released

with one comment

Browsing the TeX Live site today, I see that TeX Live 2013 has been released. There are as usual a few changes to note. My highlights:

• XeTeX now uses the HarfBuzz shaper rather than the older ICU engine (which is no longer being developed): see my earlier post about this change
• LuaTeX is updated to Lua 5.2 (the latest Lua release)
• Microtype now supports protrusion in XeTeX and LuaTeX

I’ve been using the pretest version of TeX Live for a while, and am very happy that all seems to be working just fine. Of course, many people will want the DVD version, which will be a while, but for the downloaders you can grab it now.

Written by Joseph Wright

June 18th, 2013 at 8:27 pm

Posted in General

Tagged with

## A talk in Paris

Yesterday I was in Paris, giving a talk to GUTenberg about LaTeX3 as part of their user meeting. The event was very well attended, and ‘official’ video recording will be available of all of the presentations. People seem very keen to hear talk I was giving, so I recorded the audio and have put it together with the slides as a video (thanks to UK-TUG for use of their Vimeo account!). I do hope it all makes sense!

Written by Joseph Wright

June 2nd, 2013 at 5:04 pm

Posted in LaTeX3

## TeX Welt: A new (German) TeX blog

If you are involved in (La)TeX for any length of time, you notice that using TeX is very popular in German-speaking countries. DANTE, the German-speaking TeX user group, is big, and there are several German-language TeX websites out there. They’ve now been joined by a new German-language TeX blog, TeX Welt. This has popped-up following some discussion on the TeX-sx chat system, and is being hosted by Stefan Kottwitz (a man with a server farm in his house!). Of course, we don’t all speak fluent German, but I’ll certainly be keeping an eye on the new site: always more to learn!

Written by Joseph Wright

May 27th, 2013 at 7:27 pm

Posted in General

## Keeping track of changes

Moving my code from BitBucket to GitHub has shown me (once again) the need to keep my changes to my code very organised. There was quite a bit of work to do getting all of the issues migrated, and it wasn’t helped by the fact that I’ve been less than perfect in keeping each commit I make focussed on one thing. A timely reminder that it’s important to be careful if you write a lot of code.

Written by Joseph Wright

May 25th, 2013 at 10:27 pm

Posted in General

## Moving from Mercurial to Git

Over the years of working with LaTeX, I’ve picked up a bit about version control systems for code: this post is more about general programming than TeX.

I started out with Subversion, then moved to Mercurial when I got involved in beamer maintenance. The idea is the same whatever system you are using: by keeping a track of changes in the code you help yourself in the long term, and make it easier for other people to help too. Mercurial is one of several ‘distributed’ version control systems (DCVS) that have been developed over the last few years. The idea is that each ‘repository’ (copy of the code) has the history with it, and so is independent of any server. You can still send your changes to a server, and that is very popular, but you don’t have to. Sending code to a public server makes it easy to let other people get involved, report issues and so on, and there are lots of sites that will help you do this.

I picked Mercurial over the other leader, Git, mainly because the other guy involved in looking after beamer went this way and put the code on BitBucket. At the time, BitBucket did Mercurial while GitHub did Git. BitBucket changed hands a little while ago now, and they brought in Git support. They’ve now moved to make Git the ‘standard’ repository type. That tells me that Git is likely to ‘win’ as the most popular DCVS (it’s looked that way for a while), and so it’s time to reconsider my use of Mercurial.

It turns out that moving from Mercurial to Git is pretty easy: there is a script called fast-export that does the job. Converting the code itself is therefore easy: run the script (you need a Unix system, so on Windows I’m using a virtual Ubuntu machine with VirtualBox). Life gets a bit more interesting, though, if you want to keep your issues database. BitBucket does offer issue import and export, but no easy way to convert from Mercurial to Git. At the same time, the way that the two systems refer to individual commits means that if you don’t edit your issues, any links to the commits will be messed up. That means that its as easy to move to GitHub as it is to stay on BitBucket. So that’s what I’ve decided to do (GitHub is pretty popular with other LaTeX developers). I’m working through my repositories, converting to Git and uploading to GitHub, then copying the issue information by hand and doing minor edits. That includes making sure that I keep the links which show how I fixed things. Apart from siunitx, my packages don’t have a lot of issues (no more than a dozen each), so I can do that by hand without too much work. I’d a bit surprised no-one has written a script to do this, but at least it will not take too long. I’d expect everything except siunitx to be moved by the weekend, and even this ‘big job’ to be done within a couple of weeks.

Written by Joseph Wright

April 25th, 2013 at 9:08 am

## XeTeX 0.9999: Moving to HarfBuzz (and lots of other goodies)

Khaled Hosny has announced on the XeTeX mailing list that XeTeX 0.9999 has just been released. The list of changes is pretty long, as XeTeX has had quite a backlog of issues. Probably the biggest single change is

Port OpenType layout from ICU LayoutEngine to HarfBuzz. HarfBuzz is actively maintained and generally have much wider support for
OpenType spec, the switch fixes a number of OpenType bugs:

• Support version 2 OpenType Indic specs.
• Many other Indic OpenType bugs, and support for the latest additions to OpenType spec.
• Incorrect application of contextual features.
• Incorrect kerning in fonts that has both old “kern” table and new GPOS “kern” feature.
• Allow suppressing Latin ligatures with ZWNJ.
• Support for variation selectors.
• Support for user-specified features with complex scripts.

If you are familiar with layout engines, you’ll know that while ICU has worked very well for XeTeX from day one, it’s no longer being developed while HarfBuzz is being developed. More importantly, HarfBuzz is supported by the open source community well beyond the TeX world, so by moving in this direction XeTeX gets the benefits of the efforts of many other people: part of the point of open source software. I’m sure it’s been a big effort making this change: I’m looking forward to testing it out.

The other headline change, at least for Mac users, is moving to Core Text rather than ATS/ATSUI. Apple have dropped support for the latter, so there was a worry about building XeTeX on the Mac in the future. That’s now sorted, and means XeTeX should work as a 64-bit application on the Mac in future.

If you read the full announcement you’ll see there are lots of other changes and bug fixes. Congratulations to Khaled on this: it’s great to see that XeTeX continues to develop, and that several features have been added to make working with XeTeX and LuaTeX seamlessly are now there.

Written by Joseph Wright

March 12th, 2013 at 9:01 am

Posted in General

Tagged with ,

## LaTeX Online: Options continue to grow

The idea of using ‘The Cloud’ for working with documents is very much on the rise. For collaborative work, particularly with less-experienced users, the idea of leaving things like version control ‘built in’ is very attractive. This approach is also a good way to use LaTeX on portable devices, where installing a TeX system may be tricky.

There are now several online services, all of which seem to offer a core set of idea (an editor, previewer and TeX system for compiling, and almost certainly version control). Keeping up with the different services is tricky: I’ve come across

All of them offer those core services, and some advertise other goodies such as DropBox integration (SpanDeX does).

What people want to know is probably ‘which service is best’. Some of these have been round for a little while now, but none can claim a long history, so at the moment there’s probably no one clear leader. Not everyone will be comfortable with an online service: letting other people store your data is not something that’s risk-free, while if you want the latest version of every package you use, you’re likely to need to have your own set up.

I’d love to hear people’s experiences of these services: my colleagues don’t use LaTeX, so I don’t have the opportunity to test out the big ‘selling points’ of these sites.

Written by Joseph Wright

February 24th, 2013 at 5:46 pm

Posted in LaTeX

Tagged with

## Extending biblatex to support multiple scripts

As regular readers will know, I’ve taken an interest in biblatex since it was first developed. Since the original author disappeared, I’ve been at least formally involved in maintain the code. So far, that’s been limited to tackling a few tricky low-level TeX issues, but there are some bigger issues to think about.

Philip Kime, lead Biber and biblatex developer, is keen to extend the LaTeX end to supporting multiple scripts. The Biber end is already done (in the ‘burning edge’ version), and writes to the .bbl file in the format:

 \field{form=original,lang=default}{labeltitle}{Title}
\list{form=original,lang=default}{location}{1}{%
{Москва}%
}
\list{form=romanised,lang=default}{location}{1}{%
{Moskva}%
}


However, that presents a big issue: how to do that without breaking every existing style. Supporting scripts means we need an additional argument for a very large number of commands: some of them need to have two optional arguments, and some of them need to be expandable:

\iffieldundef[form=original,lang=default]{....}


Reading (two) optional arguments and working through keyval options expandably is tricky, which is where I come in. The natural way for me to solve the first problem is to use LaTeX3, and the xparse package. However, that’s a big change for biblatex, so before I (and the rest of the biblatex team) go for this I though it would be worth raising the issue and looking for opinions. The alternative is to write the code into biblatex directly, but it’s complicated and as I’ve already done the job once I’m reluctant to do this!

So, what I want to know is ‘What do users think?’ Is it reasonable to require xparse as part of biblate

Written by Joseph Wright

February 10th, 2013 at 11:45 am

Posted in biblatex,LaTeX

Tagged with

## Clipping support in XeTeX

Clipping boxes is something that TeX does not do: it simply places them on the page. That means that clipping graphics (a pretty common requirement) is actually done by the driver rather than by TeX. The LaTeX graphics package and the driver support that come with it cover quite a lot of cases, and over the years support for a number of other drivers have been written based on the same ideas. However, things are still not 100% identical over all back-ends. A particular gap at the moment is that that XeTeX support code does not offer clipping, because the XeTeX engine does not do this (pdfTeX and LuaTeX both do). Users of pgf might have noticed that it manages to do clipping perfectly happily with XeTeX (or rather they might have wondered why graphics doesn’t when pgf does). Martin Scharrer and I looked at this a while ago for his adjustbox package, and worked out what is actually needed: some PostScript specials in a xdvipdfmx wrapper. The same basic idea is now being integrated into xetex.def, the driver support code used by graphics`. This will go to CTAN soon, but some testing would be good. The updated file is available now, so I’d encourage intrepid readers to download and test it!