Jambo Naples is an establishment dedicated to providing pizza that emulates what the denizens in Naples have been enjoying for thousands of years.
We focus on bringing out the flavour of each ingredient, such that your palate will be overwhelmingly satisfied
Because ours is a neapolitan pizza, its base consists of san marzano tomatoes as well as mozzarella di bufala campana(cheese made with the milk of water buffaloes)
The rest of the ingredients - including the spices uses - are left to the customer's discretion
We've been in the market for just over 5 years and our customer base has grown exponentially - from a few hundred every month, to thousands on a weekly basis
Our revenue streams are multiple as we go even further than simply using products to make pizza. We manufacture our own dough, grow our own spices and rear the animals needed for our meat.These base products are also sold, and contribute to our growing revenue.
We plan on expanding beyond simply serving pizza and side dishes.In 27 months, we will offer the widest variety of medditeranean cusine in the region
We are a reliable investment option, as proven by our ever-growing coffers.


This topic describes signed JNLP files and JNLP templates. A signed JNLP file is a JNLP file that is included in a signed JAR file before the JAR file is signed. A JNLP template defines the parts of an external JNLP file that can differ from the one embedded in a JAR file.
This topic contains the following sections:
Signing a JNLP file provides the following advantages:
Ensures that others cannot change the content in your JNLP file, for example, by adding a random library, or changing application information.
Allows the use of arbitrary Java Virtual Machine (JVM) options and Java system properties in your application.
Prevents others from referencing your JAR file directly in their HTML browser applets.
To create a signed JNLP file, you don't sign the JNLP file itself. Instead, you include the JNLP file inside the directory structure before the JAR file is created and then signed. The JNLP file must be named APPLICATION.JNLP
and is included in the JNLP-INF
subdirectory. The JAR file is then created and signed in the usual manner. When a web start application is started, the JNLP file used must be identical to the JNLP file in the signed JAR for the application to run.
Note that you cannot use the APPLET tag to run an applet if the JAR file contains a signed JNLP file.
The Signing and Verifying JAR Files lesson in the Java Tutorial explains how to sign a JAR file.
A JNLP file can be signed to grant special privileges to a JAR-bundled application. When deploying a signed application from a location that is unlikely to change, and other aspects of the deployment are stable, you can use a standard JNLP file, as described in Signing and Verifying Jar Files in the Java Tutorial.
However, when an application needs to be re-distributed, or other tweaks are needed, such as changing the application icon, you can deploy the application with a JNLP template. Introduced in JDK 7, a template can define the parts of an external JNLP file that can differ from the one embedded in a JAR file.
A template file has the name JNLP-INF/
APPLICATION_TEMPLATE.JNLP
. The name must be in upper case. For those element or attribute fields in the file that are to be left unspecified, the wildcard notation, *, is used as that field's value. Elements or attributes that might compromise security are locked out from this feature.
Example 17-1 shows an application template that could be used to host an application on various hosts with different application icons.
Example 17-1 Sample Application Template
<?xml version="1.0" encoding="UTF-8"?> <jnlp codebase="*"> <information> <title>SampleApp</title> <vendor>Sample Company</vendor> <icon href="*"/> <offline-allowed/> </information> <resources> <java version="1.3+"/> <jar href="SampleApp.jar"/> </resources> <application-desc main-class="com.sample.SampleApp"/> </jnlp>
An application with this text in a JNLP-INF/
APPLICATION_TEMPLATE.JNLP
file in its main JAR file can be moved from one server to another, or its application icon can be changed, without resigning the main JAR file.
For more information, see Version 7.0 of the JNLP specification (jcp.org).


{% include 'blocks/index-head-nav.html' %} {% include 'blocks/faq-main.html' %} {% include 'blocks/user-details.html' %}
Facebook Post Preview


Gareth Bale: Zinedine Zidane urges fans not to jeer Wales forward
Real Madrid manager Zinedine Zidane has called on the Spanish club's fans to stop booing Gareth Bale.
The Wales forward received a mixed reception coming on as a substitute in a 3-1 win over Real Sociedad.
It was his first Real appearance in seven weeks after his controversial 'Wales. Golf. Madrid' flag celebration in Cardiff.
"There is too much noise with Bale. He wants to be with us and do it well," said Zidane.
"I hope this doesn't carry on for the rest of the season.
"We want the fans to be with us from the beginning to the end, but we cannot control that."
Zidane added: "I have not spoken to him [about the jeers], I have only congratulated him.
"I can't tell you if it's unfair or not. Everyone can say what they want."
Bale has endured a difficult relationship with the Bernabeu crowd since joining from Tottenham for a then world-record fee of £85m in 2013, despite helping the club win four Champions League trophies.
In July he came close to joining Chinese side Jiangsu Suning, with coach Zidane saying his exit would be "best for everyone".
The move was called off at the last minute when Real demanded a transfer fee.
Bale seemed to re-establish himself in the club but returned to Spain injured in October after scoring Wales' equaliser against Croatia.
He didn't play again until Wales' games against Azerbaijan and Hungary, a comeback labelled by the Spanish press as the 'Miracle in Wales'.
Bale was jeered by supporters when his name was announced before kick-off on Saturday.
The 30-year-old received a similar response when introduced from the bench after 67 minutes for his first Real appearance since 5 October, though by full-time Bale appeared to have earned back some support.
He was applauded for the part he played in Modric's third goal and also for his defensive efforts as Real closed out the game.
"He is integrated into the group and wants to play, just like everyone else," said Zidane.
"The public has the right to do what they want, but I ask that they applaud everyone. I'm happy with the game and the victory and Bale came into the game well."
Attention now turns to the Champions League for Zidane's side, who host Paris St-Germain on Tuesday (20:00 GMT).


| Package | Description |
|---|---|
| weka.classifiers.rules.part | |
| weka.classifiers.trees.j48 | |
| weka.classifiers.trees.lmt |
| Constructor and Description |
|---|
C45PruneableDecList(ModelSelection toSelectLocModel,
double cf,
int minNum)
Constructor for pruneable tree structure.
|
ClassifierDecList(ModelSelection toSelectLocModel,
int minNum)
Constructor - just calls constructor of class DecList.
|
MakeDecList(ModelSelection toSelectLocModel,
double cf,
int minNum)
Constructor for dec list pruned using C4.5 pruning.
|
MakeDecList(ModelSelection toSelectLocModel,
int minNum)
Constructor for unpruned dec list.
|
MakeDecList(ModelSelection toSelectLocModel,
int num,
int minNum,
int seed)
Constructor for dec list pruned using hold-out pruning.
|
PruneableDecList(ModelSelection toSelectLocModel,
int minNum)
Constructor for pruneable partial tree structure.
|
| Modifier and Type | Class and Description |
|---|---|
class |
BinC45ModelSelection
Class for selecting a C4.5-like binary (!)
|
class |
C45ModelSelection
Class for selecting a C4.5-type split for a given dataset.
|
class |
NBTreeModelSelection
Class for selecting a NB tree split.
|
| Constructor and Description |
|---|
C45PruneableClassifierTree(ModelSelection toSelectLocModel,
boolean pruneTree,
float cf,
boolean raiseTree,
boolean cleanup,
boolean collapseTree)
Constructor for pruneable tree structure.
|
ClassifierTree(ModelSelection toSelectLocModel)
Constructor.
|
NBTreeClassifierTree(ModelSelection toSelectLocModel) |
PruneableClassifierTree(ModelSelection toSelectLocModel,
boolean pruneTree,
int num,
boolean cleanup,
int seed)
Constructor for pruneable tree structure.
|
| Modifier and Type | Class and Description |
|---|---|
class |
ResidualModelSelection
Helper class for logistic model trees (weka.classifiers.trees.lmt.LMT) to implement the
splitting criterion based on residuals.
|
| Constructor and Description |
|---|
LMTNode(ModelSelection modelSelection,
int numBoostingIterations,
boolean fastRegression,
boolean errorOnProbabilities,
int minNumInstances,
double weightTrimBeta,
boolean useAIC,
NominalToBinary ntb,
int numDecimalPlaces)
Constructor for logistic model tree node.
|
Copyright © 2018 University of Waikato, Hamilton, NZ. All Rights Reserved.


--- layout: post esbma_id: 1382 date: 2003-03-31 12:00:00 keywords: cornsharp title: Blog entry on 31 Mar 2003 ---
Ralph Johnson was one of my favorite professors at UIUC. Nowadays he sometimes invites his alumni back to speak to his Senior Projects class. The topic is always the same: "What I Wish I Knew When I Graduated". I've done this gig several times and it's always fun. I'm speaking to the class again today. My slides (PowerPoint format) are attached.
| cs292_31mar2003.ppt | 610 KB |


