10 
Practice Tip: A requesting party shouldn’t wait until the response date to learn if an 
opponent refuses to furnish the forms sought.  Press for a commitment; and if one is not 
forthcoming, move to compel ahead of the response date.  Don’t wait to hear the Court 
say, “Why didn’t you raise this before they spent all that money?” 
Texas was the first state to enact rules of procedure dealing with ESI.  Texas Rules of Civil 
procedure Rule 196.4 went into effect in 1999, seven years before the Federal e-discovery rules 
emerged.  Accordingly, Texas practice diverges from federal practice when it comes to form of 
production.  Rule 196.4 states,  
To obtain discovery of data or information that exists in electronic or magnetic 
form, the requesting party must specifically request production of electronic or 
magnetic data and specify the form in which the requesting party wants it 
produced.  The responding party must produce the electronic or magnetic data that 
is responsive to the request and is reasonably available to the responding party in 
its ordinary course of business.  If the responding party cannot – through 
reasonable efforts – retrieve the data or information requested or produce it in the 
form requested, the responding party must state an objection complying with these 
rules.  If the court orders the responding party to comply with the request, the court 
must also order that the requesting party pay the reasonable expenses of any 
extraordinary steps required to retrieve and produce the information.  
Under Texas practice, the requesting party’s specified form of production is afforded more 
weight than in federal courts.  Production in specified forms that are available to a responding 
party in the ordinary course of business is mandatory, unless such production cannot be 
accomplished despite reasonable efforts.  The primary relief available to a producing party is not 
the use of an alternative form of production but, instead, the right to obtain mandatory cost 
shifting for extraordinary steps required to produce in the requested form.   
Thus, under Texas jurisprudence, a request for production in the forms in which the responding 
party uses the information in the ordinary course of business seems both least likely to be 
objectionable and least likely to prompt cost shifting.  Nevertheless, it can be daunting to help 
courts (and opponents) whose only exposure to e-discovery has been to imaged productions 
appreciate that imaged formats require extraordinary steps to generate and produce, where 
native forms are easiest to retrieve and produce. 
E. D. Fogg, a veteran trial lawyer, brought a diversity action in the Western District of Texas 
against Huevos & Huevos (H&H), manufacturer of a medical device called trans-testicular mesh 
Texas Practice re: Forms of Production 
Onward through the Fogg: Learning the Language of Forms 
Pdf merge documents - Merge, append PDF files in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Provide C# Demo Codes for Merging and Appending PDF Document
attach pdf to mail merge in word; merge pdf online
Pdf merge documents - VB.NET PDF File Merge Library: Merge, append PDF files in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
VB.NET Guide and Sample Codes to Merge PDF Documents in .NET Project
pdf merge comments; acrobat merge pdf files
11 
used to treat scrotal droop.  Citing mesh migration causing pain, disfigurement and marked 
increase in vocal pitch, the suit seeks damages for Fogg’s clients and others similarly situated.
6
Fogg has handled several medical device liability claims over his long career but lacks 
experience with e-discovery.  In the past, he sought paper production or had his staff print things 
out.  But he’s gone to some CLE programs that counseled him to get electronically searchable 
ESI, and he has decided to give it a go. 
Recently, Fogg attended a Rule 26(f) “Meet ‘n Confer.”  He made all the right grunts and signs to 
convey to opposing counsel that he wanted electronically searchable production.   But as neither 
knew how they might achieve such a miracle, they shared a deer-in-headlights moment, 
followed by the usual “let me check with my client and get back to you” feint.
7
Some days later, Fogg received a letter from opposing counsel stating: 
Documents will be produced as single page TIFF files with multi-page extracted text or 
OCR.  We will furnish delimited IPRO or Opticon load files and will later identify fielded 
information we plan to exchange.  
Fogg sought out Jennifer Xavier, a young associate at the Fogg firm.  Jen was hired to help 
usher the firm into the 21
st
century and “make sure we do the e-stuff right.”  Jen is finding that 
change doesn’t come easy.   
Fogg handed Jen the document and bluntly asked, “Are they trying to screw me?”  
Jen glanced at the proposal and replied, “Are they trying to screw you?  Probably not. But are 
you screwing yourself by accepting the proposed form of production?  Yes, probably.´ 
She went on to explain the proposal in plain English. 
“Documents will be produced as single page TIFF files . . . .” 
They are not offering you the evidence in anything like the form in which they created and 
used the evidence.  Instead, they propose to print everything to a kind of electronic paper, 
turning searchable, metadata-rich evidence into non-searchable pictures of much (but not 
all) of the source document.  These pictures are called TIFFs, an acronym for Tagged 
Image File Format.  “Single page TIFF” means that each page of a document will occupy 
its own TIFF image, so reading the document will require loading and reviewing multiple 
6
All of this nonsense is intended to be fictional.  Any resemblance to any real person, company, product 
or scrotum is unintended and coincidental. 
7
Some years back, I defined a Rule 26(f) conference as, “Two lawyers who don’t trust each other 
negotiating matters neither understand.”  That definition seems to have withstood the test of time. 
C# XDoc.HTML5 Viewer- Supported File Formats
FREE TRIAL: HOW TO: XDoc.HTML5 Viewer for C#▶: C# ASP.NET: View documents; C# ASP.NET PDF to HTML; C#: Convert PDF to Jpeg; C# File: Compress PDF; C# File: Merge
add pdf together; pdf mail merge
C# Word - Merge Word Documents in C#.NET
C# Word - Merge Word Documents in C#.NET. Provide C# Demo Codes for Merging and Appending Word Document. Overview. RasterEdge C#.NET
c# merge pdf pages; pdf combine two pages into one
12 
images (as compared to, e.g., a PDF document where the custom is for the entire 
document to be contained within one multi-page image). 
If you ever pithed a frog in high school biology, you know what it’s like to TIFF a native 
document.  Converting a native document to TIFF images is lobotomizing the 
document.  By “native,” I mean that the file that contains the document is in the same 
electronic format used by the software application that created the file.  For example, the 
native form of a Microsoft Word document is typically a file with the extension .DOC or 
.DOCX.  For a Microsoft Excel spreadsheet, it’s a file with the extension .XLS or 
.XLSX.  For PowerPoints, the file extensions are .PPT or .PPTX.  Native file formats 
contain the full complement of content and application metadata available to those who 
created and used the document.  Unlike TIFF images, native files are functional files, in 
that they can be loaded into a copy of the software application that created them to 
replicate what a prior user saw, as well as affording a comparable ability to manipulate 
the data and access content that’s made inaccessible when presented in non-native 
formats. 
Think of a TIFF as a PDF’s backward little brother.  TIFFs are not just differently abled; 
they are severely handicapped.  Not born that way, but lamed and maimed on 
purpose.  The other side downgrades what they give you, making it harder to use and 
stripping it of potentially probative content. 
Do they do this because they are trying to screw you?  Probably not. 
Does it screw you just the same?  Well, yes. 
“[W]ith multi-page extracted text or OCR.” 
A native file isn’t just a picture of the evidence It’s the original electronic evidence.  As 
such, it contains all of the content of the document in an electronic form.  Because it’s 
designed to be electronically usable, it tends to be inherently electronically searchable; 
that is, whatever data it holds is encoded into the native electronic file, including certain 
data about the data, called application metadata.  When an electronic document is 
converted to an image—TIFF—it loses its ability to be electronically searched, and its 
application metadata is lost.  It’s like photographing a steak.  You can see it, but you can’t 
smell, taste or touch it.  You can’t hear the sizzle, and you surely can’t eat it. 
Because converting to TIFF takes so much away, parties producing TIFF images deploy 
cumbersome techniques to restore some of the lost functionality and metadata.  To 
restore a measure of electronic searchability, they extract text from the electronic 
document and supply it in a file accompanying the TIFF images.  It’s called “multi-page 
extracted text” because, although the single page TIFFs capture an image of each page, 
C# PowerPoint - Merge PowerPoint Documents in C#.NET
C# PowerPoint - Merge PowerPoint Documents in C#.NET. Provide C# Demo Codes for Merging and Appending PowerPoint Document. Overview.
add multiple pdf files into one online; acrobat combine pdf
C# PDF Print Library: Print PDF documents in C#.net, ASP.NET
FREE TRIAL: HOW TO: XDoc.HTML5 Viewer for C#▶: C# ASP.NET: View documents; C# ASP.NET PDF to HTML; C#: Convert PDF to Jpeg; C# File: Compress PDF; C# File: Merge
pdf merge documents; acrobat split pdf into multiple files
13 
the text extraction spans all of the pages in the document.  A recipient runs searches 
against the extracted text file and then seeks to correlate the hits in the text to the 
corresponding page image. 
If the source documents are scans of paper documents, there’s no electronic text to 
extract from the paper.  Instead, the scans are subjected to a process called optical 
character recognition (OCR) that serves to pair the images of letters with their electronic 
counterparts and impart a rough approximation of searchability.  OCR sucks, but it beats 
the alternative (no electronic searchability whatsoever). 
“We will furnish delimited IPRO or Opticon load files . . . .” 
Whether extracted from an electronic source or cobbled together by OCR, the text 
corresponding to the images or scans is transferred in so-called “load files” that may also 
contain metadata about the source documents.  Collectively, the load files and document 
images are correlated in a database tool called a “review platform” or “review tool” that 
facilitates searching the text and viewing the corresponding image.  Common review tools 
include Concordance, Summation and Relativity.  There are many review tools out there, 
some you load on your own machines (“behind the firewall”) and some you access via 
the internet as hosted tools. 
To insure that the images properly match up with extracted text and metadata, the data in 
the load files is “delimited,” meaning that each item of information corresponding to each 
page image is furnished in a sequence separated by delimiters—just a fancy word for 
characters like commas, tabs or semicolons used to separate each item in the 
sequence.  The delimiting scheme employed in the load files can follow any of several 
published standards for load file layout, including the most common schemes known as 
Summation, Concordance/Opticon and iPro. 
“[A]nd will later identify fielded information we plan to exchange.” 
Much of the information in electronic records is fielded, meaning that is not lumped 
together with all the other parts of the record but is afforded its own place or 
space.  When we fill out paper forms that include separate blanks for our first and last 
name, we are dividing data (our full name) into two fields: (first), (last).  A wide array of 
information in and around electronic files tends to be stored as fields, e.g., e-mail 
messages separately field information like From, To, Date and Subject.  If fielded 
information is not exchanged in discovery as fielded information, you lose the ability to 
filter information by, for example, Date or Sender in the case of an e-mail message or by 
a host of fielded properties and metadata describing other forms of electronically stored 
information. 
VB.NET PDF Print Library: Print PDF documents in vb.net, ASP.NET
FREE TRIAL: HOW TO: XDoc.HTML5 Viewer for C#▶: C# ASP.NET: View documents; C# ASP.NET PDF to HTML; C#: Convert PDF to Jpeg; C# File: Compress PDF; C# File: Merge
add two pdf files together; append pdf
XDoc.HTML5 Viewer for .NET, Zero Footprint AJAX Document Image
controls, PDF document, image to pdf files and components for capturing, viewing, processing, converting, compressing and stroing images, documents and more.
pdf mail merge plug in; acrobat reader merge pdf files
14 
Additionally, the discovery process may necessitate the linking of various fields of 
information with electronic documents, such as Bates numbers, hash values, document 
file paths, extracted text or associated TIFF image numbers.  There may be hundreds of 
fields of metadata and other data from which to select, though not all of it has any 
evidentiary significance or practical utility.   
Accordingly, the proposal to “later identify fielded information we plan to exchange” defers 
the identification of fielded information to later in the discovery process when presumably 
the parties will have a better idea what types of ESI are implicated and what complement 
of fields will prove useful or relevant. 
Are they trying to screw you by not identifying fielded information? 
No.  They’re just buying time.  Does their delay screw you?  Maybe.   
Re-collecting fielded information you didn’t expect your opponent would want can be 
burdensome and costly.  Waiting too long to specify fielded information you seek may 
prompt the opponent to refuse to belatedly collect and produce it. 
So, are they trying to screw you by this proposal?  I doubt it.   
Chances are they are giving you the dumbed down data because that’s what they always 
give the other side, most of whom accept it without knowing what they’re missing.  It may 
be the form of production their own lawyers prefer because their lawyers are reluctant to 
invest in modern review tools.  It probably doesn’t hurt that the old ways take longer and 
throw off many more billable hours. 
“Tell them you want native production,” she offered as Fogg headed for the door, but Jen 
didn’t share what she was thinking: 
You may accept the screwed up proposal because, even if the data is less useful and 
incomplete, you won’t have to evolve.  You’ll pull the TIFF images into your browser or 
print them out and painstakingly read them one by one. All the while, you’ll be telling 
yourself that what you didn’t get probably wasn’t that important and promising yourself 
that next time, you’ll hold out for the good stuff—the native stuff.  Yeah, next time for 
sure.  Definitely.  Definitely. 
One Monday morning, two months later, E.D. Fogg once more dropped in on Jen Xavier.  He 
looked tired.  Fogg reported that he’d gotten production from Huevos & Huevos, Inc. and spent 
the weekend going through it.  He found TIFF images of the pages of electronic documents, but 
Onward through the Fogg: Load files 
C# PDF: C#.NET PDF Document Merging & Splitting Control SDK
file. C#.NET APIs to Combine Two or More PDF Documents. void String destn); C#.NET Sample Codes to Merge Multiple PDF Files. public void
reader combine pdf; reader combine pdf pages
VB.NET PDF: Use VB.NET Code to Merge and Split PDF Documents
VB.NET PDF - How to Merge and Split PDF. How to Merge and Split PDF Documents by Using VB.NET Code. Visual C#. VB.NET. Home > .NET Imaging
batch pdf merger; break pdf file into multiple files
15 
couldn’t search them or even copy out any content. He also received a lot of “Notepad 
documents.”  He insisted he’d notified opposing counsel in writing that he wanted “everything in 
native,” so he wasn’t sure what to make of all those pictures of documents and text files. 
Thinking it unlikely that a multinational medical device company would use Windows Notepad as 
its word processor, Jen probed further and learned that that the production included folders of 
TIFF images, folders of .TXT files (those “Notepad documents”) and folders of files with odd 
extensions like .DAT and .OPT. Fogg couldn’t make head nor tails of the last. 
Jen figured out that Fogg received an imaged production from an opponent who ignored Fogg’s 
specification of native forms and simply printed everything to electronic paper. The other side 
expected Fogg to buy or own an old-fashioned review tool capable of cobbling together page 
images with extracted text and metadata in load files. Without such a tool, Jen knew the 
production would be wholly unsearchable and largely unusable. Even then, search would be 
pretty lousy.  But she also knew that when Fogg protests, the other side will tell him how all 
those other files represent the very great expense and trouble they’ve gone to in order to make 
the page images searchable, as if furnishing load files to add crude searchability to page images 
of inherently searchable electronic documents constituted some great favor. 
Jen sighed and thought of that classic Texas comeback, “Don’t piss in my boot and tell me it’s 
raining.” 
The Lowdown on Load Files 
Load files are the unsung digital sherpas of e-discovery, tasked to tote metadata and searchable 
text otherwise lost when ESI is converted to TIFF images. Grasping the fundamentals of load 
files is important to fashioning a workable electronic production protocol, whether you’re dealing 
with TIFF images, native file formats or a mix of the two. 
In simplest terms, load files carry data that has nowhere else to go. They are called load files 
because they are used to load data into, i.e., “populate” a database. They first appeared in 
discovery in the 1980s in order to add a rough electronic searchability to paper documents.   
Before the turn of the century, when most items sought in discovery were paper documents, .tiff 
and load file productions made lawyers' lives easier by grafting rudimentary electronic 
searchability onto unsearchable paper documents. Then, as now, paper documents were 
scanned to .tiff images and coded by reviewers, and their text was extracted via optical 
character recognition (OCR) software.  
Unlike Adobe PDF images, TIFF images weren’t designed to integrate searchable text; 
consequently, the text garnered using OCR was stored in simple ASCII
8
text files named with 
8
ASCII is an acronym for American Standard Code for Information Interchange and describes one of the 
oldest and simplest standardized ways to use numbers—particularly binary numbers expressed as ones 
and zeroes—to denote a basic set of English language alphanumeric and punctuation characters. 
16 
the Bates number of the corresponding 
page image. So, in "single page .tiff" 
productions, each page of a document 
became its own image file, another file 
held aggregate extracted OCR text, and 
yet another held the coded data about 
the data, i.e., its metadata.  
While we tend to think of metadata as a 
feature unique to electronic documents, 
paper documents have metadata, too. 
They come in the form of custodian 
names, office locations, file and folder 
labels, box numbers and other physical 
descriptors that must be tracked. Still 
more metadata takes the form of codes, tags and abstracts reflecting reviewers’ assessments of 
documents and names.  Finally, load files serve as a sort of road map laying out, inter alia, 
where document images and their various load files are located on disks or other media used to 
deliver productions and how the various pieces relate to one another.   
Thus, adding a measure of searchability required more than a dozen separate electronic files 
just to carry the content of one 10-page document. 
Compared to paper documents alone, imaging and OCR added functionality. It was 20
th
century 
computer technology improving upon 19
th
century printing technology, and if you were a lawyer 
in the Reagan era, this was Star Wars stuff.  It was expensive and crude, but speedier than 
poring over thousands or millions of pieces of paper. 
To put Humpty Dumpty back together again demanded a database and picture viewer capable 
of correlating the extracted text to its respective page image and running word searches. Thus 
was born a new category of document management software called "review platforms” like 
Concordance or Summation—venerable products that survive to this day. 
Different review platforms used different load file formats to order and separate information 
according to guidelines called “load file specifications.” Again, load files are plain text files 
employing characters called delimiters to field (separate) the various information items in the 
load file. Thus, a load file specification might require that information about a document be 
transmitted in the order: Box No., Beginning Bates No., Ending Bates No., Date, and Custodian. 
The resulting single line of text delimited by, e.g., commas, would appear: 
57,ABC0003123,ABC0003134,19570901,Ball C. 
Load files were a headache; but, we put up with the pain because adding searchability to 
unsearchable paper documents was worth it.  A stone ax is better than no ax at all. 
17 
Because large document cases and attorney review pyramids were integral to law firm growth 
and profitability, lawyers invested in .tiff review platforms, and service providers emerged to 
compete for lucrative scanning and coding work. The electronic data discovery industry was 
born, circa 1987. 
So, to review, some load files carry extracted text to facilitate search, some carry metadata 
about the documents and some carry information about how the pieces of the production are 
stored and fit together. Load files are used because neither paper nor TIFF images are suited to 
carrying the same electronic content; and if it wasn’t supplied electronically, you couldn’t load it 
into review tools or search it using computers. 
Before we move on, let’s spend a moment on the composition of load files. If you were going to 
record many different pieces of information about a group of documents, you might create a 
table for that purpose. Possibly, you’d use the first two columns of your table to number the first 
and last page of each document, then the next column for the document’s name and then each 
succeeding column would carry particular pieces of information about the document. You might 
make it easier to tell one column from the next by drawing lines to delineate the rows and 
columns, like so: 
Those lines separating rows and columns serve as delimiters; they (literally) delineate one item 
of data from the next. Vertical and horizontal lines serve as excellent visual delimiters for 
humans, where computers work well with characters like commas, tabs and such. So, if the data 
from the table were contained in a load file, it might be delimited as follows: 
BEGDOC,ENDDOC,FILENAME,MODDATE,AUTHOR,DOCTYPE 
0000001,0000004,Contract,01/12/2013,J. Smith,docx 
0000005,0000005,Memo,02/03/2013,R. Jones,docx 
0000006,0000073,Taxes_2013,04/14/2013,H. Block,xlsx 
0000074,0000089,Policy,05/25/2013,A. Dobey,pdf 
Note how each comma replaces a column divider and each line signifies another row. Note also 
that the first or “header” row is used to define the type of data that will follow and the manner in 
which it is delimited. When commas are used to separate values in a load file, it’s called (not 
surprisingly) a “comma separated values” or CSV file. CSV files are just one example of 
standard forms used for load files. More commonly, load files adhere to formats compatible with 
18 
the Concordance and Summation review tools. Concordance load files typically use the file 
extension .DAT and the þ (thorn, ALT-0254) and ¶ (pilcrow, ALT-0182) characters as delimiters, 
e.g.: 
Concordance Load File 
þBEGDOCþ¶þENDDOCþ¶þFILENAMEþ¶þMODDATEþ¶þAUTHORþ¶þDOCTYPEþ    
þ0000001þ¶þ0000004þ¶þContractþ¶þ01/12/2013þ¶þJ. Smithþ¶þdocxþ 
þ0000005þ¶þ0000005þ¶þMemoþ¶þ02/03/2013þ¶þR. Jonesþ¶þdocxþ 
þ0000006þ¶þ0000073þ¶þTaxes_2013þ¶þ04/14/2013þ¶þH. Blockþ¶þxlsxþ 
þ0000074þ¶þ0000089þ¶þPolicyþ¶þ05/25/2013þ¶þA. Dobeyþ¶þpdfþ 
Summation load files typically use the file extension .DII, and do not structure content in the 
same way as Concordance load files; instead, Summation load files separate each record like 
so: 
Summation Load File 
; Record 1 
@T 0000001 
@DOCID 0000001 
@MEDIA eDoc 
@C ENDDOC 0000004 
@C PGCOUNT 4 
@C AUTHOR J. Smith 
@DATESAVED 01/12/2013 
@EDOC \NATIVE\Contract.docx 
; Record 2 
@T 0000005 
@DOCID 0000005 
@MEDIA eDoc 
@C ENDDOC 0000005 
@C PGCOUNT 1 
@C AUTHOR R. Jones 
@DATESAVED 02/03/2013 
@EDOC \NATIVE\Memo.docx 
; Record 3 
@T 0000006 
@DOCID 0000006 
@MEDIA eDoc 
@C ENDDOC 0000073 
@C PGCOUNT 68 
19 
0000001_0001,,TIFF\001\0000001_0001.tif,Y,,,4 
0000002_0002,,TIFF\001\0000002_0002.tif,,,, 
0000003_0003,,TIFF\001\0000003_0003.tif,,,, 
0000004_0004,,TIFF\001\0000004_0004.tif,,,, 
0000005_0001,,TIFF\001\0000005_0001.tif,Y,,,1 
0000006_0001,,TIFF\001\0000006_0001.tif,Y,,,68 
0000007_0002,,TIFF\001\0000007_0002.tif,,,, 
0000008_0003,,TIFF\001\0000008_0003.tif,,,, 
0000009_0004,,TIFF\001\0000009_0004.tif,,,, 
0000010_0005,,TIFF\001\0000010_0005.tif,,,, 
Opticon Load File
@C AUTHOR H. Block 
@DATESAVED 04/14/2013 
@EDOC \NATIVE\Taxes_2013.xlsx 
; Record 4 
@T 0000074 
@DOCID 0000074 
@MEDIA eDoc 
@C ENDDOC 0000089 
@C PGCOUNT 16 
@C AUTHOR A. Dobey 
@DATESAVED 05/25/2013 
@EDOC \NATIVE\Policy.pdf 
Two more load files are worth mentioning: Opticon image load files and overlay load files.   
Opticon load files employ the file extension .OPT and are used to pair Bates numbered pages 
with corresponding page images and to define the unitization of each document; that is where it 
begins and ends.  A document may be unitized physically, as when its constituent pages are 
physically joined by clips, staples or bindings, or a document may be unitized logically, where its 
constituent pages belong together though they are not physically unitized (as might occur when 
documents are bulk scanned or a transmittal references an enclosure).  Logical unitization 
requires judgment based on organizational clues in the documents, such as consecutive page 
numbers, titles and consistent page headers, typefaces and/or document structures.  Logical 
unitization is also a means to track family relationships between container files and contents and 
e-mail messages and attachments. 
Opticon load files typically employ a 
simple seven-field, comma-delimited 
structure: 
1. Page identifier (e.g., Bates number), 
2. Volume label (optional), 
3. Path to page image, 
4. New document marker (Y), 
5. Box identifier (optional), 
6. Folder identifier (optional), 
7. Page count (optional). 
Opticon load files are typically used in conjunction with Concordance load files.  The Opticon 
load files carry the image links and unitization, and the Concordance load files supply metadata 
Documents you may be interested
Documents you may be interested