Я хотел бы динамически генерировать контент, а затем отображать его в файл PDF. Эта обработка будет происходить на удаленном хост-сервере, поэтому использование виртуальных принтеров и т. д. исключено. Есть ли у кого-нибудь рекомендация для библиотеки .NET (предпочтительно С#), которая будет работать?
Я знаю, что могу сгенерировать кучу PS-кода и упаковать его самостоятельно, но на данном этапе я бы предпочел что-то менее сложное.
Спасибо!
Я успешно использовал SharpPDF.
Взгляните на http://itextsharp.sourceforge.net/. Его исходный код с открытым исходным кодом.
Учебное пособие: http://itextdocs.lowagie.com/tutorial/.
Я добился успеха, используя Siberix
Корпоративная лицензия: 350 долларов США (одна лицензия распространяется на неограниченное количество рабочих мест разработчика компании, неограниченное количество веб-серверов компании и неограниченное количество дистрибутивов в составе вашего приложения.)
Бесплатный PDF Generator .NET (оболочка WkHtmlToPdf) может создать красивый PDF-файл из HTML-шаблона с помощью одной строки кода. :
var pdfBytes = (new NReco.PdfGenerator.HtmlToPdfConverter()).GeneratePdf(htmlContent);
(все, что вам нужно, это одна DLL, никаких внешних зависимостей)
Мы используем Amyuni PDF Converter и успешно используем его уже несколько лет. Мы используем интерфейс COM, но он поддерживает интерфейс .NET.
У меня есть хороший опыт работы с преобразованием Winnovative HTML в PDF.
И плохие с Open Source HTML Doc (проблемы с элементами формы + CSS).
Я давно искал высокопроизводительный инструмент для преобразования docx в pdf. Наша система имеет аспект электронного правительства и генерирует очень большое количество отчетов для сообщества пользователей. В этот момент производительность имеет первостепенное значение.
Более ранние инструменты, которые я использовал, не выполняли одновременное преобразование, вместо этого каждый exe-файл должен был ждать завершения другого. Я попробовал Aspose.words и очень доволен результатами.
Прежде всего, это было очень легко и просто интегрировать и развернуть в нашем проекте. Очень гладкий.
Во-вторых, скорость конвертации намного лучше из-за того, что несколько заданий выполняются параллельно.
В-третьих, не только быстро, но даже без ошибок форматирования. Учитывая, что мы предоставляем многоязычную систему, а некоторые отчеты включают поля как на английском, так и на арабском языке (обратите внимание на выравнивание справа налево!), это было очень важно.
И, наконец, размер файла был довольно маленьким, что опять же очень важно, так как через нашу систему создаются десятки тысяч документов.
Нашей первой реализацией была библиотека Microsoft Office Interop. Мы конвертируем документы docx в pdf, используя приведенный ниже код. Эта библиотека отлично конвертирует документы docx в файлы pdf, и мы решили загрузить ее на сервер генерации отчетов. Но через некоторое время мы заметили, что операции преобразования ждут каждого исполняемого файла. Это вызывает большую задержку при одновременном преобразовании документов, и поэтому мы начинаем искать новый инструмент для преобразования файлов docx в файлы pdf. см. изображение
В приведенном ниже коде показано, как преобразовать документы docx в файлы pdf с помощью инструмента Aspose.Words for .NET. см. изображение 2
RDLC и элементы управления Report Viewer могут генерировать PDF-файл либо по усмотрению клиента, либо по команде сервера, который затем может использоваться как MIME-тип PDF.
Я использовал PDF4NET от O2solutions с большим успехом. Они поддерживают всевозможные сценарии и цифровую подпись PDF.
Если ваши данные в основном в формате XML, вы также можете рассмотреть решение XSL-FO — мы используем Alt- Xml2Pdf компании Soft с большим успехом. «Серверная» версия немного неверна — на самом деле это всего лишь одна DLL, которую вам нужно включить в ваше приложение Winforms, WPF или ASP.NET — вот и все!
Работает как шарм (если вы знакомы с XSLT и XSL-FO или хотите их изучить).
Марк
Мы использовали набор сторонних библиотек DLL из PDFSharp которые, в свою очередь, используют библиотеки DLL от MigraDoc. Я не знаю всех причин, по которым мы пошли в этом направлении (решение было принято старшим разработчиком), но я могу сказать вам, что:
