views:

103

answers:

1

I've investigated several C# DLL's and have not found any that work especially well. My requirements are:

  • PDF documents are uploaded via an ASPX page.
  • Text needs to be extracted and stored in the DB with the PDF.
  • Solution cannot have additional cost for replicating the Web App (so if I know it will work, a fixed-fee solution would be considered, but no fee-per-installation).
  • Although good conversions are most important, users may wish to upload many PDF files at once, so speed is also important.

The downstream process that will consume the text is set up to use PDFBox, which seems to work well. But:

  • PDFBox is written in Java, so I need to launch it as a separate process and retrieve the results (I'm dismissing using it through IKVM).
  • By default it reads from disk files, but for both simplicity and speed I'd prefer a stdin->stdout filter. Fixing PDFBox was simple, but getting I/O to a subprocess from C# was tedious.
  • I know I could write a new disk to the hard drive, launch PDFBox, wait for it to exit, then read from the hard drive (or its stdout), but that seems hackish and would likely be slower.

I'm surprised I cannot find a PDF converter recipe, it seems like a common requirement. So, could anyone help me with either:

  • A canned conversion solution that you use which works at least as well as PDFBox.
  • If using a stdio filter behind IIS is truly a bad idea, an explanation of why.

Thanks in advance.

A: 

I originally asked how to write binary data to a Process.StandardInput (StreamWriter) since it only handles character data: the answer is to use Process.StandardInput.BaseStream (Stream).

In addition, since both pipes might fill up (64KB buffers IIUC), I used the following pattern:

  • Spawned a thread to write data, then set a flag,
  • Spawned a thread to read all of the return data, then set a flag,
  • Loop until both flags are set, calling Thread.Sleep(100).
  • Return data read from process.

So other than the hackish aspect of either putting an executable within the WebApp (or requiring a separate install) this seems to work fine -- but I still need to do some abuse testing.

NVRAM