Glossary
of Acronyms
A B
C D E
F G H
I J K
L M N
O P Q
R S T
U V W
X Y Z TAB
- Tape Automated Bonding. A low cost IC package
method that attaches a die directly to a PC board
using a thin film with conductive leads.
TLB - Transition Lookaside Buffer. A function
supplied the Intel Pentium processor. The TLB
is a local cache memory for virtual to physical
address translations and is usually a part of
the MMU (Memory Management Unit).
TPI - Tracks Per Inch. The number of tracks
written within each inch of a harddisk's surface.
Used as a measure of how closely the tracks are
packed on a disk surface. Also known as track
density.
TSR - Terminate and Stay Ready. The terminate
and stay ready program is an application program
usually loaded into the computer's memory by the
AUTOEXEC.BAT or CONFIG.SYS file. It remains dormant
in memory until it is needed by a peripheral or
an application. An example of a TSR is a virus
checker.
TWAIN - Technology Without An Interesting
Name. So I am told this is the meaning of
this acronym. Not 100% confirmed. TWAIN : Linking
Applications and Images. This is from HP:
TWAIN defines a standard software protocol and
application programming interface (API) for communication
between software applications and image acquisition
devices. In desktop publishing's early days, most
publications contained only text and simple black-and-white
line drawings that were output to black-and-white
laser printers. In recent years, however, computer
hardware and software has become much more sophisticated.
Both business professionals and graphic artists
can now create and output complex, full-color
publications. This near-commercial-quality work
may include black-and-white, grayscale, and color
images acquired from desktop and hand-held scanners,
or from still video, digital cameras or image
capture boards. This growth in technology means
vendors are faced with a challenge to supply customers
with hardware seamlessly for an efficient, easy-to-use
computing process. Unfortunately, image acquisition
remained a difficult process. To acquire and place
an image in your publication, you had to leave
the application in which you were working. Then
you had to locate and open a hardware driver,
set the device options, acquire the image, save
it to disk, close the hardware driver, and return
to the application.
When the image-acquisition issue surfaced, hardware
and software developers began defining their image
acquisition interfaces. This was a step in the
right direction, but it soon became apparent that
high numbers of proprietary interfaces were not
the ultimate solution. It is inefficient to require
a software developer to write a driver for each
device they need to support. Conversely, it does
not make sense to ask a hardware vendor to write
a different driver to interface with each software
application. Most importantly, it is not acceptable
that users must deal with many unique application/device
driver files.
Users need a painless way to get image data into
their applications. Software developers need compatibility
with the widest range of output devices without
writing and maintaining multiple device drivers.
Hardware developers need compatibility with the
greatest number of applications without application-dependent
coding.
The solution is an open industry interface that
directly acquires image data from external sources
while within an application. With this, each software
developer supports a standard data acquisition
manager and each hardware vendor writes one driver
for their device. Hardware vendors will benefit
because they need only provide one standard driver
for their device, which can then be used by all
software applications supporting the standard
data acquisition interface. Software vendors will
be freed from writing and supporting device drivers,
or from soliciting support for their own proprietary
interface.
In early 1990, the formation of the Macintosh
Scanner Roundtable group heightened the imaging
industry's awareness of the need for an open interface.
While participation in the roundtable was high,
it was difficult to resolve issues and progress
was slow. At one of the group's last meetings
in 1990, it was suggested that a smaller set of
industry leaders form a consortium and create
a specification for review, revision, and ultimate
adoption by the imaging industry.
The TWAIN Working Group was formed with representatives
from Aldus, Caere, Eastman Kodak, Hewlett-Packard,
and Logitech. The Working Group's primary goal
was promoting imaging products through developing
an easy-to-use image acquisition interface and
educating users about it. A key requirement of
participation was that members be willing to represent
a broader interest than that of their own company.
The number of participants was kept low so the
specification could be written quickly, while
representation from a wide spectrum of application
developers (desktop communications and OCR) and
hardware vendors (hand-held, desktop, and high-end
color imaging devices) was maintained. The result
was that working group members represent diversity
in the industry, and bring in-depth imaging experience
to both hardware and software development, and
marketing fields.
Besides the TWAIN Working Group, more than 175
major imaging hardware and software companies
form a group called the "TWAIN Coalition."
This larger group reviewed the TWAIN specification
and provided feedback before its release. The
TWAIN Working Group took comments and suggestions
from the TWAIN Coalition, examined the costs and
benefits of the modifications, and decided which
to incorporate into the specification. The Specification
is now in its third revision.
As of 1995, the TWAIN Working Group is composed
of four companies: Hewlett-Packard, Logitech,
Documagix and Canon. These companies continue
to regularly update and modify the specification,
set direction for future TWAIN development, and
implement additions to the TWAIN Data Source Manager
and tools.
TWAIN provides a simple methodology for universally
connecting TWAIN-compliant applications with TWAIN-aware
devices. The model for how applications interact
with the source of input data can be described
through a four-layer protocol: the Application
Layer, Protocol Layer, Acquisition Layer and Device
Layer. The acquisition components correspond to
these layers and include the application, Source
Manager, Source and physical hardware device.
The application communicates through the Source
Manager to a Source driver that represents the
physical hardware device that generates image
data.
The hardware interface element of the TWAIN architecture
is the Source. A Source is a TWAIN entity whose
purpose is to get data from a hardware device
and provide it to a TWAIN-compliant application.
A Source is typically written by the hardware
vendor to control their peripheral device. These
devices are usually a physical piece of hardware,
such as a scanner, although a virtual device (such
as an image database) also fits the Source model.
The device may be locally connected or remotely
accessed over a network.
The central element of this architecture is the
Source Manager (SM). The SM's primary role is
to establish and manage the connections between
the application and the sources. The SM allows
the user to select the desired source, loads and
unloads the selected source, and makes sure that
all calls from a particular application are correctly
routed to the appropriate source. The SM is implemented
as a code resource on the Macintosh and a Dynamically
Linked Library (DLL) under Microsoft (R) Windows.
Under Windows, there will be only one copy of
the active in memory at any given time. On the
Mac, there will be a separate copy of the SM for
each application accessing it. When the application
needs to communicate with a Source, it calls the
SM with a correctly addressed message. An application
never calls a Source directly.
A
B
C D E
F G H
I J K
L M N
O P Q
R S T
U V W
X Y Z
Compiled by Scott
McArdle, MagnaCom Limited. I hope this list
has helped you and if there is an item that should
be on this list, please let me know. Thanks. PS,
I've spent 100's of hours maintaining this list,
please don't be a LAMER.
|