General

Is LTC the same as Track Changes in Microsoft Word?

No. LTC was inspired by the general capability of Word to track changes. However, we made a few conscious design choices that sets LTC apart from track changes in Word. The most important difference is that the author does not have to accept or reject changes. Also, the author does not have to turn the feature on or off in order to track changes. He or she, however, has to create a history of the document by committing versions of the file to a version control system. To date, we support git and Subversion. We recommend using git because of its popularity, free availability and distributed nature, which fits well with the intended use in a collaboration on a writing project among scientific authors. Subversion is also freely available and already used by many. See the questions below for more details on different version control systems.


Why use git?

Git is free and open source and as the version control system for the Linux kernel and other high-profile open source systems under very active development. Git is also a distributed version control system, which suits the idea of collaborating authors working mostly offline (some people write best when not connected to the Internet with all its distractions).


Why use Subversion?

Subversion is also a free and open source version control system, which is very popular and under active development. However, it is a so-called centralized version control system, which means that authors can only use LTC while connected to the server, as the history of the .tex file is kept there. This prevents working with LTC in offline situations. Since it remains widely in use and is familiar to some authors, we do support using it. The response time is slower than using git.


Could LTC support other version control systems?

Yes, LTC can work with other version control systems if there is interest. We leave this as a future exercise for the open source community to provide a different back-end for a new version control system.


How do I stay in touch?

Until we have a proper mechanism to check for updates from the LTC applications, it is best to subscribe to changes using the SourceForge web site .

Troubleshooting

How do I submit a bug report?

Thank you for contributing to this project by filing a bug report. To help us debugging, please create a bug report file "report.zip" using the button "Bug Report..." in the LTC Editor or the Emacs menu item "Bug report...", which is also accessible via the command "M-x ltc-bug-report". Specify a location where to generate the report ZIP file, give an explanation if you wish, and decide whether to include the source repository of your writing project. Then send an email to the lead developer attaching the generated "report.zip" file.


I'm not sure if my LTC Server is running.

You can test whether your LTC Server is running using our little utility program HelloLTC:

$> java -cp $LTC/LTC.jar com.sri.ltc.server.HelloLTC -p 8765
 *** ERROR: Could not connect to LTC server on port 8765
$> java -cp $LTC/LTC.jar com.sri.ltc.server.HelloLTC
The answer to the question of life is: 42
(Seeing this means your LTC server on port 7777 is running.)

If you don't see the answer to the question of life, your LTC Server is not running on the tested port. If you omit the -p option, the default port is used for testing.


My svn-controlled file generates an authentication error.

We are relying on a Java library called svnkit to provide access to Subversion repositories. As such, the authentication mechanism is a bit different (because written in Java) than your native svn command line client or other Subversion applications. If you are able to run the following command

$> svn log <MY_FILE>

