Author’s Guide

1. Style Guide

The most important requirement for any tool is utility. And the most important requirement for a jgt paper is to present a tool clearly and effectively. Over the years, we’ve identified some canonical style characteristics that we feel help present tools as clearly and usefully as possible.

1.1 Conciseness and Completeness

Keep the presentation as short as possible. This isn’t just a matter of saving paper! The longer a paper, the more work it requires for readers to go through it, and the more its contribution may get lost. Even if the tool may be good, an overlong paper is not as useful as it could be.

On the other hand, don’t leave out any important details. The tool presented by the paper should work “out of the box"—readers should be able to implement the tool without needing to fill in any big gaps.

So how long should a jgt paper be? We encourage short papers, even as short as 1 or 2 pages for simple insights. For more general papers, aim for about 6–8 pages. We don’t have a formal maximum length, but papers above 15 pages are unlikely to meet our goals of simplicity and clarity.

1.2 Paper Structure

Of course, every paper has different needs, but here’s a good canonical structure that fits most jgt papers:

Introduction
The motivation or problem statement. Explain what you’re trying to do and why existing techniques aren’t good enough. Emphasize what new tool you’re providing to the reader—and why the reader would want to use it. This should be fairly brief, often just a few paragraphs, so that the reader can quickly get to the main body.
Background or Overview
Provide context and material to understand the presentation and use of the tool. This needn’t be comprehensive or elementary; it’s safe to assume that readers have a good understanding of computer graphics. Provide a brief reminder of topics that most readers ought to know and more detail for things that are more esoteric.
… Main Section(s) …
Present the tool. This may be broken up into several sections as needed.
Examples, Performance, and/or Comparison
Demonstrate that the technique works. Present measures of its speed, memory use, or quality. Show how it compares with competing techniques.
Limitations and Drawbacks, Discussion
Few techniques are panaceas: make sure to tell readers the downsides. The discussion can also include hints on how to use the tool well, how to know when to use or not use the tool, and so forth. These are ideally based on the author’s experience in using the tool.

1.3 Differences from Research-Paper Style

For authors who usually write research papers, we point out some differences from the canonical research-paper style:

No Related Work or Previous Work section:
jgt papers don’t typically need a pro-forma “related work” section. Relevant works should be cited throughout the paper as necessary: to give credit for borrowed techniques, to refer readers for further details, or to point out contrasting or competing techniques. Cite only references that help the reader understand the technique and how and why to use it. An encyclopedic list of all related or previous work is not typically needed, but a recent survey, overview paper, or textbook could be cited, if one exists.
No “road map” paragraph:
Research papers typically have a paragraph similar to “In Section 2 we discuss prior work. Section 3 presents background information. In Section 4 we…” jgt papers rarely needed this kind of road map—most are short and clear enough for readers to simply read or flip through to learn the structure.
“Present” a new technique, not “Propose” it:
A common style in research papers has authors “propose” a new technique, with the implication that time and the research community will ultimately decide whether the technique is worthy. But for a jgt paper, the author, reviewers, and editors all agree that the technique is worthy—and so we present it to our readers with confidence. This is a small matter of wording, but it contributes to the overall tone of utility.
Present your “technique”, not your “work”:
Research papers typically discuss the authors’ “work.” But a jgt paper typically presents a specific technique, method, or algorithm. Again, this is a small matter of wording, but it contributes to the overall tone of focusing on utility.
Show “Examples,” not “Results”:
Another matter of wording. Research papers typically demonstrate a technique by showing its experimental results. But a jgt paper presents a tool mature enough that its use is not experimental—so it can be demonstrated with examples of its use. (Though the word “results” can apply in a jgt paper, to refer to the statistics gathered from performance-evaluation tests or comparison tests against other techniques.)
Personal statements and observations are OK:
jgt papers are born from authors’ experience and insights, so it’s reasonable to include the authors’ observations. In particular, for a single-author paper, feel free to write using “I” rather than “we.” And favor active sentences (“We sort the rays.”) over passive (“The rays are sorted.”).
No Summary, Conclusion, or Future Work section:
A jgt paper should be short and clear enough to need no “summary”; the use of the tool should be clear enough that no “conclusion” need explain it; and “future work” is of no use great use to the reader. Sometimes in a research paper, a “conclusion” section points out some valuable properties of the technique—in a jgt paper, those properties should generally be listed in the introduction. Sometimes a “future work” section serves to point out things that the presented technique doesn’t handle—a jgt paper should certainly point out such limitations but would typically do so in a “discussion” or “limitations” section.