Everyone that use Jekyll and wants to host the site at GitHub should know that GitHub Pages does not allow custom plugins, right? Using Jekyll for a little more than a blog site, like EMAp/FGV will require plugins. In my case, avoid the use of custom plugins is not an option.
The solution is trivial, one has to run Jekyll locally and post the produzed files into a master branch of a git repo, following the conventions described at GitHub Pages por person and organization pages. The problem that I faced was to choose the best way to organize and keep tracking of the source and produzed files.
I read a couple of posts with possible solutions. The solution by Charlie Park force us to have two distinct git repositories. I don't like this approach because of that. Our website will be maintained by more than one person, having two distinct repositories since that I will not using all git features. The solution by Jean Denis is a little bit better but keeps me thinking about why he need to keep the produced files under version control in the two branches, gh-pages and the master.
My final solution is to keep the directory produced by jekyll out of git control. This simple thing allows me to switch the branches, from source to master, and still have access to the produced files, directory _site
. Once in the master branch, I only have to move the files under _site/
to the root directory in the master branch and update the master branch before push it to GitHub.
git checkout source
// do whatever you need
git status / git add / git commit
jekyll
checkout master
cp -r _site/* . && rm -rf _site/ && touch .nojekyll
git status > git add > git commit
git push -all origin


Assign Job to Vendor
-
{{selectedmanager}}
-
{{vendor.name}}
{{onboarding.first_name}} Onboarding Details
Bv Vendor : {{onboarding.bv_vender}}
- First Name:{{onboarding.first_name}}
{{onboarding.first_name_comment}}
- Last Name:{{onboarding.last_name}}
- Spouse Name:{{onboarding.spouse_name}}
- Blood Group:{{onboarding.blood_group}}
- Gender:{{onboarding.gender}}
- Nationality:{{onboarding.nationality}}
- Marital status:{{onboarding.marital_status}}
- Date_of_birth:{{onboarding.date_of_birth}}
- Pan Card:{{onboarding.pan_card}}
- Current Address:{{onboarding.current_address}}
- Permanent Address:{{onboarding.permanent_address}}
- Fathers Name:{{onboarding.fathers_name}}
- Year of passing tenth:{{onboarding.year_of_passing_tenth}}
- Board university tenth:{{onboarding.year_of_passing_tenth}}
- Year of passing twelve:{{onboarding.year_of_passing_twelve}}
- Board university twelve:{{onboarding.board_university_twelve}}
- Year of passing graduation:{{onboarding.year_of_passing_graduation}}
- Board university graduation:{{onboarding.board_university_graduation}}
- Year_of_passing_postgraduation:{{onboarding.year_of_passing_postgraduation}}
- Board university postgraduation:{{onboarding.board_university_postgraduation}}
- Existing EPF Account:{{onboarding.year_of_passing_graduation}}
- Existing ESIC Account:{{onboarding.board_university_graduation}}
- Organization Name:
{{organization.organization_name}}
- Start Date:
{{organization.start_date}}
- End Date:
{{organization.end_date}}


BaseStream - Base class to read and write streams.
More...
#import <BaseStream.h>
Detailed Description
BaseStream - Base class to read and write streams.
BaseStream is used as base class for both classes InputStream and OutputStream. It shouldn't be used directly, you must make use of InputStream and OutputStream (or inherit from it).
- Author:
- Víctor Berga<EMAIL_ADDRESS>Field Documentation
- (FILE*) _file [protected] |
- (NSString*) _path [protected] |
Property Documentation
- (BOOL) isOpen [read, assign] |
Return YES if the file is open and ready.
- (unsigned long) len [read, assign] |
- (unsigned long) offset [read, assign] |
- (NSString*) path [read, write, retain] |
- (NSStringEncoding) stringEncoding [read, write, assign] |
Sets or gets the string enconding.
Default is NSUTF8StringEncoding
The documentation for this class was generated from the following files:


All the guts of a Sections class inside a module, so multiple inheritance-like behaviour can be used for Reports which expose the Sections interface herein, along with their own Calculator interface for overall totals.
As “#each_section()”, but for Groups.
# File lib/track_record_sections.rb, line 290 def each_group @groups.each_value do | group | yield( group ) end end
Retrieve all Sections, perhaps in order to assign caller data. Call with a block, invoked with a Section instance at each iteration. The returned Section order is arbitrary. Use e.g. “iterate()” for deterministic ordering.
# File lib/track_record_sections.rb, line 282 def each_section @sections.each_value do | section | yield( section ) end end
Iterate over the tasks provided in the constructor, in the same order as provided in the construtor. The caller's block is invoked with parameters of the task, a Section, a flag indicating that the task started a new Section if true, a Group and a flag indicating that the task started a new Group if true.
# File lib/track_record_sections.rb, line 270 def each_task tasks.each do | task | section, is_new_section, group, is_new_group = retrieve( task.id.to_s ) yield( task, section, is_new_section, group, is_new_group ) end end
Obtain a Group instance related to the given task, specified as a task ID in string form.
# File lib/track_record_sections.rb, line 236 def group( task_id_str ) @task_to_group_map[ task_id_str ] end
Initialize by passing in the array of non-nil Task instances that will be used for group and section processing. This must already be in an order that makes sense for such processing, e.g. sorted by project, customer, task title.
Ideally, pass an ActiveRecord::Relation instance that'll return a set of appropriately sorted objects for most efficient operation.
In the optional section parameter, pass a Class which will be instantiated instead of TrackRecordSections::Section whenever a new section is being defined. The class must include SectionMixin along with whatever other behaviour it might define (which is of interest only to the caller and ignored herein). The custom class constructor must have the same signature as, and must call module method “initialize_section()”.
# File lib/track_record_sections.rb, line 153 def initialize_sections( tasks, optionalClass = Section ) # Create new Section objects and a map between task IDs and # those objects, so we can get to them quickly. # # We run through the tasks in the array order. Whether or # not a task needs a new Section object instance, because # it represents a hithertoo unencountered project/customer # combination, tells us that this task's row will sit at # the top of a new section in e.g. a generated report. Keep # track of that flag in another task-keyed hash as it'll be # very useful for section-aware generators or similar views. # # Groups are also handled in this loop, creating a set of # flags, but not needing new section objects. While sections # are uniquely identified by a combination of project and # customer, groups are uniquely identified by title. Group # titles are based upon the presence of colon characters in # task names (everything up to the first colon). @task_to_section_map = {} @task_starts_section = {} @sections = {} section_identifier = 0 # Groups are harder as we have to consider the no-colon-in-title # "ungrouped" tasks and how we need to treat it as a group change # if we change from ungrouped to group task, or vice versa. @task_to_group_map = {} @task_starts_group = {} @groups = {} previous_group_id = nil # Intentional potential first-row match to "ungrouped" task tasks.each do | task | task_id_str = task.id.to_s project_id = task.project.try( :id ) || '-' customer_id = task.project.try( :customer ).try( :id ) || '-' section_id = "#{ customer_id }_#{ project_id }" found = @sections[ section_id ] if ( found.nil? ) @task_starts_section[ task_id_str ] = true @task_to_section_map[ task_id_str ] = @sections[ section_id ] = optionalClass.new( section_identifier += 1, task.project ) else @task_starts_section[ task_id_str ] = false @task_to_section_map[ task_id_str ] = found end group = Group.new( task ) group_id = group.title() found = @groups[ group_id ] if ( found.nil? ) @task_starts_group[ task_id_str ] = true @task_to_group_map[ task_id_str ] = @groups[ group_id ] = group else @task_starts_group[ task_id_str ] = ( previous_group_id != group_id ) @task_to_group_map[ task_id_str ] = found end previous_group_id = group_id end end
If you want to change the task list at some later time, with some tasks omitted, call here to retain all section and group data but reasses the “this task starts a new section/group” flag settings in view of the new task list.
The new task list can be a reordered version of the original and can have tasks omitted from the original, but may contain no new tasks. Results are undefined in such a case.
The internal record of the task list is necessarily updated (else it would mismatch the flags) so the “#each_task” enumerator will, after calling here, return the new tasks list, not the original.
# File lib/track_record_sections.rb, line 309 def reassess_start_flags_using( tasks ) previous_section = nil previous_group = nil tasks.each do | task | task_id_str = task.id.to_s s = section( task_id_str ) g = group( task_id_str ) @task_starts_section[ task_id_str ] = ( s != previous_section ) @task_starts_group [ task_id_str ] = ( g != previous_group ) previous_section = s previous_group = g end end
For the given task, which must be an instance present in the array of tasks given in the constructor, retrieve an array containing in order first to last index: a Section, a flag indicating that the task started a new Section if true, a Group and a flag indicating that the task started a new Group if true.
The task must be specified by its ID, as a string.
# File lib/track_record_sections.rb, line 255 def retrieve( task_id_str ) [ @task_to_section_map[ task_id_str ], @task_starts_section[ task_id_str ], @task_to_group_map [ task_id_str ], @task_starts_group [ task_id_str ] ] end
Obtain a Section instance related to the given task, specified as a task ID in string form.
# File lib/track_record_sections.rb, line 222 def section( task_id_str ) @task_to_section_map[ task_id_str ] end
Returns 'true' if the given task, specified as a task ID in string form, starts a new Group.
# File lib/track_record_sections.rb, line 243 def starts_new_group?( task_id_str ) @task_starts_group[ task_id_str ] end
Returns 'true' if the given task, specified as a task ID in string form, starts a new Section.
# File lib/track_record_sections.rb, line 229 def starts_new_section?( task_id_str ) @task_starts_section[ task_id_str ] end


Container Vs Virtual Machines
Virtual machines are quiet often compared to containers, on the basis that both allows multiple types of software to be run in contained environments. .
While containers represent the abstraction of the application layer, where any container simulates a different application through isolated process, and sharing same Operating Systems. On the other hand VMs are abstraction of the hardware layer, with each simulating the physical machine to run a software. VM technology ca use one physical server to run the equivalent of many servers. While multiple CM run on the same hardware platform, each run on its own Operating System, applications and their related files, libraries and dependencies. .
Running software in containerized environments generally uses less space and memory than running software on separate virtual machine. The VMs require separate copy of the Operating System to run on each VM. .
However, to decide which one is better depends on the situation and objective at hand. Virtualization isolates situations from basic equipment by a layer of reflection, in a solitary working framework. VMs run few distinctive working frameworks on one process hub, while containers offer the chance to virtualize the working framework itself.
A unique working framework on a hosts can expose it to millions of user on a cloud deployment environment, it is an elective strategy for Virtualization. VMs runs a few distinctive working frameworks on one process hub, where as containers can virtualize the working framework itself.


Page checker - settings
Interval
interval between page checking in milliseconds
ms
Jitter
Interval randomization to appear less automatic
ms
IFFT Webhook URL
url endpoint configured in at
this location
( then click on "documentation" page to get the link )
Reset
Save
Setting saved


October Sky **1/2 rated PG starring Jake Gyllenhaal, Chris Cooper, Laura Dern written by Lewis Colick based on the book "Rocket Boys" by Homer H. Hickam Jr. directed by Joe Johnston
There is a certain character we've seen many times before in American cinema. He is the unlikely hero; a boy who perseveres enough to pursue his dreams. In OCTOBER SKY, that character is Homer Hickam. The movie is based, however loosely, on Homer's autobiography, "Rocket Boys". It is the story of a boy from Coalwood, West Virginia, who witnesses the launching of Russia's Sputnik rocket into the October sky in 1957, and is immediately obsessed with building one of his own. In an early scene, Homer, not cut out for football, tries out for the team anyway, and recieves a comment from his coach who tells him that he just doesn't give up. Homer doesn't make the team, but we have evidence that he is not an ordinary boy. That is why when he tells his parents that he wants to build a rocket, it comes as no surprise. Homer, influenced by a school teacher(Laura Dern), gets 3 friends, including the school nerd, Quentin(Chris Owen), to help him build this rocket. Soon, even after a few failed launches, they are the talk of the town. These nerds have become the new jocks. Cheerleaders skip a football game in order to cheer the rocket boys. Everyone in town is interested. Everyone, that is, except for Homer's father, John Hickam.
John is the head of the coal mining corporation that is the sole purpose of Coalwood. Only the football players get college scholarships; everyone else goes to work in the mines. John is very disappointed that Homer is interested in this "dumb rocket business", and wants him to follow in his footsteps. Homer, of course, wants to do something different, being the boy that he is. The father-son relationship at the heart of OCTOBER SKY works very well for most of the film, because of the great performance of Chris Cooper. Cooper, from John Sayles' LONE STAR, is used to playing roles in which he is a quiet outsider. His perfromance in OCTOBER SKY is exactly the opposite. As John, Cooper shows depth and talent rarely seen in big name actors. Relative newcomer Jake Gyllenhaal, whom I've had the pleasure of seeing in one of his school musicals, is also quite good, but he is outshined by Cooper.
>From what you have read above, you are probably under the impression that OCTOBER SKY is a excellent, moving film. But the sad truth is, OCTOBER SKY is predictable, melodramatic, and overly sentimental. There are moments in OCTOBER SKY in which I was thinking about just how much of Hickam's book was actually put into this film. This film is so predictable and by-the-numbers, that I kept hoping for some kind of originality to appear. Also, writer Lewis Colick(GHOSTS OF MISSISSIPPI) pushes all the wrong emotional buttons in trying to get us to like OCTOBER SKY. This wouldn't be all that disappointing in another movie, but watching this one, you can tell that there is a touch of greatness trying to break out of this sugary-sweet mess. But I have to give props to the producers of OCTOBER SKY, for showing us the first '99 film with even a little ambition. review by the Teenage Movie Critic<EMAIL_ADDRESS>www.angelfire.com/mo/film.html
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


TIFF File Format Summary
Also Known As: Tag Image File Format
| Type | Bitmap |
| Colors | 1- to 24-bit |
| Compression | Uncompressed, RLE, LZW, CCITT Group 3 and Group 4, JPEG |
| Maximum Image Size | 2^32-1 |
| Multiple Images Per File | Yes |
| Numerical Format | See article for discussion |
| Originator | Aldus |
| Platforms | MS-DOS, Macintosh, UNIX, others |
| Supporting Applications | Most paint, imaging, and desktop publishing programs |
| See Also | Chapter 9, Data Compression (RLE, LZW, CCITT, and JPEG) |
Usage
Used for data storage and interchange. The general
nature of TIFF allows it to be used in any operating environment,
and it is found on most platforms requiring image data storage.
Comments
The TIFF format is perhaps the most versatile and diverse bitmap
format in existence. Its extensible nature and support for numerous data
compression schemes allow developers to customize the TIFF format to fit any peculiar data storage needs.
Vendor specifications are available for this format.
Code fragments are available for this format.
Sample images are available for this format.
The TIFF specification was originally released in 1986 by Aldus Corporation as a standard method of storing black-and-white images created by scanners and desktop publishing applications. This first public release of TIFF was the third major revision of the TIFF format, and although it was not assigned a specific version number, this release may be thought of as TIFF Revision 3.0. The first widely used revision of TIFF, 4.0, was released in April 1987. TIFF 4.0 added support for uncompressed RGB color images and was quickly followed by the release of TIFF Revision 5.0 in August 1988. TIFF 5.0 was the first revision to add the capability of storing palette color images and support for the LZW compression algorithm. (See the sidebar on LZW compression in the section called "Compression" later in this article.) TIFF 6.0 was released in June 1992 and added support for CMYK and YCbCr color images and the JPEG compression method. (See the section called "Color" in Chapter 2, Computer Graphics Basics, for a discussion of these color images. See Chapter 9, for a discussion of JPEG compression.)
Contents:
File Organization
File Details
For Further Information
Today, TIFF is a standard file format found in most paint, imaging, and desktop publishing programs and is a format native to the Microsoft Windows GUI. TIFF's extensible nature, allowing storage of multiple bitmap images of any pixel depth, makes it ideal for most image storage needs.
The majority of the description in this chapter covers the current TIFF revision 6.0. Because each successive TIFF revision is built upon the previous revision, most of the information present in this chapter also pertains to TIFF Revision 5.0 as well. And, although more images are currently stored in the TIFF 5.0 format than in any other revision of TIFF, quite a few TIFF 4.0 image files are still in existence. For this reason, information is also included that details the differences between the TIFF 4.0, 5.0, and 6.0 revisions.
TIFF has garnered a reputation for power and flexibility, but it is considered complicated and mysterious as well. In its design, TIFF attempts to be very extensible and provide many features that a programmer might need in a file format. Because TIFF is so extensible and has many capabilities beyond all other image file formats, this format is probably the most confusing format to understand and use.
A common misconception about TIFF is that TIFF files are not very portable between software applications. This is amazing considering that TIFF is widely used as an image data interchange format. Complaints include, "I've downloaded a number of TIFF clip art packages from some BBSs and my paint program or word processor is able to display only some of the TIFF image files, but not all of them," "When I try to display certain TIFF files using my favorite image display program, I get the error message `Unknown Tag Type' or `Unsupported Compression Type'," and "I have a TIFF file created by one application and a second application on the same machine cannot read or display the image, even though TIFF files created by the second application can be read and displayed by the first application."
These complaints are almost always immediately blamed on the TIFF image files themselves. The files are labeled "bad," because they have been munged during a data file transfer or were exported by software applications that did not know how to properly write a TIFF file. In reality, most TIFF files that do not import or display properly are not bad, and the fault usually lies, instead, with the program that is reading the TIFF file.
If an application only uses black-and-white images, it certainly does not need to support the reading and writing of color and gray-scale TIFF image files. In this case, the application should simply, and politely, refuse to read non-black-and-white TIFF image files and tell you the reason why. By doing this, the application would prevent the user from trying to read unusable image data and would also cut down on the amount of TIFF code the application programmers need to write.
Some applications that read TIFF image files--or any type of image files, for that matter--may just return an ambiguous error code indicating that the file could not be read, leaving the user with the impression that the TIFF file itself is bad (not that the application could not use the image data the TIFF file contained). Such an occurrence is the fault of the application designer in not providing a clearer message informing the user what has happened.
Sometimes, however, you may have an application that should be able to read a TIFF file, and it does not, even though the type of image data contained in the TIFF file is supported by the application. There are numerous reasons why a perfectly good TIFF file cannot be read by an application, and most of them have to do with the application programmer's lack of understanding of the TIFF format itself.
A major source of TIFF reader problems is the inability to read data regardless of byte-ordering scheme. The bytes in a 16-bit and 32-bit word of data are stored in a different order on little-endian architectures (such as the Intel iAPX86), than on big-endian machines (such as the Motorola MC68000A). Reading big-endian data using the little-endian format results in little more than garbage.
Another major source of problems is readers that do not support the encoding algorithm used to compress the image data. Most readers support both raw (uncompressed) and RLE-encoded data but do not support CCITT T.4 and T.6 compression. It is also surprising how many TIFF readers support the reading of color TIFF files, which are either stored as raw or RLE-compressed data, but do not support the decompression of LZW-encoded data.
Most other TIFF reader problems are quite minor, but usually fatal. Such problems include failure to correctly interpret tag data, no support for color-mapped images, or the inability to read a bitmap scan line that contains an odd number of bytes.
File Organization
TIFF files are organized into three sections: the Image File Header (IFH), the Image File Directory (IFD), and the bitmap data. Of these three sections, only the IFH and IFD are required. It is therefore quite possible to have a TIFF file that contains no bitmapped data at all, although such a file would be highly unusual. A TIFF file that contains multiple images has one IFD and one bitmap per image stored.
TIFF has a reputation for being a complicated format in part because the location of each Image File Directory and the data the IFD points to--including the bitmapped data--may vary. In fact, the only part of a TIFF file that has a fixed location is the Image File Header, which is always the first eight bytes of every TIFF file. All other data in a TIFF file is found by using information found in the IFD. Each IFD and its associated bitmap are known as a TIFF subfile. There is no limit to the number of subfiles a TIFF image file may contain.
Each IFD contains one or more data structures called tags. Each tag is a 12-byte record that contains a specific piece of information about the bitmapped data. A tag may contain any type of data, and the TIFF specification defines over 70 tags that are used to represent specific information. Tags are always found in contiguous groups within each IFD.
Tags that are defined by the TIFF specification are called public tags and may not be modified outside of the parameters given in the latest TIFF specification. User-definable tags, called private tags, are assigned for proprietary use by software developers through the Aldus Developer's Desk. See the TIFF 6.0 specification for more information on private tags.
Note that the TIFF 6.0 specification has replaced the term tag with the term field. Field now refers to the entire 12-byte data record, while the term tag has been redefined to refer only to a field's identifying number. Because so many programmers are familiar with the older definition of the term tag, the authors have choosen to continue using tag, rather than field, in this description of TIFF to avoid confusion.
Figure TIFF-1 shows three possible arrangements of the internal data structure of a TIFF file containing three images. In each example, the IFH appears first in the TIFF file. In the first example, each of the IFDs has been written to the file first and the bitmaps last. This arrangement is the most efficient for reading IFD data quickly. In the second example, each IFD is written, followed by its bitmapped data. This is perhaps the most common internal format of a multi-image TIFF file. In the last example, we see that the bitmapped data has been written first, followed by the IFDs. This seemingly unusual arrangement might occur if the bitmapped data is available to be written before the information that appears in the IFDs.
Figure TIFF-1: Three possible physical arrangements of data in a TIFF file
Each IFD is a road map of where all the data associated with a bitmap can be found within a TIFF file. The data is found by reading it directly from within the IFD data structure or by retrieving it from an offset location whose value is stored in the IFD. Because TIFF's internal components are linked together by offset values rather than by fixed positions, as with stream-oriented image file formats, programs that read and write TIFF files are often very complex, thus giving TIFF its reputation.
The offset values used in a TIFF file are found in three locations. The first offset value is found in the last four bytes of the header and indicates the position of the first IFD. The last four bytes of each IFD is an offset value to the next IFD. And the last four bytes of each tag may contain an offset value to the data it represents, or possibly the data itself.
NOTE:Offsets are always interpreted as a number of bytes from the beginning of the TIFF file.
Figure TIFF-2 shows the way data structures of a TIFF file are linked together.
Figure TIFF-2: Logical organization of a TIFF file
File Details
This section describes the various components of a TIFF file.
Image File Header
TIFF, despite its complexity, has the simplest header of all of the formats described in this book. The TIFF Image File Header (IFH) contains three fields of information and is a total of only eight bytes in length:
typedef struct _TiffHeader { WORD Identifier; /* Byte-order Identifier */ WORD Version; /* TIFF version number (always 2Ah) */ DWORD IFDOffset; /* Offset of the first Image File Directory*/ } TIFHEAD;
Identifier contains either the value 4949h (II) or 4D4Dh (MM). These values indicate whether the data in the TIFF file is written in little-endian (Intel format) or big-endian (Motorola format) order, respectively. All data encountered past the first two bytes in the file obey the byte-ordering scheme indicated by this field. These two values were chosen because they would always be the same, regardless of the byte order of the file.
Version, according to the TIFF specification, contains the version number of the TIFF format. This version number is always 42, regardless of the TIFF revision, so it may be regarded more as an identification number, (or possibly the answer to life, the universe, etc.) than a version number.
A quick way to check whether a file is indeed a TIFF file is to read the first four bytes of the file. If they are:
49h 49h 2Ah 00h
or:
4Dh 4Dh 00h 2Ah
then it's a good bet that you have a TIFF file.
IFDOffset is a 32-bit value that is the offset position of the first Image File Directory in the TIFF file. This value may be passed as a parameter to a file seek function to find the start of the image file information. If the Image File Directory occurs immediately after the header, the value of the IFDOffset field is 08h.
Image File Directory
An Image File Directory (IFD) is a collection of information similar to a header, and it is used to describe the bitmapped data to which it is attached. Like a header, it contains information on the height, width, and depth of the image, the number of color planes, and the type of data compression used on the bitmapped data. Unlike a typical fixed header, however, an IFD is dynamic and may not only vary in size, but also may be found anywhere within the TIFF file. There may be more than one IFD contained within any file. The format of an Image File Directory is shown in Figure TIFF-1.
One of the misconceptions about TIFF is that the information stored in the Image File Directory tags is actually part of the TIFF header. In fact, this information is often referred to as the "TIFF Header Information." While it is true that other formats do store the type of information found in the IFD in the header, the TIFF header does not contain this information. It is possible to think of the IFDs in a TIFF file as extensions of the TIFF file header.
A TIFF file may contain any number of images, from zero on up. Each image is considered to be a separate subfile (i.e., a bitmap) and has an IFD describing the bitmapped data. Each TIFF subfile can be written as a separate TIFF file or can be stored with other subfiles in a single TIFF file. Each subfile bitmap and IFD may reside anywhere in the TIFF file after the headers, and there may be only one IFD per image.
This may sound confusing, but it's not really. We have seen that the TIFF header contains an offset value that points to the location of the first IFD in the TIFF file. To find the first IFD, all we need do is seek to this offset and start reading the IFD information. The last field of every IFD contains an offset value to the next IFD, if any. If the offset value of any IFD is 00h, then there are no more images left to read in the TIFF file.
An IFD may vary in size, because it may contain a variable number of data records, called tags. Each tag contains a unique piece of information, just as fields do within a header. However, there is a difference. Tags may be added and deleted from an IFD much the same way that notebook paper may be added to or removed from a three-ring binder. The fields of a conventional header, on the other hand, are fixed and unmovable, much like the pages of this book. Also, the number of tags found in an IFD may vary, while the number of fields in a type header is fixed.
The format of an Image File Directory is shown in the following structure:
typedef struct _TifIfd { WORD NumDirEntries; /* Number of Tags in IFD */ TIFTAG TagList[]; /* Array of Tags */ DWORD NextIFDOffset; /* Offset to next IFD */ } TIFIFD;
NumDirEntries is a 2-byte value indicating the number of tags found in the IFD. Following this field is a series of tags; the number of tags corresponds to the value of the NumDirEntries field. Each tag structure is 12 bytes in size and, in the sample code above, is represented by an array of structures of the data type definition TIFTAG. (See the next section for more information on TIFF tags.) The number of tags per IFD is limited to 65,535.
NextIFDOffset contains the offset position of the beginning of the next IFD. If there are no more IFDs, then the value of this field is 00h.
Figure TIFF-3: Format of an Image File Directory
Tags
As mentioned in the previous section, a tag can be thought of as a data field in a file header. However, whereas a header data field may only contain data of a fixed size and is normally located only at a fixed position within a file header, a tag may contain, or point to, data that is any number of bytes in size and is located anywhere within an IFD.
The versatility of the TIFF tag pays a price in its size. A header field used to hold a byte of data need only be a byte in size. A tag containing one byte of information, however, must always be twelve bytes in size.
A TIFF tag has the following 12-byte structure:
typedef struct _TifTag { WORD TagId; /* The tag identifier */ WORD DataType; /* The scalar type of the data items */ DWORD DataCount; /* The number of items in the tag data */ DWORD DataOffset; /* The byte offset to the data items */ } TIFTAG;
TagId is a numeric value identifying the type of information the tag contains. More specifically, the TagId indicates what the tag information represents. Typical information found in every TIFF file includes the height and width of the image, the depth of each pixel, and the type of data encoding used to compress the bitmap. Tags are normally identified by their TagId value and should always be written to an IFD in ascending order of the values found in the TagId field.
DataType contains a value indicating the scalar data type of the information found in the tag. The following values are supported:
1 |
BYTE |
8-bit unsigned integer |
2 |
ASCII |
8-bit, NULL-terminated string |
3 |
SHORT |
16-bit unsigned integer |
4 |
LONG |
32-bit unsigned integer |
5 |
RATIONAL |
Two 32-bit unsigned integers |
The BYTE, SHORT, and LONG data types correspond to the BYTE, WORD, and DWORD data types used throughout this book. The ASCII data type contains strings of 7-bit ASCII character data, which are always NULL-terminated and may be padded out to an even length if necessary. The RATIONAL data type is actually two LONG values and is used to store the two components of a fractional value. The first value stores the numerator, and the second value stores the denominator.
The TIFF 6.0 revision added the following new data types:
6 |
SBYTE |
8-bit signed integer |
7 |
UNDEFINE |
8-bit byte |
8 |
SSHORT |
16-bit signed integer |
9 |
SLONG |
32-bit signed integer |
10 |
SRATIONAL |
Two 32-bit signed integers |
11 |
FLOAT |
4-byte single-precision IEEE floating-point value |
12 |
DOUBLE |
8-byte double-precision IEEE floating-point value |
The SBYTE, SSHORT, SLONG, and SRATIONAL data types are used to store signed values. The FLOAT and DOUBLE data types are used specifically to store IEEE-format single- and double-precision values. The UNDEFINE data type is an 8-bit byte that may contain untyped or opaque data and is typically used in private tags. An example of the use of this data type is to store an entire data structure within a private tag specifying the DataType as UNDEFINE (value of 7) and a DataCount equal to the number of bytes in the structure.
With the exception of the SMinSampleValue and SMaxSampleValue tags (which may use any data type), none of these newer data types is used by any TIFF 6.0 tags. They are therefore found only in private tags.
DataCount indicates the number of items referenced by the tag and doesn't show the actual size of the data itself. Therefore, a DataCount of 08h does not necessarily indicate that eight bytes of data exist in the tag. This value indicates that eight items exist for the data type specified by this tag. For example, a DataCount value of 08h and a DataType of 03h indicate that the tag data is eight contiguous 16-bit unsigned integers, a total of 32 bytes in size. A DataCount of 28h and a DataType of 02h indicate an ASCII character string 40 bytes in length, including the NULL-terminator character, but not any padding if present. And a DataCount of 01h and a DataType of 05h indicate a single RATIONAL value a total of eight bytes in size.
DataOffset is a 4-byte field that contains the offset location of the actual tag data within the TIFF file. If the tag data is four bytes or less in size, the data may be found in this field. If the tag data is greater than four bytes in size, then this field contains an offset to the position of the data in the TIFF file. Packing data within the DataOffset field is an optimization within the TIFF specification and is not required to be performed. Most data is typically stored outside the tag, occurring before or after the IFD (see Figure TIFF-3).
Table TIFF-1 lists all of the public tags included in the TIFF 4.0, 5.0, and 6.0 specifications. Note that some tags have become obsolete and are not found in the current revision of TIFF; however, we provide them because the TIFF 4.0 and TIFF 5.0 specs are still in some use. Also, note that several tags may support more than one data type.
In the table below, an asterisk (*) means that the tag is defined, a hyphen (-) means that the tag is not defined, and an "x" means that the tag is obsolete.
Tag Name | Tag ID | Tag Type | 4.0 | 5.0 | 6.0 |
|---|---|---|---|---|---|
Artist |
315 |
ASCII |
- |
* |
* |
BadFaxLines[1] |
326 |
SHORT or LONG |
- |
- |
- |
BitsPerSample |
258 |
SHORT |
* |
* |
* |
CellLength |
265 |
SHORT |
* |
* |
* |
CellWidth |
264 |
SHORT |
* |
* |
* |
CleanFaxData[1] |
327 |
SHORT |
- |
- |
- |
ColorMap |
320 |
SHORT |
- |
* |
* |
ColorResponseCurve |
301 |
SHORT |
* |
* |
x |
ColorResponseUnit |
300 |
SHORT |
* |
x |
x |
Compression |
259 |
SHORT |
* |
* |
* |
Uncompressed |
1 |
|
* |
* |
* |
CCITT 1D |
2 |
|
* |
* |
* |
CCITT Group 3 |
3 |
|
* |
* |
* |
CCITT Group 4 |
4 |
|
* |
* |
* |
LZW |
5 |
|
- |
* |
* |
JPEG |
6 |
|
- |
- |
* |
Uncompressed |
32771 |
|
* |
x |
x |
Packbits |
32773 |
|
* |
* |
* |
ConsecutiveBadFaxLines[1] |
328 |
LONG or SHORT |
- |
- |
- |
Copyright |
33432 |
ASCII |
- |
- |
* |
DateTime |
306 |
ASCII |
- |
* |
* |
DocumentName |
269 |
ASCII |
* |
* |
* |
DotRange |
336 |
BYTE or SHORT |
- |
- |
* |
ExtraSamples |
338 |
BYTE |
- |
- |
* |
FillOrder |
266 |
SHORT |
* |
* |
* |
FreeByteCounts |
289 |
LONG |
* |
* |
* |
FreeOffsets |
288 |
LONG |
* |
* |
* |
GrayResponseCurve |
291 |
SHORT |
* |
* |
* |
GrayResponseUnit |
290 |
SHORT |
* |
* |
* |
HalftoneHints |
321 |
SHORT |
- |
- |
* |
HostComputer |
316 |
ASCII |
- |
* |
* |
ImageDescription |
270 |
ASCII |
* |
* |
* |
ImageHeight |
257 |
SHORT or LONG |
* |
* |
* |
ImageWidth |
256 |
SHORT or LONG |
* |
* |
* |
InkNames |
333 |
ASCII |
- |
- |
* |
InkSet |
332 |
SHORT |
- |
- |
* |
JPEGACTTables |
521 |
LONG |
- |
- |
* |
JPEGDCTTables |
520 |
LONG |
- |
- |
* |
JPEGInterchangeFormat |
513 |
LONG |
- |
- |
* |
JPEGInterchangeFormatLength |
514 |
LONG |
- |
- |
* |
JPEGLosslessPredictors |
517 |
SHORT |
- |
- |
* |
JPEGPointTransforms |
518 |
SHORT |
- |
- |
* |
JPEGProc |
512 |
SHORT |
- |
- |
* |
JPEGRestartInterval |
515 |
SHORT |
- |
- |
* |
JPEGQTables |
519 |
LONG |
- |
- |
* |
Make |
271 |
ASCII |
* |
* |
* |
MaxSampleValue |
281 |
SHORT |
* |
* |
* |
MinSampleValue |
280 |
SHORT |
* |
* |
* |
Model |
272 |
ASCII |
* |
* |
* |
NewSubFileType |
254 |
LONG |
- |
* |
* |
NumberOfInks |
334 |
SHORT |
- |
- |
* |
Orientation |
274 |
SHORT |
* |
* |
* |
PageName |
285 |
ASCII |
* |
* |
* |
PageNumber |
297 |
SHORT |
* |
* |
* |
PhotometricInterpretation |
262 |
SHORT |
* |
* |
* |
WhiteIsZero |
0 |
|
* |
* |
* |
BlackIsZero |
1 |
|
* |
* |
* |
RGB |
2 |
|
* |
* |
* |
RGB Palette |
3 |
|
- |
* |
* |
Tranparency Mask |
4 |
|
- |
- |
* |
CMYK |
5 |
|
- |
- |
* |
YCbCr |
6 |
|
- |
- |
* |
CIELab |
8 |
|
- |
- |
* |
PlanarConfiguration |
284 |
SHORT |
* |
* |
* |
Predictor |
317 |
SHORT |
- |
* |
* |
PrimaryChromaticities |
319 |
RATIONAL |
- |
* |
* |
ReferenceBlackWhite |
532 |
LONG |
- |
- |
* |
ResolutionUnit |
296 |
SHORT |
* |
* |
* |
RowsPerStrip |
278 |
SHORT or LONG |
* |
* |
* |
SampleFormat |
339 |
SHORT |
- |
- |
* |
SamplesPerPixel |
277 |
SHORT |
* |
* |
* |
SMaxSampleValue |
341 |
Any |
- |
- |
* |
SMinSampleValue |
340 |
Any |
- |
- |
* |
Software |
305 |
ASCII |
- |
* |
* |
StripByteCounts |
279 |
LONG or SHORT |
* |
* |
* |
StripOffsets |
273 |
SHORT or LONG |
* |
* |
* |
SubFileType |
255 |
SHORT |
* |
x |
x |
T4Options[2] |
292 |
LONG |
* |
* |
* |
T6Options[3] |
293 |
LONG |
* |
* |
* |
TargetPrinter |
337 |
ASCII |
- |
- |
* |
Thresholding |
263 |
SHORT |
* |
* |
* |
TileByteCounts |
325 |
SHORT or LONG |
- |
- |
* |
TileLength |
323 |
SHORT or LONG |
- |
- |
* |
TileOffsets |
324 |
LONG |
- |
- |
* |
TileWidth |
322 |
SHORT or LONG |
- |
- |
* |
TransferFunction[4] |
301 |
SHORT |
- |
- |
* |
TransferRange |
342 |
SHORT |
- |
- |
* |
XPosition |
286 |
RATIONAL |
* |
* |
* |
XResolution |
282 |
RATIONAL |
* |
* |
* |
YCbCrCoefficients |
529 |
RATIONAL |
- |
- |
* |
YCbCrPositioning |
531 |
SHORT |
- |
- |
* |
YCbCrSubSampling |
530 |
SHORT |
- |
- |
* |
YPosition |
287 |
RATIONAL |
* |
* |
* |
YResolution |
283 |
RATIONAL |
* |
* |
* |
WhitePoint |
318 |
RATIONAL |
- |
* |
* |
Table Footnotes:
[1] Tags BadFaxLines, CleanFaxData, and ConsecutiveBadFaxLines are part of TIFF Class F now maintained by Aldus and are not actually defined by the TIFF 6.0 specification.
[2] Tag 292 was renamed from Group3Options to T4Options in TIFF 6.0.
[3] Tag 293 was renamed from Group3Options to T6Options by TIFF 6.0.
[4] Tag 301 was renamed from ColorResponseCurve to TransferFunction by TIFF 6.0.
Organization of TIFF Tag Data
To keep developers from having to guess which tags should be written to a TIFF file and what tags are important to read, the TIFF specification defines the concept of baseline TIFF images. These baselines are defined by the type of image data they store: bi-level, gray-scale, palette-color, and full-color. Each baseline has a minimum set of tags, which are required to appear in each type of TIFF file.
In the TIFF 5.0 specification, these baselines were referred to as TIFF classes. Each TIFF file consisted of a common baseline (Class X) and was modified by an additional class depending upon the type of image data stored. The classes were Class B (bi-level), Class G (gray-scale), Class P (palette-color), and Class R (full-color RGB).
The TIFF 6.0 specification redefines these classes into four separate baseline TIFF file configurations. Class X is combined with each of the other four classes to form the bi-level, gray-scale, color-palette, and full-color baselines. Although TIFF 6.0 largely does away with the concept of TIFF classes, it is likely that because more TIFF 5.0 format files exist than any other, TIFF files will be referred to by these class designations for many years to come.
It is worth mentioning that a de facto TIFF class, Class F, exists specifically for the storage of facsimile images using the TIFF format. This class of TIFF file, created by Cygnet Technologies, is used by Everex products to store facsimile data, and is also known as the Everex Fax File Format. Although Cygnet Technologies is no longer in business, TIFF Class F remains in use and is considered by some to be an excellent storage format for facsimile data.
Table TIFF-2 lists the minimum required tags that must appear in the IFD of each TIFF 6.0 baseline. Note that several of these tags have default values that are used if the tag does not actually appear in a TIFF file:
- Bi-level (formerly Class B) and gray-scale (formerly Class G) TIFF files must
contain the thirteen tags listed. These tags must appear in all revision 5.0
and 6.0 TIFF files regardless of the type of image data stored.
- Palette-color (formerly Class P) TIFF files add a fourteenth required tag
that describes the type of palette information found within the TIFF image
file.
- RGB (formerly Class R) TIFF files contain the same tags as bi-level TIFF
files and add a fourteenth required tag, which describes the format of the
bitmapped data in the image.
- YCbCr TIFF files add four additional tags to the baseline.
- Class F TIFF files add three tags.
Class Name | Tag Type | Tag Name |
|---|---|---|
Bi-level and |
254 |
NewSubfileType |
Gray-scale |
256 |
ImageWidth |
|
257 |
ImageLength |
|
258 |
BitsPerSample |
|
259 |
Compression |
|
262 |
PhotometricInterpretation |
|
273 |
StripOffsets |
|
277 |
SamplesPerPixel |
|
278 |
RowsPerStrip |
|
279 |
StripByteCounts |
|
282 |
XResolution |
|
283 |
YResolution |
|
296 |
ResolutionUnit |
|
||
The following classes contain the above 13 tags plus the following tags: |
||
|
||
Palette-color |
320 |
ColorMap |
RGB |
284 |
PlanarConfiguration |
YCbCr |
529 |
YCbCrCoefficients |
|
530 |
YCbCrSubSampling |
|
531 |
YCbCrPositioning |
|
532 |
ReferenceBlackWhite |
Class F |
326 |
BadFaxLines |
|
327 |
CleanFaxData |
|
328 |
ConsecutiveBadFaxLines |
All other tags found in the TIFF specification are available to meet developer's needs. While a TIFF reader must be able to support the parsing and interpretation of all tags it considers necessary, it is certainly not necessary for a TIFF writer to include as many tags as possible in every TIFF file written.
Image Data
TIFF files contain only bitmap data, although adding a few tags to support vector- or text-based images would not be a hard thing to do. As we have seen, the bitmapped data in a TIFF file does not always appear immediately after the image header, as with most other formats. Instead, it may appear almost anywhere within the TIFF file. And, because the majority of the work performed by a TIFF reader and writer is the creation and manipulation of the image data, a thorough understanding of how the image data is stored within a TIFF file is necessary, starting with the concept of strips.
NOTE:TIFF 6.0 images may contain tiles rather than strips.
Strips
It is always amusing to come across a TIFF reader or viewer whose author posts the caveat in the source code, "This TIFF reader does not support stripped images." A large proportion of TIFF readers who fail to read certain TIFF image files do so because the author of the reader did not quite understand the concept of how image data can be organized within a TIFF file. In this case, not only did the author of the reader fail to understand how to write code to read strips, he or she also failed to realize that every TIFF 5.0 (and earlier) image contains strips.
A strip is an individual collection of one or more contiguous rows of bitmapped image data. Dividing the image data into strips makes buffering, random access, and interleaving of the image data much easier. This concept exists in several other image file formats, and is given names such as blocks, bands, and chunks. TIFF strips differ from other such concepts in several important ways due to the structure of the TIFF format.
Three tags are necessary to define the strips of bitmapped data within a TIFF file. These three tags are RowsPerStrip, StripOffsets, and StripByteCounts.
The first required tag, RowsPerStrip, indicates the number of rows of compressed bitmapped data found in each strip. The default value for RowsPerStrip is 2^32-1, which is the maximum possible size of a TIFF image. All of the strips in a TIFF subfile must use the same compression scheme and have the same bit sex, color sex, pixel depth, and so on. To find the number of strips in a non-YCbCr subfile image, we would use the RowsPerStrip tag, the ImageLength tag, and the following calculation:
StripsInImage = floor((ImageLength * (RowsPerStrip - 1)) / RowsPerStrip);
The second required tag, StripOffsets, is important because without it a TIFF reader has absolutely no hope of locating the image data within a TIFF file. This tag contains an array of offset values, one per strip, which indicate the position of the first byte of each strip within the TIFF file. The first value in the array is for the first strip, the second value for the second strip, and so on. If the image data is separated into planes (PlanarConfiguration = 2), StripOffsets contains a 2D array of values, which is SamplesPerPixel in width. All of the columns for color component (plane) 0 are stored first, followed by all the columns for color component (plane) 1, and so forth. The strips of planar image data may be written to the TIFF file in any order but are typically written by plane (RRRRGGGGBBBB) or by color component (RGBRGBRGBRGB). StripOffsets values are always interpreted from the beginning of the file.
The StripOffsets tag allows each strip in a TIFF file to have a location that is completely independent from all other strips in the same subfile. This means that strips may occur in any order and be found anywhere within the TIFF file. Many "quick and dirty" TIFF readers find the beginning of the first strip and then attempt to read in the image data as one large chunk without checking the StripOffsets array for the position of each additional strip. This technique works if all the strips in the TIFF file are contiguously written to the TIFF file and are in the same consecutive order as the original rows in the bitmap. If the strips are stored out of sequence, perhaps in a planar or interlaced fashion, or are aligned on paragraph or page boundaries, the image data read will not be in its proper order, and the image will appear sliced up and rearranged on the display. If the strips are stored in a fairly random fashion, a large part of the data read might not be part of the image, or even the TIFF file itself. In this case, anything that is displayed would be mostly garbage.
The value of the RowsPerStrip tag and the size of each element in the array of the StripOffsets tag is usually a LONG (32-bit) value. TIFF 5.0 added the ability of this tag to use SHORT (16-bit) values instead. Very old TIFF readers may expect the values in this tag to always be LONG and will therefore read the offset values improperly if they are SHORT. This modification was made primarily for TIFF readers that read the StripOffsets values into an array in memory before using them. The TIFF 6.0 specification suggests that the offset values should not require such an array to be larger than 64K in size.
The third tag, StripByteCounts, maintains an array of values that indicates the size of each strip in bytes. And, like the StripOffsets tag, this tag is also an array of values, one per strip, 1D for chunky format and 2D for planar format, each of which is calculated from the number of bytes of compressed bitmapped data stored in each strip.
This tag is necessary because there are several cases in which the strips in an image may each contain a different number of bytes. The first case occurs when using compressed bitmapped image data. As we have said, the StripBytesCounts value is the size of the image data after it is compressed. Although there is a fixed number of bytes in an uncompressed row, the size of a compressed row varies depending upon the data it contains. Because we are always storing a fixed number of rows, not bytes, per strip, it is likely that most strips will be of different lengths because each compressed row will vary in size. Only when the bitmap data is not compressed will each strip be the same size.
Well, almost... The last strip in an image is sometimes an exception. TIFF writers typically attempt to create strips so that each strip in a TIFF image has the same number of rows. For example, a bitmap with 2200 rows can be divided into 22 strips, each containing 100 rows of bitmapped data. However, it is not always possible to divide the number of rows equally among the desired number of strips. For example, if we needed to divide a bitmap containing 482 rows into strips containing five rows each, we would end up with a total of 97 strips, 96 strips containing five rows of data and the 97th strip containing the remaining two rows. The RowsPerStrip tag value of 5 would be correct for all strip lengths except for the last strip.
The truth is that a TIFF reader does not need to know the number of rows in each strip to read the image data, only the number of bytes. Otherwise, the TIFF specification would require that every "short" strip be padded with additional rows of dummy data, but it doesn't. Instead, we simply read the last StripByteCounts value to determine how many bytes to read for the last strip. What the TIFF specification doesn't make clear is that the RowsPerStrip value specifies the maximum value, and not the required value, of the number of rows per strip. Many TIFF files, in fact, store a single strip of data and specify an arbitrarily large RowsPerStrip value.
There are several advantages to organizing bitmap data in strips.
First, not all applications can read an entire file into memory. Many desktop machines still have only one megabyte or less of memory available to them. And even if a system has gobs of memory, there is no guarantee that a TIFF reader will be able to use it. Such a TIFF reader can allocate the largest buffer it can manage and then read in the bitmapped data one strip at a time until the buffer is filled. If the image is panned or scrolled, data in the buffer can be discarded and more strips read in. If the entire image can fit in memory, all the strips in the TIFF file would then be read.
Because compressed strips can vary in size, the StripByteCounts values cannot be accurately used by an application to dynamically allocate a buffer in memory (unless every value is read and the largest value is used to allocate the buffer). Therefore, it is recommended that each strip be limited to about 8K in size. If a TIFF reader can allocate a much larger buffer than 8K, then multiple strips may be read into the buffer. Although TIFF strips can be larger, perhaps to support an image where each compressed or uncompressed row is greater than 8K in size, the size of a strip should never exceed 64K. Allocating a buffer greater than 64K can be a bit tricky when using certain system architectures.
Second, having access to a table of strip offsets makes random access of the bitmapped data easier. If a TIFF reader needed to display the last 100 rows of a 480-row image, and the bitmaps were divided into 48 strips of 10 rows each, the reader would skip over the first 380 rows and read in the strips stored at the last 10 offsets in the StripOffsets tag array. If no strip offsets were present, the entire image would need to be read to find the starting position of the last 100 rows.
And while it is possible that the bitmap in a TIFF file may be written out as one long strip--and many TIFF files are written this way--it is not a good idea to do so. These so-called unstripped images often fail because an application must attempt to allocate enough memory to hold the entire image. For large images, or small systems, enough memory may not be available. One can only hope that a TIFF file reader would exit from such a situation gracefully.
Tiles
Strips are not the only possible way to organize bitmapped data. TIFF 6.0 introduced the concept of tiled, rather than stripped, bitmapped data. A strip is a 1D object that only has a length. A tile can be thought of as a 2D strip that has both width and length, very similar to a bitmap. In fact, you can think of each tile in an image as a small bitmap containing a piece of a larger bitmap. All you need to do is fit the tiles together in their proper locations to get the image. (This concept only serves to remind me that I must replace the linoleum in my bathroom one day.)
Dividing an image into rectangular tiles rather than horizontal strips has the greatest benefit on very large high-resolution images. Many electronic document imaging (EDI) applications cannot manipulate images larger than E size (6848 pixels wide by 8800 pixels long) because of the large amount of memory required to buffer, decompress, and manipulate even a few hundred rows of image data. Even if you just wanted to display the upper-left corner of an image you would still be forced to decompress the entire strip and maintain it in memory. If the image data were tiled, however, you would only decompress the tiles that contained the image data for the part of the image you wanted to display.
Many compression algorithms, such as JPEG, compress data not as 1D strips, but instead as 2D tiles. Storing the compressed data as tiles optimizes the decompression of the data quite a bit. In fact, the support of 2D compression algorithms is perhaps the primary reason why the capability of tiling image data was added to TIFF 6.0.
When tiles are used instead of strips, the three strip tags, RowsPerStrip, StripByteCounts, and StripOffsets, are replaced by the tags TileWidth, TileLength, TileOffsets, and TileByteCounts. As you might have guessed, the tile tags are used in much the same way that the strips tags are. And, like strips, tiles are either all uncompressed, or all compressed using the same scheme. Also, TIFF images are either striped or tiled, but never both.
TileWidth and TileLength describe the size of the tiles storing the image data. The values of TileWidth and TileLength must be a multiple of 16, and all tiles in a subfile are always the same size. These are important compatibility considerations for some applications, especially when using the tile-oriented JPEG compression scheme. The TIFF 6.0 specification recommends that tiles should contain 4K to 32K of image data before compression. Finally, tiles need not be square. Rectangular tiles compress just as well.
The TileWidth and TileLength tag values can be used to determine the number of tiles in non-YCbCr image subfiles:
TilesAcross = (ImageWidth + (TileWidth - 1)) / TileWidth; TilesDown = (ImageLength + (TileLength - 1)) / TileLength; TilesInImage = TilesAcross * TilesDown;
If the image is separated into planes (PlanarConfiguration = 2), the number of tiles is calculated like this:
TilesInImage = TilesAcross * TilesDown * SamplesPerPixel;
The TileOffsets tag contains an array of offsets to the first byte of each tile. Tiles are not necessarily stored in a contiguous sequence in a subfile. Each tile has a separate location offset value and is independent of all other tiles in the subfile. The offsets in this tag are ordered left-to-right and top-to-bottom. If the image data is separated into planes, all of the offsets for the first plane are stored first, followed by the offsets for the second plane, and so on. The number of offset values in this tag are equal to the number of tiles in the image (PlanarConfiguration = 1) or the number of tiles multiplied by the SamplesPerPixel tag value (PlanarConfiguration = 2). All offset values are interpreted from the beginning of the TIFF file.
The final tag, TileByteCounts, contains the number of bytes in each compressed tile. The number of values in this tag is also equal to the number of tags in the image, and the values are ordered the same way as the values in the TileOffsets tag.
Normally, a tile size is chosen that fits an image exactly. An image 6400 pixels wide by 4800 pixels long may be divided evenly into 150 tiles, each 640 pixels wide by 320 pixels long. However, not all image dimensions are divisible by 16. An image 2200 pixels wide by 2850 long cannot be evenly divided into tiles whose size must be multiples of 16. The solution is to choose a "best-fit" tile size and fill out the image data with padding.
To find a best-fit tile size, we must choose a tile size that minimally overlaps the size of the image. In this example, we want to use tiles that are 256 pixels wide by 320 pixels long, roughly the same aspect ratio as the image. Using tiles this size requires that 104 extra pixels of padding be added to each row and that 30 additional rows be added to the image length. The size of the image data plus padding is now 2304 pixels wide by 2880 pixels long and can be evenly divided among 81 of our 256 by 320 pixel tiles.
In this example, you may notice that the total amount of padding added to the image before tiling is 365,520 pixels. For a 1-bit image, this equals an extra 45,690 bytes of image data. No appreciable gain in compression results from tiling small images. Also, avoid using tiles that are excessively large and require excessive amounts of padding.
Compression
TIFF supports perhaps more types of data compression than any other image file format. It is also quite possible to use an unsupported compression scheme just by adding the needed user-defined tags. TIFF 4.0 supported only Run-Length Encoding (RLE) and CCITT T.4 and T.6 compression. These compression schemes are typically only for use with 8-bit color, and gray-scale and 1-bit black-and-white images, respectively. TIFF 5.0 added the LZW compression scheme, typically for color images, and TIFF 6.0 added the JPEG compression method for use with continuous-tone color and gray-scale images. (All of these data compression schemes, including a variety of RLE algorithms, are discussed in Chapter 9.)
LZW Is Not Free If you are creating or modifying software that implements the LZW algorithm, be aware that under certain circumstances, you will need to pay a licensing fee for the use of LZW.
Unisys Corporation owns the patent for the LZW codec (encoding/decoding algorithm) and requires that a licensing fee be paid for each software program which implements the LZW algorithm.
Many people have concluded that the Unisys licensing claim applies only to LZW encoders (software that creates LZW data) and not to LZW decoders (software that only reads LZW data). However, Unisys believes that its patent covers the full LZW codec and requires a licensing fee even for software that reads, but does not write, LZW data.
For more information about the entire issue of LZW licensing, refer to the section called "LZW Legal Issues" in Chapter 9. For a popular alternative to graphics file formats that use LZW, consider using the Portable Network Graphics (PNG) file format.
TIFF uses the PackBits RLE compression scheme found in the Macintosh toolbox. PackBits is a simple and effective algorithm for compressing data and is easy to implement. The name "PackBits" would lead a programmer to believe that it is a bit-wise RLE, packing runs of bits. However, PackBits is a byte-wise RLE and is most efficient at encoding runs of bytes.
PackBits actually has three types of data packets that may be written to the encoded data stream. The first is a two-byte encoded run packet. The first byte (the run-count byte) indicates the number of bytes in the run, and the second byte stores the value of each byte in the run. The actual run-count value stored is in the range 0 to 127 and represents the values 1 to 128 (run count + 1).
Another type of packet, the literal run packet, stores 12 to 128 bytes literally in the encoded data stream without compressing them. Literal run packets are used to store data with very few runs, as found in very complex or noisy images. The literal run packet's run count is in the range of -127 to -1, indicating that 2 to 128 run values (-(run count) + 1) follow the run count byte.
The last type of packet is the no-op packet. No-ops are one byte in length and have a value of -128. The no-op packet has no use in the PackBits compression scheme and is therefore never found in PackBits-encoded data.
Decompressing PackBits-encoded data is a simple matter of reading a packet of encoded data and converting it to the appropriate byte run. Once again, the run-count byte value is stored one less than the actual number of bytes in the run. It is therefore necessary to add one to the run-count value before using it.
Refer to the TIFF 6.0 specification for more information on PackBits compression, and to Chapter 9, for more information on RLE algorithms.
NOTE: Problems with TIFF 6.0 JPEGCommentary by Dr. Tom Lane of the Independent JPEG Group, a member of the TIFF Advisory Committee
TIFF 6.0 added JPEG to the list of TIFF compression schemes. Unfortunately, the approach taken in the 6.0 specification is a very poor design. A new design has been developed by the TIFF Advisory Committee. If you are considering implementing JPEG in TIFF, I strongly urge you to follow the revised design described in TIFF Tech Note #2 rather than that of the 6.0 spec.
The fundamental problem with the TIFF 6.0 JPEG design is that JPEG's various tables and parameters are broken out as separate fields, which the TIFF control logic must manage. This is bad software engineering--that information should be private to the JPEG compressor/decompressor. Worse, the fields themselves are specified without thought for future extension and without regard to well-established TIFF conventions. Here are some of the more significant problems:
- The JPEG table fields use a highly nonstandard layout: rather than containing data directly in the field structure, the fields hold pointers to information elsewhere in the file. This requires special-purpose code to be added to every TIFF-manipulating application. Even a trivial TIFF editor (for example, a program to add an ImageDescription field to a TIFF file) must be explicitly aware of the internal structure of the JPEG-related tables, or it will probably break the file. Every other auxiliary field in TIFF follows the normal TIFF rules and can be copied or relocated by standard code.
- The specification requires the TIFF control logic to know a great deal about JPEG details--for example, such arcana as how to compute the length of a Huffman code table. The length is not supplied in the field structure and can be found only by inspecting the table contents.
- The design specifies separate Huffman tables for each color component. This neglects the fact that baseline JPEG codecs may support only two sets of Huffman tables. Thus, an encoder must either waste space (by storing duplicate Huffman tables) or violate the TIFF convention that prohibits duplicate pointers. Furthermore, baseline decoders must test to see which tables are identical--a waste of time and code space.
- The JPEGInterchangeFormat field again violates the proscription against duplicate pointers; it envisions having the normal strip/tile pointers pointing into the larger data area pointed to by JPEGInterchangeFormat. TIFF editing applications must be specifically aware of this relationship, because they must maintain it or, if they can't, must delete the JPEGInterchangeFormat field.
- The JPEGQTables field is fixed at a byte per table entry; there is no way to support 16-bit quantization values. This is a serious impediment to extending TIFF to use 12-bit JPEG.
- The design cannot support using different quantization tables in different strips/tiles of an image (so as to encode some areas at higher quality than others). Furthermore, because quantization tables are tied one-for-one to color components, the design cannot support table switching options that are likely to be added in future JPEG extensions.
In addition to these major design errors, the TIFF 6.0 JPEG specification is seriously ambiguous. In particular, several incompatible interpretations are possible for its handling of JPEG restart markers, and Section 22, "JPEG Compression," actually contradicts Section 15, "Tiled Images," about the restrictions on tile sizes.
Finally, the 6.0 design creates problems for implementations that need to keep the JPEG codec separate from the TIFF control logic--consider using a JPEG chip that was not designed specifically for TIFF. JPEG codecs generally want to produce or consume a standard JPEG datastream, not just raw data. (If they do handle raw data, a separate out-of-band mechanism must be provided to load tables into the codec.) With such a codec, the TIFF control logic must be prepared to parse JPEG markers to create the TIFF table fields (when encoding) or to synthesize JPEG markers from the fields (when decoding). Of course, this means that the control logic must know a great deal more about JPEG than we would like. The parsing and reconstruction of the markers also represents a fair amount of unnecessary work.
Due to all these problems, the TIFF Advisory Committee has developed a replacement JPEG-in-TIFF scheme. The rough outline is as follows:
- Each image segment (strip or tile) in a JPEG-compressed TIFF image contains a legal JPEG datastream, complete with all markers. This data forms an independent image of the proper dimensions for the strip or tile.
- To avoid duplicate tables in a multi-segment file, segments may use the JPEG "abbreviated image data" datastream structure, in which DQT and DHT tables are omitted. The common tables are to be supplied in a JPEG "abbreviated table specification" datastream, which is contained in a newly defined "JPEGTables" TIFF field. Because the tables in question typically amount to 550 bytes or so, the savings are worthwhile.
- All the field definitions in the existing Section 22, "JPEG Compression," are deleted. (In practice, those field tag values will remain reserved indefinitely, and this scheme will use a new Compression code, Compression = 7. Implementations that have TIFF 6.0-style files to contend with may continue to read them, using whatever interpretation of 6.0 they used before.)
This replacement design is described in TIFF Tech Note #2. The Tech Note is currently being distributed in draft form, because Adobe has not yet formally accepted it. However, I expect that the Note will be accepted as is, and that the design it describes will replace the existing Section 22 when version 7.0 of the TIFF spec is released.
If you are considering implementing JPEG in TIFF, please use the design of the Tech Note. The 6.0 JPEG design has not been widely implemented, and with any luck it will stay that way.
For Further Information
For further information about the TIFF format, see the specification.
TIFF was formerly maintained by the Aldus Developer's Association. Aldus has recently merged with Adobe Systems, which now holds the copyright to the TIFF specification and administers and maintains the TIFF format.
All information on the TIFF format may now be obtained through the Adobe Developer Support group. However, this group supplies only general TIFF information and does not provide any TIFF tutoring, sample TIFF source code, or sample TIFF files. Contact the Adobe Developer Support group, at<EMAIL_ADDRESS>Questions about the the Adobe Developer's Association should be directed to:
Adobe Developer's Association
1585 Charleston Road
P.O. Box 7900
Mountain View CA 94039-7900
Voice:<PHONE_NUMBER>
FAX:<PHONE_NUMBER>
FTP: ftp://ftp.adobe.com
WWW: http://www.adobe.com/Support/ADA.html
BBS:<PHONE_NUMBER>
Adobe distributes the TIFF 6.0 specifiction in PDF format in the "Technical Notes for Developers" section on the Adobe homepage, at:
http://www.adobe.com/Support/TechNotes.html#tiff
http://www.adobe.com/PDFs/TN/TIFF6.pdf
or on the Adobe FTP server:
ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/TechNotes/PDFfiles/TIFF6.pdf
or in paper form for $25US by calling 1-800-831-6395.
TIFF support in Europe may be obtained via email or from Adobe's BBS in Edinburgh, Scotland:
Email<EMAIL_ADDRESS>BBS: +44<PHONE_NUMBER>
The Adobe Acrobat reader for PDF files may be obtained for free from:
ftp://ftp.adobe.com/pub/adobe/Applications/Acrobat/
Technical information on Aldus products, including the TIFF Class F specification, is available from Adobe's Automated Technical Support for Aldus Products FAXback service in which information may be requested automatically via a FAX machine. This service may be reached at<PHONE_NUMBER> (toll-free), or<PHONE_NUMBER>.
You will also find useful TIFF information and tools at:
ftp://ftp.sgi.com/textonly/tiff/ (maintained by Sam Leffler)
http://www-mipl.jpl.nasa.gov/~ndr/tiff/textonly.html (maintained by Niles Ritter)
See the following references for more information about TIFF:
Aldus Corporation. TIFF Developer's Toolkit, Revision 5.0. Seattle, WA, November 1988.
Aldus Corporation. TIFF Developer's Toolkit, Revision 6.0, Seattle, WA, June 1992.
Aldus Corporation. Aldus Developer News, Seattle, WA.
Campbell, Joe. The Spirit of TIFF Class F, Cygnet Technologies, Berkeley, CA. April 1990.
Hewlett-Packard Company. HP TIFF Developer's Manual, Greeley, CO, November 1988.
Katz, Alan, and Danny Cohen, "RFC 1314: A File Format for the Exchange of Images in the Internet," USC Information Sciences Institute, Marina Del Rey, CA, April 1992.
This document outlines the use of TIFF as a standard format for exchanging facsimile images within the Internet.
Murray, James. "TIFF File Format," C Gazette, Winter 1990-91, pp. 27-42.
RFC 804, "Standardization of Group 3 Facsimile Apparatus for Document Transmission."
This document is a draft of the CCITT Recommendation T.4 explaining the CCITT Group 3 encoding scheme used by TIFF.
This page is taken from the Encyclopedia of Graphics File Formats and is licensed by O'Reilly under the Creative Common/Attribution license.


