Fix read

docs/performance.md

@@ -43,11 +43,11 @@ the cache size, the more data is read from the disk, i.e. the chances of cache h
 comes at the cost of more memory usage and more allocations in the JVM, which can have a performance impact.
 By default, the plugin uses a section size of 8KiB with a maximum number of cached sections of 10,
 which is a good trade-off for most setups and performed well in our benchmarks. If you want to tweak these
-settings, use the `sectionReadSizeKib` and `maxSectionCacheSizeKib` parameters on the `OcrHighlightComponent`
+settings, use the `sectionReadSizeKiB` and `maxSectionCacheSizeKiB` parameters on the `OcrHighlightComponent`
 in your `solrconfig.xml`:
 
-- `sectionReadSizeKib`: The size of the sections that are read from the OCR files. The default is 8KiB.
-- `maxSectionCacheSizeKib`: The maximum memory that is used for caching sections. The default is 10 * `sectionReadSizeKib`.
+- `sectionReadSizeKiB`: The size of the sections that are read from the OCR files. The default is 8KiB.
+- `maxSectionCacheSizeKiB`: The maximum memory that is used for caching sections. The default is 10 * `sectionReadSizeKiB`.
 
 ## Concurrency
 The plugin can read multiple files in parallel and also process them concurrently. By default, it will

src/main/java/com/github/dbmdz/solrocr/reader/BaseSourceReader.java

@@ -218,7 +218,7 @@ public Section getAsciiSection(int offset) throws IOException {
     int readLen = Math.min(sectionSize, this.length() - startOffset);
     int numRead = 0;
     while(numRead < readLen) {
-      numRead += this.readBytes(copyBuf, 0, startOffset, readLen);
+      numRead += this.readBytes(copyBuf, numRead, startOffset + numRead, readLen - numRead);
     }
     // Construct a String without going through a decoder to save on CPU.
     // Given that the method has been deprecated since Java 1.1 and was never removed, I don't think