from the command line without a prompt for authentication but LTC generates an authentication error, you can try to work around this by doing the following once for every Subversion repository, where your files generate such an error. First, download the svnkit 1.7.x standalone distribution (or match the version used in LTC for "org.tmatesoft.svnkit" as seen on page http://latextrack.sourceforge.net/dependencies.html ) from http://www.svnkit.com/download.php. Extract the downloaded zip file in a directory of your choice that we call $TMP_SVNKIT. Then, do the following command in your svn repository, which may result in prompts for authentication as seen below. Simply answer the following questions, which may look like this:

$> $TMP_SVNKIT/svnkit-1.7.x/bin/jsvn log <MY_FILE>
Authentication realm: svn+ssh://rfs.csl.sri.com
Username: <USERNAME>
Password for 'rfs.csl.sri.com' (leave blank if you are going to use private key): <PASSWORD>
Port number for 'rfs.csl.sri.com' [22]:
The 'rfs.csl.sri.com' server's key fingerprint is:
<FINGERPRINT>
If you trust this host, enter 'p' to add the key to the SVN cache and carry on connecting.
If you want to carry on connecting just once, without adding the key to the cache, type 't'. If you do not trust this host, type 'R' to abandon the connection.
(R)eject, accept (t)emporarily or accept (p)ermanently? p

Now the credentials should be cached (typically in ~/.subversion/auth/ or ~/.svn/auth) and a subsequent call to the above command is not prompting for authentication anymore. In this case, LTC should now work since we are using the svnkit Java library and thus going through the same steps to determine authenticity. In case the above does not provide remedy, please send screen shots and details to the lead developer.


Running ltc-install.sh with Emacs directory generates error.

If you are installing or updating LTC with the ltc-install.sh script and supplying an Emacs directory (where the Emacs packages are being put) but an error occurs that says:

caution: filename not matched:  versions.el
 *** ERROR: Something went wrong when extracting Emacs Lisp files -- exiting.

then you may have an outdated install script. Download ltc-install.sh again and try it with the new script. As of Jan 30, 2014, the install script performs a self-check at the beginning to see whether a newer version of it is available online. If a newer version is found you are prompted whether the script should overwrite itself. You can skip the self-check using the option -s.

Troubleshooting Emacs Mode

When I try to invoke ltc-mode in Emacs, it says "[No match]".

You need to tell Emacs about ltc-mode in your Emacs configuration file adding the line

(autoload 'ltc-mode "ltc-mode" "" t)

When I try to invoke ltc-mode in Emacs, it says "Cannot open load file: ltc-mode".

Emacs is not able to find the Emacs Lisp files from the LTC distribution. Check that the load-path in Emacs contains the directory that you used as the second argument for the LTC installation script.


When I try to invoke ltc-mode in Emacs, it says "LTC Error: While testing LTC server version: Why? url-http-response-status is nil Perhaps the LTC server is not running?"

Possible causes are that the server is not running or that the server uses a different port than the Emacs mode. If the server is running, check whether Emacs uses the same port as the server. The port that the server uses was output on the command line where it was started and can also be found in the log file ~/.LTC.log in a line ending similarly to the following.

... | INFO:    Started RPC server on port 8765.

You can also check whether the LTC Server is running using the utility described in the question above.

To check the port setting in Emacs, invoke the command "C-h v ltc-port <RET>" (this requires ltc-mode to be loaded at least once, possibly with the failure above). See the manual for more details on configuring Emacs.


When I invoke ltc-mode in Emacs, it asks "Warning: ltc-mode.el (X.Y.Z) and LTC Server (A.B.C) numeric version prefixes don't match. Continue anyways? (y or n)"

We are now checking versions between the client (Emacs mode) and server to make sure that they match. We are only comparing the numeric prefix (i.e., if we release an alpha names X.Y.Z-pre, it would only compare the numeric part X.Y.Z of the version numbers) -- we prompt the user whether to continue loading ltc-mode in case they need to update their LTC installation. Using the install script with the appropriate Emacs directory as the second argument should always result in matching versions. In that case the user is not prompted for input.


When starting or updating LTC mode, or saving my text in Emacs, it says "LTC Error: While updating: Multibyte character in data for base64 encoding" What should I do?

The text in the Emacs buffer contains so-called multibyte characters. Commonly, these are from international character sets. A sequence of two or more bytes are used to represent individual non-ASCII characters.

LTC mode does not convert these characters for you because this would result in loss of information. Instead, the author has to decide what to do about those characters. One option is to use the Emacs command "M-x eval-expression <RET> (set-buffer-multibyte nil) <RET>" to force Emacs into changing the coding system. This is best done before starting LTC mode.


My ltc-mode seems to be working but deletions are missing the strike-through markup.

Unfortunately, Emacs 23 under Mac OS X is missing the Courier font in strike-through. Other operating systems such as Linux do not have this problem but the default setting for marking up deletions may not show the strike-through.

You can customize Emacs to use a different font face for marking up deletions using command "M-x customize-face <RET> ltc-deletion <RET>" once LTC mode has been loaded at least once via "M-x ltc-mode" (which can be unsuccessful).

As of Emacs 24 on Mac OS X, the strike-through font is working again. Customize the deletion font accordingly.


Can ltc-mode run in black-and-white Emacs?
No. (TODO: elaborate on failure message etc.)