System Architect Definitions, Encyclopedia:"D:\DATA\SYSARCH\HCM\GEN_DATA\SUBJECT\V01\CURRENT\"
collector (Association)
- From Class:
"Standard Heading Set"
- To Class:
"Standard Heading"
Completed Activity (Class)
- Description:
"Activity" which has ended normally and for which no further work is intended.
- Comment:
-
An end state.
Note that a repetitive activity may be deemed complete even though not all its actual or potential
components have been identified.
- Source:
post-CBS
- State Type:
F
- &Abstract:
F
- Value:
F
completion timepoint (Association)
- From Class:
Timepoint
- To Class:
"State Change Activity"
Complication (Object)
- Class:
Category
- Definitions Used:
-
Category (Class)
Component Subject Relation (Class)
- Description:
-
"Partitive Subject Relation" where a "Subject" forms part of the other as a component and may not
exist as a component in another "Component Subject Relation" at the same time.
- Comment:
-
There are four types of COMPONENT SUBJECT RELATION:
* That where both the component and the assembly SUBJECTS can continue their existence and may
be reused after the destruction of the relation;
* That where neither the component nor any assembly SUBJECT can continue their existence after
the destruction of the relation;
* That where the component SUBJECTS can continue their existence after the destruction of the
relation but the assembly cannot;
* That where the assembly SUBJECT can continue its existence after the destruction of the
relation but the components cannot function as designed.
- Examples:
-
First type: The front off side wheel on car J76 VFA.
Second type: Lenin's brain
Third type: An orange and its segments
Fourth type: Dave Jones' left index finger.
- Source:
post-CBS
- State Type:
F
- &Abstract:
F
- Value:
F
component (Association)
- From Class:
"Classification Element"
- To Class:
"Classification In Version"
Compound Fracture (Object)
- Class:
Category
- Definitions Used:
-
Category (Class)
Concept/Essential Type (Gen-Spec Arc)
- Base Class:
Concept
- Open:
F
- Definitions Used:
-
Concept (Class)
Concept (Class)
- Description:
"Object" which is a unit of thought.
- Source:
CBS V2 Gen
- Previous name:
CONCEPT
- State Type:
F
- &Abstract:
F
- Value:
F
concept (Association)
- From Class:
Concept
- To Class:
"Agent's Term For Concept"
Contact Method (Class)
- Description:
"Category" describing a "Subject Contact".
- Comment:
-
The population of this includes:
Postal address
Telephone number (landline / mobile)
Fax number
Email address
Telex number
Bleeper number.
- Source:
CBS V2 Gen
- State Type:
F
- &Abstract:
F
- Value:
F
contact (Association)
- From Class:
"Subject Contact"
- To Class:
"Preferred Contact For Subject"
Context Activity (Class)
- Description:
"Activity" acting as a context for one or more other "Activities".
- Comment:
-
The context activity may be generated before the component activities exist.
Common types of Context Activity are:
Consultant Episode
Ward Stay
Consultation
Out Patient Attendance
Case Conference.
Note that Context Activities may themselves be components of other Context Activities.
- Source:
HcM QA
- State Type:
F
- &Abstract:
F
- Value:
F
context (Association)
- From Class:
"Context Activity"
- To Class:
"Activity In Context"
context (Association)
- From Class:
"Classification System Version"
- To Class:
"Classification In Version"


