.net c# pdf viewer : Build pdf from multiple files SDK Library service wpf asp.net azure dnn Lawyers%20Guide%20to%20Forms%20of%20Production_Ver.20140512_TX5-part420

50 
decisis, considering the Court cited three prior opinions in which it had reached a similar result 
ordering a party to tie Bates numbers to specific Requests. 
The Court reflected on its reasoning as enunciated from the bench: 
The Court said that it understood rule 34(b)(2)(E)(i) — requiring a responding party to produce 
documents ³as they are kept in the usual course of business or . . . organize and label them to 
correspond to the categories in the request´ — to apply both to hard copy documents and to 
ESI, as both are subsets of the catchall term ³documents,´ and that rule 34(b)(2)(E)(ii) and (iii) 
are additional provisions related only to the production of ESI. … The Court expressed 
uncertainty regarding how a party would produce ESI ³in the usual course of business,´ and that, 
if the party were to go through the documents and remove privileged or unresponsive 
documents before placing the files on a storage device, this production would not meet the 
³usual course of business´ requirement and the party would have to label the documents to 
correspond to the categories in the request. … The Court compared hard copy document 
storage to ESI and noted that it would be difficult to find an analog to allowing opposing counsel 
access to boxes of information kept in warehouses, because it would require the responding 
party to give the other party access to the responding party’s computer system, or to place all of 
the files on a storage device without culling out any unresponsive or privileged files…. 
The Court, it appears, was less than supremely confident in its ruling.  Understandably, as these 
were not your usual, imperious “Let them eat TIFF” Defendants.  They approached the Plaintiffs 
and inquired about preferred forms of production.  They supplied native files in native 
forms and paired same to particular requests.  They promised that the paper documents were 
ordered as in the usual course, notwithstanding their digitized format.  They graciously added 
searchability to unsearchable paper documents and furnished an index. 
I’ve seen worse…much worse. 
A month later, the Court held a hearing on an unrelated matter and the defense asked the Court 
to reconsider its directive to pair the Bates numbers of the electrified paper with the requests to 
which they are responsive.  It’s not clear from the opinion why the work hadn’t been done in the 
intervening month, and I expect Plaintiffs’ counsel couldn’t have passed a BB when the Court 
said it “was seriously rethinking its prior ruling” and that “some of the commentators and some of 
the cases conflate.” 
I hope it wasn’t some blindsided young associate who had to comment and conflate all that back 
to the partners.  [Have you seen Breaking Bad?  They don’t mess around in Albuquerque]. 
The Court made it easy for the defense, stating that, if the Defendants could prove that the ESI 
was produced as it was kept in the usual course of business, without litigation-related alteration, 
then the Court was inclined to rule that no labeling would be required.  But the Court added, 
“once you’ve set there and you had your paralegals go through it, you’ve decided that this is 
Build pdf from multiple files - Merge, append PDF files in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Provide C# Demo Codes for Merging and Appending PDF Document
adding pdf pages together; pdf merge
Build pdf from multiple files - 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 merger; pdf split and merge
51 
relevant, this is not relevant, we’re going to go through it for privilege, we’re going to Bates 
stamp it, I don’t think that’s . . . the usual course of business.” 
Undaunted, the defense provided a declaration, and a damn fine one, too!  The Declaration 
establishes that the only documents removed from production were privileged ones, and 
supplies a breakdown of contents by Bates number ranges and sources.  The affidavit also 
confirms my suspicion that the venerable Plaintiffs’ firm was trying to navigate e-discovery in an 
“old school” way, without benefit of basic e-discovery tools. 
The Plaintiffs supplied no counter-declaration from anyone with any e-discovery expertise (or 
from anyone at all, insofar as PACER reveals). 
Reminder: Evidence is good.  Judges like evidence more than lawyer talk
At this juncture, the Court could have put this matter to bed in three ways, without muss, fuss or 
dicta: 
1. The Court could have found that the material in question derived from hard-copy 
documents clearly subject to 34(b)(2)(E)(i) at the start of litigation, and the conversion of 
these paper documents to searchable electronic forms for use by counsel in discovery 
didn’t change their essential character for purposes of requiring that they be organized as 
they are kept in the usual course of business or organized and labeled to correspond to 
the categories of a request.  Plaintiff prevails. 
2. The Court could have found that the electronic counterparts of the paper documents had 
been produced in substantially the way they were kept in the usual course of business, 
making reasonable allowances for variations attendant to the parties’ agreement to scan 
and OCR the material and the need to protect privileged content.  Documents withheld as 
privileged would necessarily be identified in a privilege log by Bates number, so, their 
location within the collection could be readily established.  Defendant prevails. 
3. The Court could have found (and did find) that the Parties agreement respecting 
production was a stipulation that altogether removed the issue from the purview of Rule 
34(b)(2)(E), and the Court could have fashioned any outcome it deemed proper and 
proportionate without further need to address the (inapplicable) Rule 34(b)(20(E) in dicta. 
Instead, the Court pursued a broad-ranging assessment of Rule 34(b)(2)(E) that stirs an eddy of 
uncertainty. 
1. For example, the Court termed “unavailing” the argument that the source documents 
weren’t ESI because they existed in hard copy form and were only imaged for 
production.  The Court reasoned that the agreement to image the documents was, in fact, 
the parties stipulating out of the rule’s default provisions. 
C# Create PDF from images Library to convert Jpeg, png images to
Component for combining multiple image formats into one or multiple PDF file in C#.NET. This example shows how to build a PDF document with three image files
merge pdf online; apple merge pdf
VB.NET Create PDF from images Library to convert Jpeg, png images
Turn multiple image formats into one or multiple PDF file. NET example shows how to build a PDF document with three image files (BMP, JPEG and PNG).
break pdf into multiple files; add pdf together one file
52 
This makes little sense.  Certainly, parties can agree to stipulate around Rule 34(b)(2)(E); but 
such a stipulation should be clear and express.  It needn’t follow that because one party accedes 
to another party’s desire to make paper records more convenient, organization of the information 
is optional.  Why should a mutually beneficial endeavor come at the risk that an opponent is free 
to destroy the usual and customary organization of the evidence or at the cost of a requesting 
party’s right to know what’s responsive to what? 
The parties merely settled upon forms of production.  They made no bargain respecting 
the organization of production, nor did they agree to restrict the scope of production.  These are 
three distinct dimensions of discoverable information. 
It was the producing party’s avowed intention to convert the hard-copy documents to TIFF 
images.  Had they done so without the agreement of the requesting party, they would 
nonetheless have been obliged to produce the hard-copy documents as kept in the usual course 
or organized and labeled to correspond to the request.  Judge Browning made quite clear that, 
“’if at the beginning of the litigation the documents existed in document hard copy form,’ then the 
Defendant could not unilaterally convert the documents into ESI.”  However, if the requesting 
party cooperates and allows a producing party to convert hard-copy documents to TIFF or PDF, 
the requesting party is now agreeing, sub silentio, to forego organization of the documents.  The 
producing party is thus free to make an unholy mess of the production from an organizational 
standpoint, and there’s not a thing the requesting party can do about it.  That doesn’t add up. 
2. At the start of the litigation, the 20,000 pages produced were paper records kept in the 
usual course of the Defendants’ business.  From the standpoint of the usual course of the 
Defendants’ business, they never changed form.  That is, they did not become ESI in 
conjunction with the customary operation or recordkeeping of the Defendants’ 
business.  So, they remained subject to the provisions of Rule 34(b)(2)(E)(i).  It’s a 
mistake to equate conversion for the convenience of the lawyers to conversion in the 
usual course of the litigants’ business. 
If a lawyer elects to convert ESI to another form like scanned images, the destination form may 
be the form used in the course of the lawyer’s business, but it’s not the form used by the 
producing party 
The Court fails to distinguish between the form and organization of information as used by the 
parties to an action and the (de)form and (dis)organization occasioned by counsel’s wish to 
convert information to something else.  We frequently encounter this assumption in e-
discovery.  That is, producing parties assume that requesting parties can’t demand any form 
more complete or utile than the dumbed-down versions used by producing party’s counsel. 
That’s not the rule. 
C# Create PDF from CSV to convert csv files to PDF in C#.net, ASP.
file to one PDF or splitting to multiple PDF documents. dlls, Right click the project -> Properties -> Build -> Platform target how to convert CSV to PDF document
add pdf files together; pdf combine two pages into one
C# PDF Convert to Images SDK: Convert PDF to png, gif images in C#
conversions from PDF document to multiple image forms dlls, Right click the project -> Properties -> Build -> Platform target C# Sample Code for PDF to Png in C#
pdf mail merge; all jpg to one pdf converter
53 
Requesting parties should be entitled to obtain forms of production that mirror the forms the 
producing parties use, not compelled to accept the degraded forms preferred by the producing 
party’s lawyer. 
3. The form of production does not implicate the organization of production. They are 
different, and each presents different opportunities for abuse.  A party can produce 
information items in utile, complete and searchable forms but still disrupt organization or 
logical unitization (i.e., folder structure) so as to render the production all but 
useless.  The notion that electronic search adequately offsets the risk of shuffling and 
other organizational mischief is untenable—ask anyone who’s ever gotten a malformed 
load file. 
Organizational information, like foldering data and file locations (paths), are as essential to utile 
production today as they were in the paper era, if not more so. 
4. I don’t share the Court’s view that potentially responsive documents/ESI collected as 
maintained in the usual course of business lose that character when privileged 
documents are culled.  Granted, the collection is not as complete as kept in the usual 
course, but the remaining documents are still organized and in the same form as kept in 
the usual course.  In the paper era, it was customary for the boxes from the legal 
department to be spirited out of the warehouse; and when privileged contents turned up, 
they, too, were pulled.  Production by inspection didn’t oblige a producing party to 
abandon privilege.  Parties need not do so with respect to ESI. 
5. Most problematic of all is the Court’s conclusion that provisions 34(b)(2)(E)(i) and 
34(b)(2)(E)(ii) “apply to distinct, mutually exclusive categories of discoverable 
information,” being “Documents,” which the Court calls “a term that does not include ESI,” 
governed exclusively by 34(b)(2)(E)(i), and ESI, which the Court says is governed 
exclusively by 34(c)(E)(ii).  The Court relies on the views of a distinguished commentator, 
John K. Rabiej.  With respect to Professor Rabiej–who was closely involved with the 
amendments process—his disjunctive interpretation of 34(b)(2)(E) is one thoughtful view; 
but one that seems oddly out of step with the Committee Notes. 
The Court’s embrace of such a distinction is regrettable because the 2006 Federal Rules 
amendments and the Committee Notes that accompany them go to some pains to underscore 
that the term “documents” includes ESI.  In fact, defining “Documents” to encompass data 
compilations has a long and uncontentious history in the Rules. 
The Court saw the perils, stating, “There is something to be gained from imposing basic 
organization requirements onto massive productions of ESI; artifacts of ESI can be jumbled 
beyond usefulness — by dumping them out of their file directories and onto the requesting party 
— just as easily as hard copy documents can.”  Indeed, and it happens all the time, though more 
often as a consequence of carelessness than of bad faith. 
C# Create PDF from Tiff Library to convert tif images to PDF in C#
image with single page or multiple pages is Right click the project -> Properties -> Build -> Platform target a quick evaluation of our XDoc.PDF file conversion
merge pdf files; scan multiple pages into one pdf
C# Create PDF from OpenOffice to convert odt, odp files to PDF in
control able to batch convert multiple OpenOffice documents to Right click the project -> Properties -> Build -> Platform target Code to Convert ODT to PDF in C#
combine pdf; pdf combine
54 
The organization of ESI in production can fairly and efficiently be made to mirror its organization 
in the usual course of business.  It typically requires little more than competent handling of 
system metadata.  It doesn’t require granting an opponent access to a responding party’s 
computer systems. 
Here again, it’s useful to distinguish the three dimensions of discoverable ESI: form, 
organization and scope If a party culls privileged content before producing the data for 
inspection, form and organization remain the same; only scope changes—and it’s appropriate 
that privileged content be outside the general scope of discovery.  Any minimal impact on 
organization is offset by the obligation to log content withheld as privileged. 
6. Finally, it’s an ill wind which blows no man to good.  Judge Browning clarified that his 
ruling did not apply unless the requesting party sought conversion to an imaged 
format.  “’[I]f at the beginning of the litigation the documents existed in document hard 
copy form,’ then the Defendant could not unilaterally convert the documents into ESI.” 
By that reasoning, if at the beginning of the litigation the documents existed as ESI, the 
producing party cannot unilaterally convert the documents into paper or paper-like forms (e.g., 
images) unless the requesting party stipulates to same
Quoting Professor Rabiej, the Court notes that “while (E)(i) document production gives the 
producing party the right to choose whether to produce ‘in the usual course of business” or 
“label[ed] … to correspond to the categories in the request,’ (E)(ii) puts the ball in the requesting 
party’s court by first giving them the option to ‘specify a form for producing’ ESI. Fed. R. Civ. P. 
34(b)(2)(E)(i)-(ii). It is only if the requesting party declines to specify a form that the producing 
party is offered a choice between producing in the form ‘in which it is ordinary maintained’ — 
native format — or ‘in a reasonably useful form or forms.’ Fed. R. Civ. P. 34(b)(2)(E)(i)-(ii).” 
That’s powerful stuff, and dead right.  Producing parties have long assumed that they were free 
to ignore a requesting party’s specification of form so long as they produced in a form claimed to 
be “reasonably usable.”  Not so.  As the Court notes, the “reasonably usable” option applies only 
when a requesting party fails to specify a form. 
The lesson for requesting parties is always, always, ALWAYS specify forms for production in 
your requests.  If you want Word documents produced natively, SAY SO!  If you want e-mail in 
functional forms, specify the forms!  The Rules afford requesting parties the crucial right to 
specify form or forms of production, and lawyers who fail to avail themselves of that right are 
inviting production of less utile and -complete forms.  If you wear a “KICK ME” sign on your 
bootie, don’t be surprised by the boot. 
So, with apologies to Judge Browning, the result seems right, but the rationale not so much.  It’s 
dicta likely to be cited in support of mischief, and I know that’s not what the Court wished. 
C# Create PDF from Text to convert txt files to PDF in C#.net, ASP
plain text to PDF text with multiple fonts, sizes Right click the project -> Properties -> Build -> Platform target can convert text file to PDF document using
acrobat reader merge pdf files; reader combine pdf pages
VB.NET TIFF: Use VB.NET Class to Create TIFF File Mobile Viewer in
able to view and process their TIFF files in iPhone mobile application, but also make multiple annotations on & profession imaging controls, PDF document, tiff
merge pdf; batch combine pdf
55 
1. "Information items" as used here encompass individual documents and records 
(including associated metadata) whether on paper or film, as discrete "files" 
stored electronically, optically or magnetically or as a record within a database, 
archive or container file. The term should be read broadly to include e-mail, 
messaging, word processed documents, digital presentations and spreadsheets.  
2. Responsive electronically stored information (ESI) shall be produced in its native 
form; that is, in the form in which the information was customarily created, used 
and stored by the native application employed by the producing party in the 
ordinary course of business.   
3. If it is infeasible to produce an item of responsive ESI in its native form, it may be 
produced in an agreed-upon near-native form; that is, in a form in which the item 
can be imported into the native application without a material loss of content, 
structure or functionality as compared to the native form.  Static image production 
formats serve as near-native alternatives only for information items that are 
natively static images (i.e., photographs and scans of hard-copy documents). 
4. The table below supplies examples of agreed-upon native or near-native forms in 
which specific types of ESI should be produced: 
Source ESI 
Native or Near-Native Form or Forms Sought 
Microsoft Word documents 
.DOC, .DOCX 
Microsoft Excel Spreadsheets 
.XLS, .XLSX 
Microsoft PowerPoint 
Presentations 
.PPT, .PPTX 
Microsoft Access Databases 
.MDB, .ACCDB 
WordPerfect documents 
.WPD 
Adobe Acrobat Documents 
.PDF 
Photographs 
.JPG, .PDF 
E-mail 
Messages should be produced in a form or 
forms that readily support import into standard 
e-mail client programs; that is, the form of 
production should adhere to the conventions 
set out in RFC 5322 (the internet e-mail 
standard).   For Microsoft Exchange or 
Outlook messaging, .PST format will suffice.  
Single message production formats like .MSG 
or .EML may be furnished, if source foldering 
data is preserved and produced.  For Lotus 
Notes mail, furnish .NSF files or convert to 
.PST.  If your workflow requires that 
attachments be extracted and produced 
separately from transmitting messages, 
attachments should be produced in their 
Appendix 2: Exemplar Production Protocol 
C# Create PDF from RTF to convert csv files to PDF in C#.net, ASP.
library which able to batch convert multiple RTF files Right click the project -> Properties -> Build -> Platform target way of converting RTF to PDF document.
.net merge pdf files; c# merge pdf files
56 
native forms with parent/child relationships to 
the message and container(s) preserved and 
produced in a delimited text file. 
5. Absent a showing of need, a party shall produce responsive information reports 
contained in databases through the use of standard reports; that is, reports that 
can be generated in the ordinary course of business and without specialized 
programming efforts beyond those necessary to generate standard reports.  All 
such reports shall be produced in a delimited electronic format preserving field 
and record structures and names.  The parties will meet and confer regarding 
programmatic database productions as necessary. 
6. Information items that are paper documents or that require redaction shall be 
produced in static image formats scanned at 300 dpi e.g., single-page Group 
IV.TIFF or multipage PDF images. If an information item contains color, the 
producing party shall not produce the item in a form that does not display color. 
The full content of each document will be extracted directly from the native 
source where feasible or, where infeasible, by optical character recognition 
(OCR) or other suitable method to a searchable text file produced with the 
corresponding page image(s) or embedded within the image file.  Redactions 
shall be logged along with other information items withheld on claims of privilege. 
7. Parties shall take reasonable steps to ensure that text extraction methods 
produce usable, accurate and complete searchable text.  
8. Individual information items requiring redaction shall (as feasible) be redacted 
natively, produced in .PDF format and redacted using the Adobe Acrobat 
redaction feature or redacted and produced in a format that does not serve to 
downgrade the ability to electronically search the unredacted portions of the item.  
Bates identifiers should be endorsed on the lower right corner of all images, but 
not so as to obscure content. 
9. Upon a showing of need, a producing party shall make a reasonable effort to 
locate and produce the native counterpart(s) of any unredacted .PDF or .TIF 
document produced.  The parties agree to meet and confer regarding production 
of any such documents.  This provision shall not serve to require a producing 
party to reveal redacted content. 
10. Except as set out in this Protocol, a party need not produce identical information 
items in more than one form and shall globally de-duplicate identical items across 
custodians using each document’s unique MD5 hash value.  The content, 
metadata and utility of an information item shall all be considered in determining 
whether information items are identical, and items reflecting different information 
shall not be deemed identical.  
57 
11. Production should be made on CD, DVD or hard drive(s) using the medium 
requiring the least number of deliverables.  Label all media with the case number, 
production date, Bates range and disk number (1 of X, if applicable).  Organize 
productions by custodian, unless otherwise instructed. All documents from an 
individual custodian should be confined to a single load file.  All productions 
should be encrypted for transmission to the receiving party.  The producing party 
shall, contemporaneously with production, supply decryption credentials and 
passwords to the receiving party for all items produced in an encrypted or 
password-protected form. 
12. Each information item produced shall be identified by naming the item to 
correspond to a Bates identifier according to the following protocol:  
i. The first four (4) characters of the filename will reflect a unique alphanumeric 
designation identifying the party making production;  
ii. The next six (6) characters will be a designation reserved to the 
discretionary use of the party making production for the purpose of, e.g., 
denoting the case or matter.  This value shall be padded with leading zeroes 
as needed to preserve its length; 
iii. The next nine (9) characters will be a unique, consecutive numeric value 
assigned to the item by the producing party. This value shall be padded with 
leading zeroes as needed to preserve its length;  
iv. The final six (6) characters are reserved to a sequence consistently 
beginning with a dash (-) or underscore (_) followed by a five digit number 
reflecting pagination of the item when printed to paper or converted to an 
image format for use in proceedings or when attached as exhibits to pleadings.  
v. By way of example, a Microsoft Word document produced by Acme in its 
native format might be named: ACMESAMPLE000000123.docx. Were the 
document printed out for use in deposition, page six of the printed item must 
be embossed with the unique identifier ACMESAMPLE000000123_00006. 
Bates identifiers should be endorsed on the lower right corner of all printed 
pages, but not so as to obscure content. 
vi. This format of the Bates identifier must remain consistent across all 
productions. The number of digits in the numeric portion and characters in the 
alphanumeric portion of the identifier should not change in subsequent 
productions, nor should spaces, hyphens, or other separators be added or 
deleted except as set out above. 
13. Information items designated Confidential may, at the Producing Party’s option: 
58 
a. Be separately produced on electronic production media prominently labeled to 
comply with the requirements of the [DATE] Protective Order entered in this 
matter; or, alternatively, 
b. Each such designated information item shall have appended to the file’s name 
(immediately following its Bates identifier) the following protective legend: 
~CONFIDENTIAL-SUBJ_TO_PROTECTIVE_ORDER 
When any item so designated is converted to a printed or imaged format for use 
in any submission or proceeding, the printout or page image shall bear the 
protective legend on each page in a clear and conspicuous manner, but not so 
as to obscure content. 
14. Producing party shall furnish a delimited load file supplying the metadata field 
values listed below for each information item produced (to the extent the values 
exist and as applicable): 
Field Name 
Sample Data 
Description 
BegBates 
ACMESAMPLE000000001 
First Bates identifier of item  
EndBates 
ACMESAMPLE000000123 
Last Bates identifier of item 
AttRange  
ACMESAMPLE000000124 - 
ACMESAMPLE000000130 
Bates identifier of the first page of the parent 
document to the Bates identifier of the last page 
of the last attachment “child” document  
BegAttach 
ACMESAMPLE000000124 
First Bates identifier of attachment range 
EndAttach 
ACMESAMPLE000000130 
Last Bates identifier of attachment range 
Parent_Bates  
ACMESAMPLE000000001 
First Bates identifier of parent document/e-mail 
message.   
**This Parent_Bates field should be populated in 
each record representing an attachment ³child´ 
document. ** 
Child_Bates  
ACMESAMPLE000000004; 
ACMESAMPLE000000012; 
ACMESAMPLE000000027 
First Bates identifier of “child” attachment(s); may 
be more than one Bates number listed 
depending on number of attachments. 
**The Child_Bates field should be populated in 
each record representing a ³parent´ document. ** 
Custodian 
Houston, Sam 
E-mail: mailbox where the email resided.  
Native: Individual from whom the document  
originated   
Path 
E-mail: \Deleted Items\Battles\ 
SanJac.msg 
Native: Z:\TravisWB\Alamo.docx 
E-mail: Original location of e-mail including 
original file name. 
Native: Path where native file document was 
stored including original file name. 
From 
GuerreroJ@hotmail.com; David 
Crockett [mailto: 
Davy@Crockett.net] 
E-mail:  Sender  
Native: Author(s) of document  
**semi-colons separate multiple entries ** 
To 
Genl. A.L. de Santa Anna 
Recipient(s)  
**semi-colons separate multiple entries ** 
CC 
Jim.Bowie@bigknife.com 
Carbon copy recipient(s) 
**semi-colons separate multiple entries ** 
BCC 
AustinSF@state.tx.gov 
Blind carbon copy recipient(s) 
**semi-colons separate multiple entries ** 
Date Sent 
03/18/2014 
E-mail:  Date the email was sent  
59 
Time Sent  
11:45 AM 
E-mail: Time the message was sent  
Subject/Title 
Remember the Alamo! 
E-mail: Subject line of the message  
IntMsgID  
<A1315BC17ABD4774BF779CB3
E3E62B9B@gmail.com> 
E-mail: For e-mail in Microsoft 
Outlook/Exchange, the “Unique Message ID” 
field; For e-mail in Lotus Notes, the UNID field. 
Native: empty. 
Date_Mod 
02/23/1836 
E-mail: empty.  
Native: Last Modified Date 
Time_Mod 
01:42 PM 
E-mail: empty  
Native: Last Modified Time 
File_Type 
XLSX 
E-mail: empty 
Native: file type 
Redacted 
Denotes that item has been redacted as 
containing privileged content (yes/no). 
File_Size 
1,836 
Size of native file document/email in KB. 
HiddenCnt  
Denotes presence of hidden Content/Embedded 
Objects in item(s) (yes/no) 
Confidential  
Denotes that item has been designated as 
confidential pursuant to protective order (yes/no). 
MD5_Hash 
eb71a966dcdddb929c1055ff2f1cc
d5b 
MD5 Hash value of the item. 
DeDuped 
E-mail: \Inbox\SanJac.msg 
Native: Z:\CrockettD\Alamo.docx 
Full path of other instances de-deduplicated by 
MD5 hash 
**semi-colons separate multiple entries ** 
15. Each production should include a cross-reference load file that correlates the 
various files, images, metadata field values and searchable text produced. 
16. Parties shall respond to each request for production by listing the Bates 
identifiers/ranges of responsive documents produced, and where an information 
item responsive to these discovery requests has been withheld or redacted on a 
claim that it is privileged, the producing party shall furnish a privilege log. 
Documents you may be interested
Documents you may be interested