0

Let me get straight to it: when writing a new document class, should I load fontspec and other packages which require LuaLaTeX and XeLaTeX?

Some context

When I was taught to use LaTeX, some 10-odd years ago, I was told to write diacritics using escape codes such as \^{a}-like commands. Very quickly I found out that was obsolete and that \usepackage[utf8]{inputenc} took care of the job.

Most LaTeX introductions don't tell you about LuaLaTeX or XeLaTeX or if they do, they treat it as a non-standard solution. In my opinion, that shouldn't be the case. In Portuguese, my mother tongue, we have few but constantly used characters which are not part of ASCII. So, when teaching newcomers to LaTeX, I always tell them to use Lua- or XeLaTeX.

I have never, however, taught how to write LaTeX document classes. I want to teach my students the best practices, so I'd like to know what the community thinks about this topic.

  • 2
    the future will probably be some combination of lua/xe tex but currently for example most journals accepting tex sources will only accept classic tex, so it depends what use your students need to make of latex. Unless your class actually requires luatex or xetex there is no need to make it fail with pdftex. – David Carlisle May 27 '17 at 22:18
  • 2
    inputenc should cover all Portuguese needs I would think? If you were using cjk or indic scripts with complicated text requirements then the arguments for not supporting 8-bit tex are much stronger. – David Carlisle May 27 '17 at 22:22
  • While inputenc is enough for Portuguese, fontspec is a great way of changing fonts. Much less complicated than the old ways. I want my students to be able to create classes for with custom fonts very easily. – rberaldo May 27 '17 at 22:44
  • 1
    In my opinion, LaTeX beginners should not write new classes. Classes are for reuse by others and a beginner does not (yet) have the knowledge to provide quality work. – Johannes_B May 28 '17 at 5:57
  • 1
    If possible I write classes for both engine types. E.g. with \sys_if_engine_pdftex:TF{code for pdflatex}{code for luatex/xelatex} – Ulrike Fischer May 28 '17 at 8:37
4

Classes and packages should usually be engine/font/encoding agnostic

I think there's something being missed here. By and large neither classes nor packages should make any assumptions with either font or input encodings or engine unless absolutely needed; this should almost always be left to the document level. A class is usually used to set up some particular document type: the layout of the pages, section headings, etc. A package adds a particular functionality to documents of any class, usually. Of course one can find exceptions to this general rule (see below for some examples). Neither needs to assume properties of the fonts or engines.

Classes and packages should similarly not assume a particular language is being used, and should therefore leave loading babel or polyglossia to the user as well.

It's one thing to teach students to use XeLaTeX or LuaLaTeX as their main engine for their day to day documents (which indeed does make font handling easier) but an entirely different thing to teach them that classes or packages they write should include engine dependent code. This is teaching them bad practices.

When might a class or package require engine specificity

There are obviously certain times at which it makes sense for a class or package to assume an engine or font setup.

  • packages that require Lua code and will only run with LuaTeX
  • packages that require XeTeX specific functionality (e.g., XeTeXinterchartoks)
  • classes that reproduce a particular form with a specified font

These are very specialized uses, and unlikely to be the thing that beginners are ever likely to do.

  • I don't think it was really missed. I took it to be David's point ;). – cfr May 28 '17 at 20:42
  • @cfr I was referring to the now deleted summary and to the question itself. – Alan Munn May 28 '17 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.