Searchable Image vs. Searchable Image (Exact) - Quality of OCR

Question

I work in the legal field, and have always used the "Searchable Image (Exact)" setting when running OCR in-house on document productions.  I'm currently using Acrobat X when I do my own OCR. 
I have a vendor who says they use Acrobat 9 "Searchable Image" for all their document productions.  They say even though the actual image of the document is altered, they get better quality OCR results than they do with "Searchable Image (Exact)."  They say the document is deskewed so text can be read better by the OCR engine. 
My problem is that many documents are being altered.  Especially architectural drawings are tilting drastically to the right, the edge of the drawing is being clipped off entirely from the document, and dotted lines are being added to the image itself -- apparently where the edge of the page used to be.  This is unacceptable.  They say the entire drawing is being flipped so that the first few lines of text on the drawing is horizontal.  So if there is a small bit of text which is slanted, the entire drawing is tilted to adjust to that one piece of text. 
Is it true that OCR is that much better using "Searchable Image" vs. "Searchable Image (Exact)"?  I have to select one setting for all docs, and I'm inclined not to alter our documents in any way at the expense of OCR. 
They also say that they're having trouble OCRing docs that I can OCR without a problem using both Acrobat 8 and Acrobat X.  Does that make any sense?  I switched directly from 8 to X so I'm not familiar with Acrobat 9.

Answer 1

Finding PDF that have / lack OCR.
You can utilize Acrobat's Preflight(s) for this.
Regarding a PDF that won't take to OCR (and has no renderable text, although text is present).
This can happen. Occasionally I have to deal with a few of these. In all cases the source PDF came out of a non-Adobe application.
Most annoying. As the PDF is all I have I resort to a "refry" to a tabloid page size with appropriate orientation and at 400 ppi.
OCR "takes". A lesson learned - for every best practice (don't refry PDF) there can be exceptions.
Some observations (of, in my opinion, egregious activity).
--| Reprocessing to letter, portrait
Or is this a contractually specified page size/orientation?
If so, it is driving the production of problematic deliverables.
--| Refry of good PDFs to images to support OCR (for "search") 
Many of your "source" PDFs have renderable text that will support search.
Example:
-- --| PDFs sourced from Word or Excel possess renderable text.
When done properly the fonts / font sub-sets are embedded and map to Unicode. This assures the PDFs' page content is searchable "as-is". Refry of a PDF to obtain an image so one can then OCR "to make searchable" is egregious.
--| PDFs of scanned images at the source paper's page size.
Why refry by printing to a smaller page size? For usability, as a true and accurate copy of the hardcopy one wants the appropriate page size and orientation. These days most 'discovery' work is done via shake 'n bake of the eDoc not the hardcopy (*).
(*) If one needs hardcopy then print it. One can create imprints to paper in a plethora of ways.
The imprint can be sized to fit the desire paper size. Of course going down in page size for a scanned image means what's on paper is not too usable. But, doing so with a PDF from CAD that is vector graphic is something else. Yes, a 44 x 34 from Microstation is "smaller" on a sheet of letter size paper. But, the imprint is crisp and usable. If you're a geezer like me you'll want a magnification "glass". But, oh my, that imprint is sweet and is usable.
--|  PDF output of CAD.
Reprocessing into an image for OCR.
Most CAD applications in use can output PDF. Text will present in one or more layers on the output.
Unless the CAD fonts are of some in-house branding that fails to comply with proper "font" practices all this will be renderable. With proper font selection the font families used will map to Unicode. Thus "searchable".
If one's client does not want a PDF with layers then use an Acrobat Pro Preflight to flatten them.
Typically the text present in the PDF won't be embedded. If needed use the Acrobat Pro Preflight to embed them.
Note that some CAD output will have vector graphics (CAD file content created with the CAD application) and raster (an image). Typically legacy drawings are scanned and this image brought into the CAD file for the drawing. A designer then redraws/remasters using vector graphics. Often this is incremental (it is a time consuming activity) to process approved drawing revisions as these come in. The output PDF will have the renderable text that is associated with text placed via the CAD application. The image of text from the source raster will not be searchable. One *does not* reprocess such a PDF to an image to OCR for "search".
More (much more) is lost.
Do the trials and review what you get compared to what you had. This will validate my statement.
(I'm confident on this because I've done it -- that "what if" itch I just gotta scratch <grin>.)
A Note: OCR of "mixed" content (say a chart, plot, scanned CAD drawing having text, lines, curves, etc.) rarely yields useful OCR output. Scan a collection of these. OCR. Export / Save As to a text file. Do the compare/contrast.  Or view the "hidden" text (Acrobat lets you do that). This can be a most informative exercise.
--| Always the same .... no one complains
One could write volumes on this. But then I suspect that's already been done.
~~~~~~~~~~~~~~~~~
Some nattering on my part.
An eDiscovery firm that has no "eDoc wranglers" is in harm's way.
(Actually, the wrangler is something of a joat. Competent understanding of the core discpline and compent understanding of  the workflows to which the "eDocs" are subjected to.
Being a programmer/developer is not a prerequisite.  -- You know, like it or not you've already joined the "wrangler" posse.)
If what you've described resides in content provided to clients it becomes "when" not "if" a client gets to hold the bag. This may be minor; it may be major. Regardless client ire will tend to be directed towards the eDiscovery firm not the firm's vendor(s).
Be well...