Click Here To Return To Our Home Page
Click Here For Our Services
Click Here For Additional Products
Click Here For Web Design
Click Here For Web Hosting Services
Click Here For Dialup Access
Click Here For Domain Names
Click Here For Contact Details
Click Here For Our Online Support
Click Here to Check or Order Services
 

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.

 

 
(c) MagnaCom Limited, Crossford Mill, Beith Road, Johnstone. PA10 2NS
Tel: +44(0)1505 706000 Email: Click Here To Email

























Click Me!