管道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.