Бесконечные фиктивные страницы в outpout docx с использованием Apache Poi

Итак... в основном у меня есть файл docx. И я должен сделать некоторые изменения форматирования в нескольких абзацах, а затем сохранить в новом файле. То, что я делаю, по существу следующее.

import scala.collection.JavaConversions._
import org.apache.poi.xwpf.usermodel._

def format( sourceDocumentPath: String, outputDocumentPath: String ) {

  val sourceXWPFDocument = new XWPFDocument( new FileInputStream( sourcePath ) )

  // lets say I have a list of paragraph numbers... I want to format
  val parasToFormat = List( 2, 10, 15, 20 )

  val allParagraphs = sourceXWPFDocument.getParagraphs

  for ( ( paragraph, index ) <- allParagraphs.zipWithIndex ) {
    if( parasToFormat.contains( index ) ) {
      formatParagraph( paragraph )
    }
  }

  val outputDocx = new FileOutputStream( new File( outputDocumentPath ) );
  xwpfDocument.write( outputDocx )
  outputDocx.close()

}

def formatParagraph( paragraph: XWPFParagraph ): Unit = {
  // Do some color changing to few runs
  // Add few runs with new text.
}

В большинстве случаев все работает нормально. Выходной файл docx открывается в LibreOffice на моем Ubuntu.

Но когда я переношу этот вывод docx в систему Windows и пытаюсь открыть этот вывод docx в MS Word, я получаю бесконечные (постоянно растущие) страницы мусора.

Любые догадки из мудрого сообщества Poi приветствуются.

Кроме того... Один из моих догадок - Может быть, окончание строк в файлах запутывает MS Word. Поскольку Ubuntu использует (LF - \n) окончания строки, тогда как окна используют (CRLF - \r\n). Если это действительно проблема... тогда как я ее исправлю?

Хотя... Мой код находится в Scala... Я думаю, что подобное должно относиться и к Java-коду... и большинство пользователей Poi будут в сообществе java... Поэтому я также добавляю Java-тег.

Ответы

Ответ 1

Ну... так что я пробовал разные вещи и, наконец, решил проблему.

В основном проблема заключалась в следующем: очень простая вещь,

def copyRunFontSizeAttribute( sourceRun: XWPFRun, targetRun: XWPFRun ): Unit = {
  targetRun.setFontSize( sourceRun.getFontSize )
}

Как-то, установив размер шрифта экземпляра XWPFRun, скажем xWPFRunTarget к возвращаемому значению xWPFRunSource.getFontSize (где xWPFRunSource - еще один экземпляр XWPFRun), вызывает некоторые очень странные и неожиданные результаты.

Итак... на данный момент я удалил все те биты, где я делал эту copyRunFontSizeAttribute вещь, которая решила проблему.