By enabling strict mode the programer are not allowed to use some error prone js features!
Older than ES5 engines will not use the restrictions that the strict mode offers.
If you see the following error in your browsers debugging mode:
than your js version is using strict mode successfully!
strict mode Wiki


---
subject: Connect with Influential Moms & Bloggers at WOW Summit Chicago!
---
This exciting event brings influential Moms together for a two-day conference to learn more about natural, organic, and eco living, as well as the products and services that help them raise healthier families.
Friday is for Mom Bloggers who will attend educational blogging workshops. They will also have the chance to network with you, the brands they love, and experience exclusive blogger-only time in the Exhibit Hall.
On Saturday, our moms will hear directly from healthy- living and parenting experts. Then, they’ll have the opportunity to sample your products when they visit the Exhibit Hall.
Sponsorship opportunities include:
Sponsorships start at just $1,500


- Sort Order:
- Write In:
- Image URL:
3 Candidates
| ID | Name | Party |
|---|---|---|
| 310007675 | Barack Obama | DEM |
| 310007676 | Mitt Romney | REP |
| 310007677 | Gary Johnson | LIB |
Option for Referendum
Referendum ID: 90011
- Title:
- Proposition 37
- Subtitle:
- A referendum to ban smoking indoors
- Brief:
- A yes vote is a vote to ban smoking indoors.
- Text:
- Shall the State of Ohio ... (full text of referendum as it appears on the ballot).
- Pro Statement:
- Vote yes please
- Con Statement:
- Vote no please
- Passage Threshold:
- three-fifths
- Effect Of Abstain:
- Abstaining has no effect
- Informational Url:
- Sort Order:
| ID | Text |
|---|---|
| 120001 | Yes |
| 120002 | No |
Option for Custom Ballot
Custom Ballot ID: 90012
- Heading:
- Should Judge Carlton Smith be retained?
- Sort Order:
| ID | Text |
|---|---|
| 120001 | Yes |
| 120002 | No |


