我使用PDFiumSharp将每页转换为PNG图像，从而打印PDF文件。接下来，我将此图像绘制到Graphics。
private void PrintPage(object sender, PrintPageEventArgs ev)
{
ev.Graphics.DrawImage(images[pageNum], ev.Graphics.VisibleClipBounds);
pageNum++;
if (pageNum == images.Count)
{
ev.HasMorePages = false;
}
else
{
ev.HasMorePages = true;
}
}
public void Print()
{
printDocument.PrintPage += new PrintPageEventHandler(PrintPage);
pageNum = 0;
if (printDocument.PrinterSettings.IsValid)
{
printDocument.Print();
}
else
{
throw new Exception("Printer is invalid.");
}
}
问题是打印机接收的数据量很大，整个过程运行缓慢。我尝试在Windows上使用lpr命令。它可以直接处理PDF文件，但我的应用程序需要支持双面打印、不同的纸张来源等，这在lpr中是不可用的。
如何使用System.Drawing.Printig(或其他提供类似功能的软件(打印PDF而不转换为图像？我使用.NET Core 3.1，我的应用程序应该是跨平台的。
实际上，您需要选择3中的任意2个：
- 不使用光栅图像直接将数据发送到打印机
- 使用System.Drawing.Printing
- 跨平台
例如，1和2在Windows上可以正常工作。有一些跨平台的PDF库可以直接解析PDF并将其打印到System.Drawing.Graphics。
问题是System.Drawing在Linux和macOS上不能很好地工作。它使用libgdiplus，这种实现有许多实际问题
例如，libgdiplus不能很好地处理剪切路径。我修复了一些相关问题(#545、#547、#552(，并发现了严重的阻碍因素，可以进一步改进。
第一个是维护人员。他们没有回答问题，而是几个月前审查了简单的提款请求。看起来微软对这个项目不太感兴趣。
第二个阻碍因素是内部架构。有两个旧的区域实现(基于位图和矩形(应该重新考虑。然而，如果没有与维护人员的沟通，进行架构更改也是不可行的。
我认为你有两个选择：
-
使用可以打印到System.Drawing.Graphics而不需要中间图像的PDF库(如上面的示例(。它在Windows上运行良好。在Linux上，您需要：
- 自行修复libgdiplus中发现的问题，在生产中使用自定义版本
- 将PDF渲染为图像，然后打印光栅图像
-
不要使用System.Drawing.Printing