Comment by _kst_ | Hacker News Reader

Comment by _kst_ | Hacker News Reader

"The handbook consists of four five-inch-thick binders containing printed and photocopied pages. These binders are replicated and distributed across numerous regional and local offices. The handbook also exists as online PDFs, where each chapter or subsection is published as its own PDF. With these two options, investigators don’t have an easy way to quickly access and search for much-needed information that helps them complete investigations, particularly when they’re working out in the field."

If I were working in that environment, I'd concatenate the multiple PDFs into one so I could search the entire set from any PDF reader. It's probably not as convenient as a web interface with a more sophisticated search facility, but it solves part of the problem fairly quickly.

To concatenate multiple PDFs:

    gs -q -sPAPERSIZE=letter -dNOPAUSE -dBATCH - \
       sDEVICE=pdfwrite -sOutputFile=ALL.pdf *.pdf

Adjust the paper size and the order of the input files to taste.

("gs" is the Ghostscript command.)

Longer term the team should track down where those PDFs are coming from.

"Source --> PDF --> docx --> HTML --> json" is just nuts.

>Coming into the sprint, we understood that one of the major constraints is that the handbook is created and maintained using Microsoft Word.

It's likely that the original source for the PDF/paper copies was lost. This necessitated the process of using OCR to get it into Word.

Obviously maintaining such a large and important piece of documentation in Word is wrong, but that's apparently how it's being done.

What are the options? It should be something that any clerk can handle and that doesn't become obsolete.

"It should be something that any clerk can handle and that doesn't become obsolete."

This is an important statement. in that it is a reasonable goal, but nearly impossible.

Even using word, once one gets past a simple document, and starts having TOC, index, etc. and is "four five-inch binders" full of pages, then not just ANY CLERK will be able to maintain the document.

Sure, maybe not _any_ clerk, but there are certainly more people that have deep knowledge of Word than LaTeX, mediawiki, etc

Okay, invoking Word vs LaTex automatically makes your argument a straw man. I would have compared word to e.g. Adobe InDesign.

It has been my experience that while almost everybody can create a passable document in Word, something technical/government-ish with 500 pages and all of the publishing accouterments that come with a document of size, purpose, and complexity, you're getting into specialist territory, and almost all of the DTP specialists I know start by importing Word files in to InDesign.

How elitist have we become that the top comment says staff will become confused by the term "sprint" or using Microsoft word, the most ubiquitous document writing software in existence. Would I use it? No. Would I suggest it here? Yes. I mean we are talking about PRINTING a 500 page document and carrying it around so we can't reach for the stars here, but I will grant them 2nd grade english and 5th grade typing proficiency.

I think word is actually one of the better tools to do this.

This reads like someone who doesn't have an understanding of the enormous power that word has hiding under it's shell.

Recent versions of Word can also import PDFs, which is useful in a pinch. I think it would have been a good fit for replacing OCR here.

Note that some PDFs contain actual text and markup, and can be imported natively. But others (eg. ones that came from a scanner) are nothing but an image of each page. Such images require some kind of OCR to turn into text, which I doubt Word's built in import will do.

As an aside, how does Ghostscript handle if the original pages aren't letter? I'm wondering if a command like this isn't doing more than it needs to. The way page trees work in the PDF file format, it's pretty easy to just create a new root page tree node that has as a child all the root page tree nodes of the other documents. This would maintain the individual paper size and orientation of each source document. The only "fun" part would be reindexing all the objects as you bring them into the new document.

"As an aside, how does Ghostscript handle if the original pages aren't letter?"

I have no idea. Most of the PDFs I deal with happen to be letter. I found that command a few years ago and haven't bothered to investigate further, since it suits my purposes most of the time.

"I'm wondering if a command like this isn't doing more than it needs to."

I wouldn't be at all surprised.

    pdfunite *.pdf ALL.pdf

"pdfunite" is part of the "poppler-utils" package on Debian-based systems.

(But older versions of poppler-utils don't include pdfunite, so the "gs" solution might still be useful.)

Similarly for pdftk:

    pdftk *.pdf cat output combined.pdf

It can perform lots of other functions on pdfs (hence the name!) during the process like setting printing permissions and quality, and performing encryptions.

Reply on news.ycombinator.com