{% extends "base.html" %} {% import "bootstrap/wtf.html" as wtf %} {% import "bootstrap/fixes.html" as fixes %} {% import "bootstrap/utils.html" as util %} {% block title %}Network Catalog{% endblock %} {% block head %} {{ super() }} {% endblock %} {% block styles %} {{ super() }} {% endblock %} {% block scripts %} {{ super() }} {% endblock %} {% block content %}
Each curated network is backed by a BEL script. Below are options to summarize the networks' contents{% if 'analysis' in blueprints %},{% else %} or{% endif %} explore them with an in-browser navigator{% if 'analysis' in blueprints %}, or run analyses with data sets such as differential gene expression data {% endif %}. {% if 'parser' in blueprints %} Upload more networks here.{% endif %}
{{ network.description }}
{% endif %}


Welcome... Under construction.
abc def ghi jkl mno pqrs tuv wxyz ABC DEF GHI JKL MNO PQRS TUV WXYZ !
"§ $%& /() =? * '|; ²³~ @`´ ©«» ¤¼× {} abc def ghi jkl mno pqrs tuv wxyz ABC DEF GHI JKL MNO PQRS TUV WXYZ !
- “Life is too short to be little.” — Benjamin Disraeli
- “When one tugs at a single thing in nature, he finds it attached to the rest of the world.” — John Muir
- “By attempting the impossible one can attain the highest level of the possible.” — August Strindberg
- “Not failure, but low aim, is crime.” — James Russell Lowell
- “On ne doit pas juger un homme par ses grandes qualités, mais par l'usage qu'il sait en faire.” — Jean de La Bruyère
- “The defect of equality is that we desire it only with our superiors.” — Henry Becque
- “We carry within us the wonders we seek without us.” — Thomas Browne
- “Nature does not hurry, yet everything is accomplished.” — Lao Tzu
- “No snowflake in an avalanche ever feels responsible.” — Voltaire
- “A friend made is a road paved; an enemy created is a wall built.” — Chinese proverb
- “The real voyage of discovery consists not in seeking new landscapes, but in having new eyes.” — Marcel Proust


