Skip to main content

Text Highlighting in Latex

While preparing a manuscript with Latex, it is often useful to highlight the changes made in the current revision with a different color. This can be achieved using the \textcolor command provided by Latex. For example, \textcolor{red}{Hello World} would display the string "Hello World" in red color.

However, the final/published copy of the manuscript does not contain any highlighted text. Therefore, if a large volume of changes were made, it becomes tiresome at the end to find and remove all the individual portions of highlighted text.

This can be circumvented by defining a utility command to switch highlighting on and off as desired. In the following, we define a new Latex command, highlighttext, for this purpose. The command takes only a single argument -- the text that it should highlight.

    \usepackage{color}

        % For highlighting changes in this version with red color
    \newcommand{\highlighttext}[1] {\textcolor{red}{#1}}
    % Remove all text highlighting

    % Useful to generate the final version of the PDF
    %\newcommand{\highlighttext}[1] {#1}


In particular, the line

\newcommand{\highlighttext}[1] {\textcolor{red}{#1}}
indicates that when highlighttext is called with an argument, it will change the color of the argument (text) to red. Moreover, if we wish to change the highlight color from red to say, yellow, we only need to change the above line.

When review of the manuscript is over or, in general, when you do not require the highlighted text any more, simply comment out the above line, and uncomment the following:

\newcommand{\highlighttext}[1] {#1}

This version of the command signifies that whenever highlighttext is called with an argument, the argument (text) is returned as it is -- no processing (e.g., coloring) over it is done. Note that only one of these two command definitions should be enabled at any given time -- the other should be commented out.

What do you think of this technique? Did the pair of commands make text highlighting easier for you? Or do you use any better approach? Let the world know in the comments!

Comments

Post a Comment

Popular posts from this blog

Specifying Source and Destination of Messages

One of the frequently asked questions in the community is how to specify which particular nodes would act as source(s) and destination(s) of the messages created in the ONE simulator. The simulator, in fact, provides a pair of settings (shown below in bold face) aimed for this particular purpose.

Let us consider that there are $n + 1$ nodes in an OMN.  Further, let the nodes with addresses from $x$ to $y$, both inclusive, would create messages. The nodes in the range $w$ to $z$, both inclusive, would be the destinations of those messages, where $0 \le x \le y \le n$, and $0 \le w \le z \le n$. Then, the corresponding simulation scenario can be configured as follows.

## Message creation parameters # How many event generators Events.nrof = 1 # Class of the first event generator Events1.class = MessageEventGenerator # (Following settings are specific for the MessageEventGenerator class) # Creation interval in seconds (one new message every 25 to 35 seconds) Events1.interval = 25,35 # Me…

Effects of Buffer Size on Delay Tolerant Routing

In this post, we look at how buffer size affects, if at all, the performance of the routing protocols in DTNs. For this purpose, we will consider the following five routing protocols:
EpidemicPROPHETSpray-and-Wait (SnW) First Contact (FC) Direct Delivery (DD)  Detailed discussion of these protocols is scoped out here. We just note that in case of Epidemic, there is unlimited replication of the messages. In PROPHET, however, the replication is usually less than that of Epidemic. On the other hand, SnW has a fixed limit (L) on possible number of replications of a message. Finally, FC and DD involve message forwarding -- not replication. So, in the latter cases, there is always a single copy of any message in the DTN.

We will consider the buffer sizes from 20 MB to 180 MB, both inclusive, in steps of 20 MB so that we have total 9 different buffer sizes. We will use the real-life connection traces from Infocom'06. Therefore, we will need to simulate 5 * 9 = 45 scenarios to get the rel…

Controlling Transmission Range from within the Simulation

While simulating scenarios with the ONE simulator, one typically defines one or more network interfaces, and add them to the nodes as required. This use case prevails in most of the scenarios. However, a drawback here is that different network interfaces are mutually incompatible — an interface of type 1 can't communicate with any interface not of type 1.

Under certain circumstances, it might be required to control the transmission range of one or more network interfaces dynamically from within the simulation. For example, in one of my works, "On emotional aspects in Mission-Oriented Opportunistic Networks", I have considered the case where users occasionally turn off their device radios based on their contemporary emotions. In particular, the following shows how to set the radio range to 0: ModuleCommunicationBus comBus = host.getComBus(); // Store the original radio range the first time it is reset if (this.originalRadioRange == -1) { this.originalRadioRange = Double…