After a bit of a hiatus, I’ve got back into fixing the bugs in
beamer, starting with some ‘low hanging’ ones and scheduling a few more. Hopefully there won’t be too many new issues as a result, but if there are then please log them!
The LaTeX Project have been making efforts over the past few years to update support in the LaTeX2e kernel for XeTeX and LuaTeX. Supporting these Unicode-enabled engines provide new features (and challenges) compared to the ‘classical’ 8-bit TeX engines (probably pdfTeX for most users). Over recent releases, the team have made the core of LaTeX ‘engine-aware’ and pulled a reasonable amount of basic Unicode data directly into the kernel. The next area we are addressing is font loading, or rather the question of what the out-of-the-box (text) font should be.
To date, the LaTeX kernel has loaded Knuth’s Computer Modern font in his original ‘OT1’ encoding for all engines. Whilst there are good reasons to load at least the T1-encoded version rather than the OT1 version, using an 8-bit engine using the OT1 version can be justified: it’s a question of stability, and nothing is actually out-and-out wrong.
Things are different with the Unicode engines: some of the basic assumptions change. In particular, there are some characters in the upper-half of the 8-bit range for T1 that are not in the same place in Unicode. That means that hyphenation will be wrong for words using some characters unless you load a Unicode font. At the same time, both LuaTeX and XeTeX have changed a lot over recent years: stability in the pdfTeX sense isn’t there. Finally, almost all ‘real’ documents using Unicode engines will be loading the excellent
fontspec package to allow system font access. Under these circumstances, it’s appropriate to look again at the standard font loading.
After careful consideration, the team have therefore decided that as of the next (2017) LaTeX2e release, the standard text font loaded when XeTeX and LuaTeX are in use will be Latin Modern as a Unicode-encoded OpenType font. (This is the font chosen by
fontspec so for almost all users there will no change in output.) No changes are being made to the macro interfaces for fonts, so users wanting anything other than Latin Modern will continue to be best served by loading
fontspec. (Some adjustments are being made to the package to be ready for this.)
It’s important to add that no change is being made in math mode: the Unicode maths font situation is not anything like as clear as the text mode case.
There are still some details being finalised, but the general approach is clear and should make life easier for end users.
On Windows, users have two main choices of TeX system to install: TeX Live or MiKTeX. I’ve looked at this before a couple of times: first in 2009 then again in 2011. Over the past few years both systems have developed, so it seems like a good time to revisit this. (I know from my logs that this is one of the most popular topics I’ve covered!)
The first thing to say is that for almost all ‘end users’ (with a TeX system on their own PC just for them to use), both options are fine: they’ll probably notice no difference between the two in use. It’s also worth noting that there is a third option: W32TeX. I’ve mentioned this before: it’s popular in the far East and is where the Windows binaries for TeX Live come from. (There’s a close relationship between W32TeX and TeX Live, with W32TeX more ‘focussed’ and expecting more user decisions in installing.)
Assuming you are going for one of the ‘big two’, what is there to think about? For most people, it’s simply:
- Both MiKTeX and TeX Live include a ‘full’ set of TeX-related binaries, including the engines pdfTeX, XeTeX, LuaTeX and support programs such as BibTeX, Biber, MakeIndex and Xindy.
- The standard installer for MiKTeX installs ‘just the basics’ and uses on-the-fly installation for anything else you need; the standard install for TeX Live is ‘everything’ (about 4.5 Gb!). Which is right for you will depend on how much space you have: you can of course customise the installation of either system to include more or less of the ‘complete’ set up.
- MiKTeX has a slightly more flexibly approach to licensing than TeX Live does: there are a small number of LaTeX packages that MiKTeX includes that TeX Live does not. (Probably the most obvious example is
- TeX Live has a Unix background so the management GUI looks slightly less ‘standard’ than the MiKTeX one.
- TeX Live has a strict once-a-year freeze,which means that to update you have to do a fresh install once a year. On the other hand, MiKTeX versions change only when there is a significant change and otherwise ‘roll onward’.
So the decision is likely to come down to whether you want auto-installation of packages. (If you do go for MiKTeX on a one-user PC, choose the ‘Just for me’ installation option: it makes life a lot simpler!)
For more advanced users there are a few more factors you probably want to consider
- TeX Live was originally developed on Unix and so is available for Linux and on the Mac (and other systems) as well as Windows; MiKTeX is a Windows system so is (more-or-less) Windows-only. So if you want exactly the same set up on Windows and other operating systems, this of course means you need to use TeX Live.
- Both systems have graphical management tools as well as command line interfaces. They have a lot in common, but they are not identical (in particular, MiKTeX tends to emulate TeX Live command line interfaces, but the reverse is not true).
- The engine binaries in TeX Live are (almost) never updated other than in the yearly freeze period, meaning that for a given release you know which version of pdfTeX, etc., you’ll have: MiKTeX is more flexible with such updates. (At different times, one or other of the systems can be more ‘up to date’: this is not necessarily predictable! The W32TeX system often has very up-to-date testing binaries.)
- The two systems differ slightly in handling how local trees are managed (places to add TeX files that are not controlled by the TeX system itself). TeX Live automatically expects
<installation root>/texmf-localto hold system-wide ‘local’ additions and
<user root>/texmfto hold per-user additions, whereas MiKTeX has no out-of-the box locations, but does make it easier to add and remove them from the command line. MiKTeX also makes it easy to add multiple per-user trees, whereas for TeX Live there’s more of an assumption that all user additions will be added in one place. (This makes it easier in MiKTeX to add/remove local additions by altering a setting in the TeX system rather than deleting files.)
- TeX Live has a team doing the work; MiKTeX is a one-man project. This cuts both ways: you know exactly who is doing everything in MiKTeX (Christian Schenk), and he’s very fast, but there is more ‘spread’ in TeX Live for the work.
- For people wanting to step quickly between different versions of TeX system, the fact that TeX Live freezes once a year makes life convenient (I have TeX Live 2009,2010, 2011, 2012, 2013, 2014, 2015 and 2016 installed at present, plus MiKTeX 2.9 of course!) You can switch installations by adjusting the
PATHor by choosing the appropriate version from your editor, so have a ‘fall back’ if there is an issue when you update.
- TeX Live has build-in package backup during maintenance updates.
As I’ve just moved where the blog is hosted it seemed like a good opportunity to do a bit of tidying up. Regular readers will notice that the categories have been updated, hopefully making it easier to find things. Suggestions on any new arrangements are welcome. I’ve also fixed a few missing files in older posts (the odd re-install means that not 100% of the older content is right!). I’ve also revised the static pages (About, Packages and Contact) to make sure they are up to date: the package list and my PGP key are now right! At the ‘back end’, I’ve adjusted a few WordPress plugins and generally made sure everything is as organised as it should be. I’ve also tweaked a few parts of the layout, including adding the very-commong ‘quite share’ buttons. So hopefully the blog is tuned up for the future!
A rare foray outside of the strictly TeX-related: as it’s about the blog itself I think its OK! As you might notice on visiting the site, I’ve enabled https for the site. Why have I done that? Well, if you read the WordPress News it’s clear that they are pushing toward more use of secure access. (As you might guess, the back-end for the blog is WordPress.) There are wider moves toward ‘https everywhere’, so it seemed like as good a time as any to do the work.
For readers, there should be no change at all in the site. For those interested in the detail, I’ve moved the hosting to SiteGround as they offer Let’s Encrypt: a free SSL certificate system suitable for small-scale sites like this one. (If anyone is feeling particularly generous, I’ve got a referral URL which will give me some free service in return for pointing to my new host!) The process was largely trouble-free: I’ve taken the opportunity to re-build the site from scratch (just using the dumps of the content) and to remove some older ‘back-end’ rubbish (old plugins and the like). Again, for readers this should be transparent!
There’s been some recent discussion on the TeX Live mailing list about recording dependencies for (La)TeX packages. This is a good idea but means that package authors need to think about their dependency situation. So I thought a few words on this would be helpful, at least from the point of view of the most common case: LaTeX packages.
It’s pretty easy to accumulate
\RequirePackage lines in your source, but if you are serious about giving a useful set of dependencies you need to know what each one is for. In many ways the rule is easy: require each package you use. What makes that more complicated is that you might use features which are available when you load package X but are actually provided by package Y. For example, if you load my
siunitx package, it loads
array so means that you can do for example
So how do you tell what your ‘real’ dependencies are? The usual rule is that you check the documentation: does it say that package X itself provides the features you use? In the case above,
siunitx doesn’t document that syntax extension for
tabular: it’s documented by
array. So if you wrote a package that uses
siunitx but also needs to use features from
array you should
This means that even if at some future stage there’s a change in the internals of a package you load, things should still all work.
If you want to track down where stuff might be coming from, you can always
\listfiles to get a full overview of your current package use (starting from a small example).
There are a few places were packages are so closely linked you might not have to list them both. The most obvious is TikZ/
pgf: the two are different ‘layers’ of the same set up but are documented together, so if you load TikZ you can assume
pgf. Of course, there is no harm in listing both!
There are lots of places one can host development of open source code. I’ve used a few over the years, but in recent times have mainly focussed on GitHub. That’s true not least because the LaTeX3 development code is held there. The one package I’m involved in that’s to-date been elsewhere has been
beamer: there are lots of issues in the tracker which I didn’t want to lose. So for some time it’s been slightly orphaned on BitBucket. I’ve now (finally) been able to migrate everything using a very handy script maintained by Jeff Widman. I’m making final arrangements on the move, but the key is that new issues should to to GitHub.
LaTeX2e was released in 1994 and since then the LaTeX3 Project have been committed to keeping it working smoothly for users. That means balancing up keeping the code stable with fixing bugs and adding new features.
Back in 2003 the team announced that the e-TeX extensions would be used by the kernel when they were available. The new primitives offered by e-TeX make many parts of TeX programming easier and often there’s no way in ‘classical’ TeX to get the same effect. As e-TeX was finalised in 1999, starting to use it seriously in around 2004 meant most people had access to them.
Since then, the availability and use of e-TeX has spread, and almost all users have them available. Indeed, the standard format-building routines for LaTeX have included them for many years. There are also a lot of packages on CTAN that use e-TeX, most obviously any using the
expl3 programming language that the LaTeX3 Project have created.
The team had always meant to say at some stage that e-TeX was now required, and indeed thought we had until I checked over the official newsletters! So as of the next LaTeX2e release, scheduled for the start of 2017, the kernel will only build if e-TeX is enabled. For this release, we are likely to add a test for e-TeX but no actual use directly in the kernel, though in the future there will probably be more use of the extensions.
I wrote recently abut the need to manage
biblatex back-ends, and thoughts the maintenance team had on which way to proceed.
After a bit of thought, we’ve gone for a solution we hope works for users and for us. Reversing what seemed like a ‘good idea at the time’, we’ve re-integrated (almost) all of the TeX code into one pathway. This is focussed on Biber, but we have a small stub that converts the relevant parts to work with BibTeX. So users how don’t need Biber or can’t use it can still use BibTeX and get mainly the same results.
There are a few changes, mainly related to places where BibTeX and Biber had ended up with different interfaces and where BibTeX can’t (reasonably) support the Biber one. In those places we’ve dropped the ability to use a ‘BibTeX alternative pathway’ as it makes the code complex and makes switching between back-ends tricky.
Hopefully the balance we’ve gone for will work for everyone: you can still use BibTeX, it still does almost everything it always has with
biblatex, but we’ve got a more sustainable code base for the future.