管道的 Ghostscript（MinGW 编译）问题

Question

解决方案在最后一条评论中，但以防万一有人在寻找解决方法，我在这里总结了它：http://sourceforge.net/mailarchive/message.php?msg_id=30391589

---

我设法使用 MinGW 和当前稳定的 GhostScript (9.06) 构建了GSDjVu。将 Bash 脚本转换为 CMD 的任务并不难，但令我惊讶的是 gsdjvu（带有 gsdjvu 驱动程序的 gs 解释器）没有按预期接受 PDF 输入。它只接受 PostScript。为了避免编写巨大的临时文件，我想创建一个管道，这里是示例：

set args=-sstdout=nul -dSAFER -dNOPAUSE -dBATCH

gs %args% -sDEVICE=pswrite -sOutputFile=- test.pdf |^
   gsdjvu %args% -sDEVICE=djvusep -sOutputFile=- - |^
   csepdjvu - test.djvu

这会导致错误：

*** csepdjvu: corrupted input file (lost RLE sync.)
*** (..\..\..\tools\csepdjvu.cpp:647)

Internal error at ./base/gdevdjvu.c:2831

 
如果我将gsdjvu 的结果输出到文件而不是管道，则没有错误：

gs %args% -sDEVICE=pswrite -sOutputFile=- test.pdf |^
   gsdjvu %args% -sDEVICE=djvusep -sOutputFile=test.sep -

csepdjvu test.sep test.djvu

 
现在，如果我比较来自gsdjvu (test.sep) 的文件输出和来自相同 (test2.sep) 的管道输出：

gs %args% -sDEVICE=pswrite -sOutputFile=- test.pdf |^
   gsdjvu %args% -sDEVICE=djvusep -sOutputFile=- - > test2.sep

我得到了这个差异：

经过简单分析，0A 在管道输出中表示为0D0A，或者“行尾”从 Unix LF 更改为 Windows CRLF。

为什么会这样，有办法补救吗？
或者它可能是一个错误？

Answer 1

我不确定 DjVuLibre 如何无法接受 PDF 作为输入，因为据我所知它是一个 Ghostscript 设备。你有一些文件说这不能做吗？如果是这样，我会向维护者投诉，我看不出有任何原因。

由于这适用于文件输出，因此合乎逻辑的答案是正在进行一些换行符转换。

一些快速的谷歌搜索显示有很多关于此的讨论，但我看不到任何与您的体验完全匹配的内容。您可能应该将此标记为 MingW，或者更明智地将其带到 MingW 支持论坛。

或者只是停止对 I/O 进行管道传输。