1.4 Web Materials

Every jgt paper ends with a Web Information section, which lists the URL of the paper’s page on the jgt website. We encourage authors to provide us with materials such as images, videos, and source code to make available on the Web—and to write a small blurb describing the material.

In the final paper, we prefer to list jgt’s URL, which will be something like http://jgt.akpeters.com/papers/Author05/, rather than (or in addition to) the author’s personal site. The jgt site can host the materials locally or can link in turn to the author’s site. We use this approach because authors’ sites tend to be transient; we don’t want the printed material to end up with dangling links. Note: for submission, please do provide your personal URL here, so that the reviewers and editors can easily find the material.

We also ask authors not to write the URLs in the body of the paper, but rather only in the Web Information section. We prefer to have the URLs consistently in one place. In the body, refer to the URL as “…the address listed at the end of this paper.”

If you will provide source code, typically mention this in the last sentence of the abstract: “Source code is available online.” The introduction and/or presentation of the algorithm will include “Source code is available online at the address listed at the end of this paper.”

2. On Submitting Faster Versions of Algorithms

Computers are never fast enough, and jgt is a great forum for improved algorithms that run faster. But please keep in mind that performance depends on ever-changing things like processor speed, pipeline technology, cache sizes, etc.; and also, standard optimization tricks like precomputing, code reordering, etc. can often vastly improve the speed of code without changing the underlying algorithm.

So a new algorithm that demonstrates only modest speed improvements over existing algorithms is not likely to be greeted with excitement by our reviewers and editors—unless it is also better in some other ways: simpler, easier to code, more accurate, fewer errors, or something. Worse, if the algorithm is only modestly faster and also more difficult or more error-prone, it is unlikely to be accepted.

The bottom-line question for an “improved” algorithm is: will our reviewers and editors want to replace their currently working algorithm with your new one? That’s the sign of a really improved algorithm.

3. Formatting Your Submission

We aren’t picky about the format of your submission. If you can, try to format it to look roughly like a published jgt paper.

You do not need to worry about the final formatting. After acceptance and final approval of a paper, the A K Peters production staff will copyedit and do the final layout of the paper for publication. You will be asked to check the proofs before final publication.

We recommend that you use LaTeX; that’s what we use for the final layout. If you use LaTeX, the production staff will be able to start with your source files, minimizing the chances of errors in the final publication. Please download the jgt LaTeX style files and article template to help you get started.

4. The Review and Revision Process

Submissions will be refereed by members of the editorial board or outside reviewers according to the criteria of clarity and utility discussed above and in the call for papers and codified in the referee’s review form.

The result of the review process may be:

Reject. The editors believe the paper is not appropriate for jgt.
Request Resubmission. The editors believe the described tool has promise, but the paper hasn’t presented sufficient evidence or clear enough explanation to completely convince the editors. Or in some cases, the editors may be convinced of the technical merit, but the presentation would need major revision to be appropriate for jgt. When possible, a revised submission is sent to the original reviewers to assess whether their concerns have been met.
Accept with minor modification. The reviewers and editors typically have suggestions for improving the presentation. In only a handful of cases has a jgt submission ever been published as-is.

In all cases, we try to provide clear explanation of the reasoning that led to the judgment, but authors may feel free to contact us to request clarification or provide rebuttal, or to seek advice on addressing the comments.

An accepted paper enters an “edit cycle” in which the author and a designated editor work together to produce the final version based on the original review comments and the editor’s sensibilities for clarity and conciseness. Typically, this involves one to three revisions until the editor approves the final version.