8.3 Producing (fairly) portable line graphics
If we take a very conservative and narrow point of view, then fully portable graphics in LaTEX are only those that are built from boxes, lines, and characters (i.e., standard LaTEX’s picture environment), because everything else requires some backend functionality that may not be available in all situations.
However, these days certain graphic functions are available across virtually every backend (even though sometimes with different implementations and interfaces). It is therefore legitimate to consider packages that build upon a restricted set of those (and hide the implementation details from the user) as being portable for all practical purposes. Such a package is pict2e, a reimplementation and extension of LaTEX’s picture environment functionality using backend features for better quality. This is followed by a brief discussion of bxeepic, which is a reimplementation of the original epic (the first attempt to improve on LaTEX’s picture environment in a portable way). We finish the section with a package that can produce only one type of graphics: QR-codes for use with mobile devices.
8.3.1 A kernel picture environment enhancement
According to the LaTEX manual, picture mode coordinates are multiples of (default value 1pt), i.e., you had to write (2,3){…}. This allows easy scaling of pictures by changing the value of , but makes it fairly complicated to base coordinate values on real dimensions, e.g., solving tasks such as “put this object at 2⁄3 of the ”.
In 2020 the LaTEX kernel was therefore extended1 to also support length expressions as coordinate values, which allows you to write things like
8.3.2 pict2e - An extension of LaTeX’s picture environment
Standard LaTEX’s picture environment was originally designed in the mid-eighties to be fully independent of any particulars of the final output device, and to achieve this it drew the graphics using characters taken from special fonts (containing line segments at various angles, etc.). In other words, for TEX a line-graphic was reduced to the question of typesetting and positioning “characters”, something that is well understood by the engine.
The downside is obvious: with fonts containing small part of the graphics as characters, only a restricted set of graphics can be drawn. Lines and vectors were available in only a small number of angles, circles could be drawn in only a few discrete sizes, etc.
The following example exhibits some of these limitations. Here, the circle and disk on the left are too small (without producing any warning), and the commands produce errors because the required slope is not available. Compare this result to Example 8-3-2, which shows the correct output — it is strikingly different.
8.3.3 bxeepic - A differently enhanced picture environment
Standard LaTEX’s picture environment (especially in conjunction with the pict2e reimplementation) allows you to generate line-style graphics of arbitrary complexity through basic commands for drawing lines, vectors, quarter-circles, and Bézier curves. However, creating complex graphics, although possible, requires a lot of manual effort. Most of its picture-drawing commands require explicit specification of coordinates for every object, which makes alterations later very difficult.
Given that the basic command had several drawbacks and was very non-intuitive to use, people started early on to develop alternatives. One of the most successful and influential packages back then was epic by Sunil Podar, which provided a powerful high-level user interface to the picture environment [166]. Its main aim was to reduce the amount of manual calculations required to specify the layout of objects. In this way, the epic package made it possible to produce sophisticated pictures with less effort than before even though it inherited the restrictions of the original picture environment commands.
As a result, some of the functions took a long time to complete, or the output was not of very high quality. This situation improved with the eepic package, written by Conrad Kwok, which is an extension of both LaTEX and epic. It overcame most of the limitations by using
commands for drawing that were understood by only some output devices.
In short, it traded device independence for better-looking output, but given that dvips, the predominant output device in the nineties, supported these
commands, it was often used for high-quality line graphics. However, when pdfTEX started to become popular and people used that program to produce PDF directly, the situation changed once more, because eepic stopped working in this workflow.
In 2010 YATO Takayuki then provided a new implementation of most of the epic commands in a package called bxeepic, this time using pict2e as the underlying interface. While his implementation does not cover all of the features of epic and eepic, it is complete enough so that you will seldom find old documents using the original packages that cannot be processed by exchanging them with the new package. In fact, when loading bxeepic, the packages epic and eepic are both marked as “already loaded”. Thus if your document later loads another package that itself requests, say, epic, it does not replace the improved versions with epic’s original code.
The remainder of this section gives you an overview of the most useful commands of the bxeepic package. There are a number of other special features not discussed, but if you have needs that go beyond simple line drawings, it is better to switch to a full-blown graphic system that can be used with LaTEX such as tikz [189] discussed in Section 8.5 on page 631.Standard LaTEX’s picture environment (especially in conjunction with the pict2e reimplementation) allows you to generate line-style graphics of arbitrary complexity through basic commands for drawing lines, vectors, quarter-circles, and Bézier curves. However, creating complex graphics, although possible, requires a lot of manual effort. Most of its picture-drawing commands require explicit specification of coordinates for every object, which makes alterations later very difficult.
Given that the basic command had several drawbacks and was very non-intuitive to use, people started early on to develop alternatives. One of the most successful and influential packages back then was epic by Sunil Podar, which provided a powerful high-level user interface to the picture environment [166]. Its main aim was to reduce the amount of manual calculations required to specify the layout of objects. In this way, the epic package made it possible to produce sophisticated pictures with less effort than before even though it inherited the restrictions of the original picture environment commands.
As a result, some of the functions took a long time to complete, or the output was not of very high quality. This situation improved with the eepic package, written by Conrad Kwok, which is an extension of both LaTEX and epic. It overcame most of the limitations by using
commands for drawing that were understood by only some output devices.
In short, it traded device independence for better-looking output, but given that dvips, the predominant output device in the nineties, supported these
commands, it was often used for high-quality line graphics. However, when pdfTEX started to become popular and people used that program to produce PDF directly, the situation changed once more, because eepic stopped working in this workflow.
In 2010 YATO Takayuki then provided a new implementation of most of the epic commands in a package called bxeepic, this time using pict2e as the underlying interface. While his implementation does not cover all of the features of epic and eepic, it is complete enough so that you will seldom find old documents using the original packages that cannot be processed by exchanging them with the new package. In fact, when loading bxeepic, the packages epic and eepic are both marked as “already loaded”. Thus if your document later loads another package that itself requests, say, epic, it does not replace the improved versions with epic’s original code.
The remainder of this section gives you an overview of the most useful commands of the bxeepic package. There are a number of other special features not discussed, but if you have needs that go beyond simple line drawings, it is better to switch to a full-blown graphic system that can be used with LaTEX such as tikz [189] discussed in Section 8.5 on page 631.
8.3.4 Special purpose languages
Building on LaTEX’s picture environment, possibly extended with a package such as epic, eepic, or bxeepic, several package authors have implemented high-level user interfaces intended to make entering graphical information more straightforward and less error prone by adopting a syntax that is more familiar to the end user in a particular application domain. Some of the systems are quite complex (the LATEX Graphics Companion [55] describes several of them in detail). In this section we merely give a flavor of what is possible in this area by showing one example from the XΥMTEX bundle by FUJITA Shinsaku for drawing chemical diagrams (see [50, 51] or [55, Chapter 6]).
By using command names inspired by standard nomenclature known to practitioners in the field, complex formulas can be entered simply. In the following example, we use the hetarom subpackage, designed for specifying the structure of vertical heterocyclic compounds.
8.3.5 qrcode - Generating Quick Response codes
Today’s use of smartphones and tablets has given rise to a widespread appearance of Quick Response (QR) codes. These are very special graphics used to encode arbitrary information into a square matrix of black and white pixels. You scan such a QR code with your mobile device camera, and it shows you the encoded data and— if recognized — offers to process it, e.g., open a hyperlink in the smartphone browser.
While QR codes can encode any type of information up do several kilobytes, the most common usage is to provide easy access to hyperlinks. Try it out with your smartphone on the example below: the first QR code should take you directly to the publication page of the LaTEX Project website, the second could have been made by a modern Lord Peter Wimsey, and the third is Miss Vane’s answer in draft mode.