Tome un vistazo a org.apache.pdfbox.examples.util.PrintTextLocations. Lo he usado bastante y es muy útil hacer análisis sobre el diseño de elementos y cuadros delimitadores en documentos PDF. También reveló elementos impresos en tinta blanca, o fuera del área imprimible (presumiblemente, marcas de agua de documentos u objetos "olvidados" que el autor ha apartado de su vista).
Ejemplo de uso:
java -cp app/target/pdfbox-app-1.5.0.jar org.apache.pdfbox.examples.util.PrintTextLocations ~/tmp/mydoc.pdf >~/tmp/out-text-locations.txt
que obtendrá algo así:
Processing page: 0
String[53.9,59.856995 fs=-6.0 xscale=6.0 height=-3.666 space=1.3320001 width=4.6679993]A
String[58.568,59.856995 fs=-6.0 xscale=6.0 height=-3.666 space=1.3320001 width=2.6640015]f
String[61.232002,59.856995 fs=-6.0 xscale=6.0 height=-3.666 space=1.3320001 width=1.6679993]e
...
que se puede analizar y utilizar para trazar la posición del elemento fácilmente, saltando de la caja, y el "flujo" (trayectoria a través de todos los elementos), etc. para cada página. Como estoy seguro de que ya sabe, encontrará que PDF puede ser casi imposible de convertir a texto. En realidad, es solo un formato de descripción gráfica (es decir, para la impresora o la pantalla), no un lenguaje de marcado. Podrías crear fácilmente un PDF que imprima "Hola mundo", pero que salte aleatoriamente a través de las posiciones de los personajes (y que utilice glifos diferentes a cualquier codificación ISO, si así lo deseas), haciendo que el PDF sea muy difícil de convertir a texto. No hay noción de "palabra" o "párrafo". Un documento de dos columnas, por ejemplo, puede ser una pesadilla para analizar en texto.
Para la segunda parte de su pregunta, tuve buenos resultados usando xpdf versión 3.02, después de la fijación Xref.cc (hacer XRef::okToPrint(), XRef::okToChange(), XRef::okToCopy()XRef::okToAddNotes() y todos regresan gTrue). Eso es para manejar documentos bloqueados, no cifrados (hay otros utilidades para eso).