Taycan 4S
MSRP $ 119,400
Price
4.0s
Acceleration 0 - 100 km/h with Launch Control
522hp
Overboost Power with Launch Control up to (hp)
250km/h
Top speed
| Power Unit | Motor |
| Power up to (kW) (Performance Battery) | 320kW |
| (Performance Battery Plus) | Overboost |
| (Performance Battery Plus) | 479 lb-ft |


Welcome to the census
{{releaseVersion | log }}Welcome to RH - draft prototype for internal discussion on what to include and key information
There's a different form to fill in the census for Communal Establishments or
if you need an Individual form
Placeholder text - below to start the census


Notes from Course 0
History of HTML (hypertext markup language): invented in 1990s
You (browser) <=> Internet <=> Servers (via HTTP)
HTML consists of:
Text content (what you see)
Markup (what it looks like)
References to other documents
Links to other pages
Tags (opening and closing)
Opening Tag: <NAME>
Closing Tag: </NAME>
Elements: String of text includings tags and content
Other tags:
 = bold
 = italics
HTML Attributes
<TAG ATTR = "value"> content </TAG>
Anchors: links
 content
 (VOID tag)
Void Tags: tags that do not require closing tag
Whitespace

 = break (VOID tag)

 = paragraph
Inline vs. Block tags
Inline - work within existing text (bold, italics, line breaks, etc.)
Block - create imaginary box that contains everything until closing tag
(paragraph, form, div, etc.)
HTML Document Example
<! DOCTYPE HTML>

<title> TITLE! </title>

Contents


{% extends "customers/base.html" %} {% block content %}
Hi. This looks like the first time you've logged into a Parks and Wildlife site as {{ user.email }}! We just need a couple more details before we can continue on.
If you already have a Parks and Wildlife customer account under another email address, please sign in again with that account and instead add {{ user.email }} as a secondary email address.
{% endblock %}


WURFL is a continuously updated device description repository that utilizes sophisticated parsing logic and statistical analysis to properly handle false positives and incorrect information passed by the browser.
WURFL stands for Wireless Universal Resource FiLe. It "maps HTTP request headers to the profile of the HTTP client that issued the request", (wurfl.sourceforge.net).
Scientiamobile has written a publicly accessible page for testing browser and device capabilities using just a query string.


Handde1096.github.io
Precor Vitality Series Selectorized Line Handbuch.
Precor Vitality Series Selectorized Line Handbuch and Sangean Wr-12Bt Bedienungsanleitung.