Печать и PDF в Windows-приложениях: PrintDocument, WPF и библиотеки отчётов

Печать в Windows-приложении не сводится к фразе «нарисуем что-нибудь через PrintDocument — и готово». Не работают разрывы страниц, съезжают поля, предпросмотр не совпадает с бумагой, а между приложением и нужным PDF вклинивается диалог печати. Обычно так бывает, когда реализацию начинают, не разобравшись в самом механизме печати.

В этой статье четыре варианта разобраны с точки зрения выбора по требованиям. Дальше на них ссылаюсь по этим номерам.

1. Сначала вывод

• Для простых списков и как продолжение уже существующего WinForms-кода обычно хватает PrintDocument. Разрыв страницы устроен так: событие PrintPage вызывается снова, пока HasMorePages не станет false. Если это забыть, вторая страница и дальше не выйдут. ¹²
• DPI печати — это не DPI экрана. PageSettings.PrinterResolution — разрешение принтера. Поля складываются из двух уровней: PageSettings.HardMarginX / HardMarginY (область, в которой принтер физически не печатает) и Margins (логические поля, которые задаёт приложение). Если экранные координаты просто перенести в печать, вёрстка съедет из-за разницы DPI и систем координат. ³⁴⁵
• В WPF стандартный путь печати Windows разделён на два: путь GDI и путь XPS. Приложение WPF по замыслу идёт по пути XPS; если задание уходит на принтер без XPSDrv, данные автоматически преобразуются в формат GDI. ⁶⁷
• У документов WPF разный замысел: FlowDocument — перетекание, FixedDocument — фиксированная вёрстка. FlowDocument ставит читаемость выше и перестраивает вёрстку под размер окна и разрешение; FixedDocument ставит выше точность на устройстве отображения и печати. ⁸⁹
• Бумагу и лоток в WPF задают через PrintDialog и PrintTicket / PrintQueue. Перед печатью принято слить запрос с реальными возможностями принтера и проверить его через PrintQueue.MergeAndValidatePrintTicket. ¹⁰¹¹
• Microsoft Print to PDF — драйвер печати, рассчитанный на интерактивную работу. Это очередь печати и пакет драйвера, которые поставляются с ОС. Как правило, при каждом запуске появляется диалог выбора пути сохранения, поэтому для пакетной обработки без оператора он не подходит. ¹²
• Автоматизацию Office через COM с сервера или из службы Microsoft официально не поддерживает и не рекомендует. Office рассчитан на интерактивный рабочий стол и профиль пользователя; в необслуживаемой неинтерактивной среде возможны нестабильная работа и взаимная блокировка. ¹³
• Служба Windows работает в сеансе 0, поэтому не может показать диалог и не должна опираться на принтер по умолчанию из сеанса пользователя. Если проектируете печать из постоянно работающего процесса, эту границу нужно учитывать с самого начала. ¹⁴
• Если в долго работающем процессе не освобождать объекты GDI (дескрипторы), можно упереться в лимит на процесс и получить сбой. Лимит конечен: его можно менять через GDIProcessHandleQuota в реестре, бесконечно выделять объекты нельзя. ¹⁵

Таблица выбора: требование × средство

Дальше разберём каждый пункт подробнее.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 21, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Минимум о печати в Windows

Сначала определим термины, которые дальше используются в этой главе.

Архитектура печати Windows состоит из диспетчера печати и драйверов отдельных принтеров. Приложение вызывает функции, не зависящие от устройства, и может отправить задание на самые разные выходы: лазерный принтер, векторный плоттер, растровый принтер, факс. ¹⁶

Путей печати два.

• Путь печати GDI. Когда печатает Win32-приложение на GDI, графический движок GDI либо кладёт команды рисования в очередь как EMF (расширенный метафайл), либо вместе с драйвером сразу строит печатаемое изображение и отдаёт его диспетчеру печати. По этому пути идут обычные приложения WinForms. ¹⁶⁶
• Путь печати XPS. Это путь для драйверов на основе XPS (XML Paper Specification). Приложение WPF по замыслу идёт сюда и отправляет в диспетчер печати XPS-документ. Если у целевого принтера нет драйвера XPSDrv, данные автоматически преобразуются в формат GDI и только потом уходят дальше. ⁶⁷

На схеме это выглядит так. Каким бы путём ни шли, в конце всё равно есть диспетчер печати и драйвер.

flowchart LR
    WF["приложение WinForms<br/>вариант ① PrintDocument"] --> GDI["путь печати GDI<br/>команды рисования уходят в spool как EMF"]
    WPF["приложение WPF<br/>вариант ② FlowDocument и FixedDocument"] --> XPS["путь печати XPS<br/>в spool как XPS-документ"]
    XPS -->|"принтер с XPSDrv"| SPL["диспетчер печати"]
    XPS -->|"принтер без XPSDrv"| CONV["автопреобразование в формат GDI"]
    CONV --> SPL
    GDI --> SPL
    SPL --> DRV["драйвер принтера"]
    DRV --> OUT["принтер, факс<br/>Microsoft Print to PDF и др."]

Рис. 1. Путь печати GDI и путь печати XPS. Если WPF отправляет задание на принтер без XPSDrv, данные по пути преобразуются в формат GDI.

Почему вид на экране и печать не совпадают. Самая частая причина — путаница DPI. Экранный Graphics обычно строит координаты около 96 DPI, а Graphics принтера работает с разрешением PageSettings.PrinterResolution, чаще всего около 600 DPI. ³ Если пиксельные координаты, посчитанные для экрана, передать печатному Graphics как есть, рисунок выйдет гораздо мельче задуманного — или, при другом разрешении, крупнее. Для печати безопаснее собирать координаты в сотых долях дюйма (hundredths of an inch) или в физических единицах (миллиметры, дюймы) и не зависеть от разрешения Graphics.

Ещё одна часто упускаемая вещь — область, в которой принтер физически не печатает. Многие принтеры не могут печатать несколько миллиметров от края листа. Это ограничение доступно через PageSettings.HardMarginX / HardMarginY; в документации оно описано как физические поля, которые задаёт принтер. ⁴ Логические поля приложения — PageSettings.Margins (по умолчанию один дюйм со всех сторон). Даже если поставить их в ноль, печатать внутри аппаратных полей нельзя. ⁵ Многие дефекты вида «поля обнулили, а край режется или всё съезжает» происходят от того, что об этих физических полях забывают.

Важно, что эти два значения задаются независимо. Аппаратные поля определяет принтер, а MarginBounds считается только из Margins, которые задало приложение. MarginBounds сам по себе к области печати не округляется. На схеме это не вложенность, а так:

flowchart TB
    subgraph PB["PageBounds — размер всего листа"]
      HM["область печати<br/>PrintableArea, HardMarginX, HardMarginY<br/>задаёт принтер; приложение сузить не может"]
      MB["MarginBounds<br/>считается только из Margins<br/>к области печати не округляется"]
    end
    HM --> SAFE["гарантированно печатаемая область — пересечение двух"]
    MB --> SAFE

Рис. 2. MarginBounds и аппаратные поля задаются независимо. Если Margins меньше аппаратных полей, MarginBounds выходит за область печати.

• PageBounds: размер всего листа.
• Аппаратные поля: физическая область, в которой принтер не печатает. Её можно прочитать через HardMarginX / HardMarginY; приложение сузить её не может. ⁴ Саму область печати даёт PageSettings.PrintableArea (в сотых долях дюйма). ¹⁷
• MarginBounds: область рисования с учётом Margins, которые задало приложение (по умолчанию один дюйм со всех сторон). ⁵

То есть если логические поля меньше аппаратных — как при Margins равных нулю — MarginBounds выходит за область печати. Если рисовать, опираясь на такой MarginBounds, содержимое в выпирающей полосе не напечатается и край обрежется. В этом и состоит «поля обнулили, а край режется».

Чтобы уйти в безопасную сторону, берут один из двух приёмов.

• Сделать логические поля не меньше аппаратных. Каждую сторону Margins сравнивают с HardMarginX / HardMarginY и меньшую поднимают.
• Прямоугольник для рисования получить как пересечение с PrintableArea. MarginBounds как есть не используют, а берут общую часть с областью печати через Rectangle.Intersect.

// Внутри события PrintPage. Все единицы — сотые доли дюйма
private void OnPrintPage(object? sender, PrintPageEventArgs e)
{
    PageSettings page = e.PageSettings;

    // Область печати от левого верхнего угла листа. Левый верх — сами аппаратные поля
    var printableOnPaper = new RectangleF(
        page.HardMarginX, page.HardMarginY,
        page.PrintableArea.Width, page.PrintableArea.Height);

    // MarginBounds — расчёт из Margins, к области печати он не округлён.
    // Пересечение даёт диапазон, который не обрежется даже на модели с большими аппаратными полями.
    // До этой точки начало координат — левый верхний угол листа
    Rectangle safeOnPaper = Rectangle.Intersect(
        e.MarginBounds, Rectangle.Round(printableOnPaper));

    // Здесь легко ошибиться. Когда OriginAtMargins по умолчанию false, начало
    // координат e.Graphics — левый верх области печати, а не листа. Если рисовать
    // в координатах листа, рисунок уедет вправо-вниз на величину аппаратных полей,
    // правый и нижний края выйдут за область печати и обрежутся — как раз тот
    // симптом, который этот пример должен предотвратить.
    // Перед рисованием переносим в координаты Graphics
    Rectangle safe = safeOnPaper;
    safe.Offset(
        -(int)Math.Round(page.HardMarginX),
        -(int)Math.Round(page.HardMarginY));

    e.Graphics!.DrawRectangle(Pens.Black, safe);
}

Если поставить OriginAtMargins = true, начало координат смещается, и эта поправка тоже меняется. Сначала решите, в какой системе рисуете, и только потом собирайте координаты. Если смешать подходы, позиция будет съезжать только на другой модели — такой сбой трудно искать.

Ещё одно место, где путают начало координат. У PrintDocument.OriginAtMargins значение по умолчанию — false. Тогда начало координат Graphics стоит в левом верхнем углу области печати, а Margins на это начало не влияет. ¹⁸ Если кажется, что «Margins задали, а сдвига нет» или наоборот «сдвиг лишний», сначала проверьте это. Чтобы начало оказалось внутри полей, явно поставьте OriginAtMargins = true.

3. WinForms: практика System.Drawing.Printing

Печать WinForms собирают вокруг компонента PrintDocument. Обычный порядок: создать PrintDocument, настроить PrinterSettings и DefaultPageSettings, рисовать в событии PrintPage и запускать печать методом Print(). ¹

using System;
using System.Collections.Generic;
using System.Drawing;
using System.Drawing.Printing;
using System.Windows.Forms;

public sealed class ReportPrinter
{
    // Данные для печати. Предполагается одна позиция документа в каждой строке.
    private readonly IReadOnlyList<string> _lines;
    private int _lineIndex;

    public ReportPrinter(IReadOnlyList<string> lines) => _lines = lines;

    public void Print(string printerName)
    {
        using var document = new PrintDocument();
        document.DocumentName = "Позиции заказа";
        if (!string.IsNullOrEmpty(printerName))
        {
            document.PrinterSettings.PrinterName = printerName;
        }

        // Если указано неизвестное имя принтера, здесь будет false (для проверки offline это не годится)
        if (!document.PrinterSettings.IsValid)
        {
            throw new InvalidOperationException(
                $"Указанный принтер не найден: {printerName}");
        }

        _lineIndex = 0;
        document.PrintPage += Document_PrintPage;
        document.Print();
    }

    private void Document_PrintPage(object? sender, PrintPageEventArgs e)
    {
        // MarginBounds — доступная для рисования область с учётом логических полей (Margins).
        // PageBounds — весь лист; содержимое может обрезаться, даже если рисовать внутри аппаратных полей
        using var font = new Font("Segoe UI", 10);
        float lineHeight = font.GetHeight(e.Graphics);
        float y = e.MarginBounds.Top;

        while (_lineIndex < _lines.Count)
        {
            if (y + lineHeight > e.MarginBounds.Bottom)
            {
                // Эта страница закончена. Есть продолжение — переходим к следующей.
                e.HasMorePages = true;
                return;
            }

            e.Graphics.DrawString(_lines[_lineIndex], font, Brushes.Black,
                e.MarginBounds.Left, y);
            y += lineHeight;
            _lineIndex++;
        }

        // Все строки нарисованы; это последняя страница
        e.HasMorePages = false;
    }
}

Типичный случай «вторая страница не выходит» — забыть явно поставить HasMorePages в false (значение по умолчанию — false) либо ошибиться в условии и выйти, оставив его всегда false. Событие PrintPage вызывается снова, пока это свойство не станет false; перед установкой явно определите, остались ли строки, которые ещё нужно нарисовать. ¹² Если на разных страницах нужны разные настройки (размер бумаги, ориентация), вместе с PrintPage используйте событие QueryPageSettings.

Типичный случай «съехали поля» — собрать координаты от e.Graphics.VisibleClipBounds или e.PageBounds и проигнорировать MarginBounds (область с логическими полями) и HardMarginX / HardMarginY (физическое ограничение принтера). ⁴ Особенно часто на принтере разработки аппаратные поля малы, и проблема не проявляется, а у заказчика модель с большими аппаратными полями — и линии с полями обрезаются. Проверка на нескольких моделях — этап, который на разработке легко пропустить.

Чтобы дать предпросмотр, тому же PrintDocument достаточно присвоить свойство Document у PrintPreviewDialog: логика PrintPage переиспользуется как есть. ¹ Если вывод нужно менять в зависимости от разрешения принтера, варианты берут из PrinterSettings.PrinterResolutions и записывают в PageSettings.PrinterResolution. ³

4. WPF: FlowDocument / FixedDocument и PrintDialog

В WPF выбор между FlowDocument и FixedDocument зависит от характера документа.

• FlowDocument. Документ, который динамически перестраивает содержимое под переменные выполнения — размер окна, настройки шрифта — и ставит читаемость выше. Поиск, разбиение на страницы и смена режима отображения есть из коробки. ⁸
• FixedDocument. WYSIWYG-документ, в котором вёрстку полностью контролирует приложение и важнее точность на устройстве отображения и печати. Подходит, когда нужна высокая воспроизводимость. ⁹

Для внутреннего отчёта, где важнее читаемость и перетекание, берите FlowDocument. Для накладной или этикетки, где положение линий и полей должно быть зафиксировано до пикселя, — FixedDocument.

Базовая печать идёт через System.Windows.Controls.PrintDialog. Это отдельный класс WPF, не равный System.Windows.Forms.PrintDialog. ¹⁰

using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;

public static class FlowDocumentPrinter
{
    public static void Print(FlowDocument document, string jobName)
    {
        var printDialog = new PrintDialog();

        // Печатать только если пользователь нажал OK
        if (printDialog.ShowDialog() != true)
        {
            return;
        }

        // У FlowDocument разные предпосылки размера страницы для экрана и для печати,
        // поэтому размер страницы и поля печатаемого содержимого нужно привести
        // к области печати принтера
        var paginator = ((IDocumentPaginatorSource)document).DocumentPaginator;
        paginator.PageSize = new Size(
            printDialog.PrintableAreaWidth, printDialog.PrintableAreaHeight);

        printDialog.PrintDocument(paginator, jobName);
    }
}

Чтобы точно задать размер бумаги, лоток и двустороннюю печать, используют PrintQueue и PrintTicket / PrintCapabilities. PrintTicket — инструкция заданию, PrintCapabilities — функции, которые принтер реально поддерживает. Запрошенные настройки принято слить с допустимыми значениями принтера и проверить через PrintQueue.MergeAndValidatePrintTicket. ⁷¹¹

using System.Linq;
using System.Printing;

public static class DuplexPrintTicketBuilder
{
    public static PrintTicket BuildDuplexTicket(PrintQueue printQueue)
    {
        PrintCapabilities capabilities = printQueue.GetPrintCapabilities();

        // Заранее проверить, поддерживает ли принтер двустороннюю печать (переплёт по длинной стороне)
        bool supportsDuplex = capabilities.DuplexingCapability
            .Contains(Duplexing.TwoSidedLongEdge);

        var requestedTicket = new PrintTicket();
        if (supportsDuplex)
        {
            requestedTicket.Duplexing = Duplexing.TwoSidedLongEdge;
        }

        // К стандартному PrintTicket пользователя сливаем только запрос на двустороннюю печать.
        // Неподдерживаемые элементы автоматически заменяются допустимыми значениями
        ValidationResult result = printQueue.MergeAndValidatePrintTicket(
            printQueue.UserPrintTicket, requestedTicket);

        return result.ValidatedPrintTicket;
    }
}

Если отчёт с фиксированной вёрсткой собран как FixedDocument и его отправляют напрямую по пути XPS, задание добавляют в PrintQueue методами Write / WriteAsync у XpsDocumentWriter. Для принтера без XPSDrv внутри выполняется автоматическое преобразование в формат GDI, так что вызывающей стороне путь учитывать не нужно. ⁷

5. Варианты вывода PDF

Требование «нужно вывести PDF» меняет проектирование в зависимости от того, какой из трёх смыслов имеется в виду.

1. Как продолжение печати достаточно, чтобы пользователь вручную выбрал сохранение в PDF.
2. Нужно генерировать PDF из приложения через диалог печати.
3. Печатать вообще не нужно, а в пакетной обработке без оператора массово создавать только PDF-файлы.

Microsoft Print to PDF рассчитан на случаи 1 и 2. Это функция, которая поставляется с Windows 10: очередь печати и пакет драйвера. Для печатающего приложения она выглядит как обычный принтер. ¹² По сути это механизм с интерактивным поведением: при каждой печати спрашивают имя файла назначения. Официально управление дано только в виде администрирования этой очереди и пакета драйвера — администратор может убрать их из образа. ¹² Для случая 3, где путь фиксирован и PDF нужно тихо выдавать массово, механизм не рассчитан. Если нужен случай 3, естественнее библиотека, которая генерирует PDF напрямую, минуя конвейер печати.

Когда выбираете библиотеку генерации PDF, до рекомендации конкретного продукта разложите требования компании по таким осям.

Условия лицензии меняются по продукту и версии. Перед выбором всегда читайте официальную документацию или сам текст лицензии. Конкретную библиотеку или продукт эта статья не рекомендует — показаны только оси сравнения и где эти сведения проверять.

Как искать кандидатов и сравнивать их. Если искать только по осям, вывод зависит от даты статьи, поэтому заранее зафиксируйте порядок обращения к первоисточникам.

Чаще всего пропускают этапы 4 и 5. Решить по обзорной статье, а потом обнаружить «поддерживался только .NET Framework» или «оказался AGPL, в свой продукт вставить нельзя» — значит выбросить всю работу на проверку. Пока не сузили список до одного кандидата, пройдите хотя бы 4 и 5 — так меньше возвратов.

6. Печатные формы через Excel / Word

Если отчёт уже ведут шаблоном Excel, часто реалистичнее опереться на этот актив, чем собирать всё заново. Крупных способов два.

• Генерировать или править xlsx/docx напрямую через Open XML SDK и аналоги. Исполняемый файл Excel/Word не запускается: читается и пишется сам формат (ZIP + XML), поэтому на сервере это стабильно. Хорошо сочетается со схемой, где линии и оформление шаблона оставляют, а подставляют только значения. Подробнее — в статье «Как строить вывод Excel-отчётов: COM, Open XML, шаблоны».
• Управлять настоящим Excel.Application через Excel COM Interop. Этот путь выбирают, когда нужно как есть прогнать существующую книгу с макросами или сложным пересчётом. Часто остаётся процесс EXCEL.EXE из-за неосвобождённых ссылок COM. Меры и критерии — в статье о том, когда при работе с Excel из C# остаётся EXCEL.EXE.

Важно, что автоматизацию Office через COM на сервере и из службы Windows Microsoft официально называет нерекомендуемой и неподдерживаемой. Приложения Office рассчитаны на интерактивный рабочий стол и профиль уже вошедшего пользователя; в необслуживаемой неинтерактивной среде возможны нестабильная работа и взаимная блокировка. ¹³ И по лицензии обычный EULA не предполагает отдавать клиентам функции Office за счёт автоматизации на стороне сервера. ¹³

Поэтому если вывод отчётов встраивают в постоянно работающую службу или пакетное задание, даже при переиспользовании шаблона Excel безопаснее не запускать Excel.exe во время работы через COM Interop, а перейти к прямой генерации файлов через Open XML SDK. Если COM Interop всё же необходим, реалистично вынести его в постоянно работающее приложение (не службу) в интерактивном сеансе вошедшего пользователя.

7. Практические ловушки

Печать из службы Windows и сеанса 0

Просьбы встроить печать в постоянно работающую службу встречаются часто, но службы Windows выполняются в сеансе 0. Начиная с Windows Vista сеанс 0 зарезервирован для служб и процессов, не связанных с интерактивными пользователями, и отделён от сеанса пользователя. ¹⁴ Из-за этого разделения диалог, который показывает служба, пользователь не увидит, а код, который ждёт его ввода — например диалог печати, — выглядит зависшим. ¹⁴

Ещё одна практическая ловушка — какие сетевые и назначенные конкретному пользователю принтеры вообще видны. Сетевой принтер, который пользователь подключил после входа, чаще виден в его интерактивном сеансе и не обязан быть виден в другом контексте — например в процессе службы сеанса 0. Для постоянно работающего процесса с печатью в начале проектирования нужно выяснить, какие принтеры видны какой учётной записи и из какого сеанса. Общая картина разделения сеансов — в статье «Как понимать изоляцию сеансов Windows», а основы реализации и эксплуатации служб — в «Как создавать службы Windows и как их эксплуатировать».

Когда принтера нет или он offline

Если в PrinterSettings.PrinterName указать несуществующее имя или запустить код там, где принтер по умолчанию не задан, попытка печати может закончиться исключением или отказом. Как минимум заранее проверяйте через PrinterSettings.IsValid и заложите повторные попытки и уведомление об ошибке. Когда сетевой принтер временно offline, задание может остаться в диспетчере печати без реального вывода. Не заканчивайте проверку на «отправить удалось»: при необходимости смотрите состояние задания.

Риск зависимости от принтера по умолчанию

Реализация, которая не задаёт PrinterSettings.PrinterName и всегда опирается на «принтер по умолчанию», со временем копит риск. Пользователь может сменить его, ноутбук в другом месте получит другой принтер по умолчанию — и важный документ уйдёт не туда. Для значимых отчётов явно храните имя принтера назначения в конфигурации или на экране настроек, чтобы смена принтера по умолчанию вас не утащила.

Утечка GDI-дескрипторов при долгой работе

Если в коде печати не освобождать через using или Dispose() ресурсы GDI/GDI+ вроде Graphics, Font, Brush и Pen, после долгой работы заканчиваются дескрипторы объектов GDI и вызовы рисования начинают отказывать. У дескрипторов объектов GDI есть лимит на процесс; это конечный ресурс, который через реестр GDIProcessHandleQuota можно настроить от 256 до 65 536. ¹⁵ Чем чаще печатает постоянно работающее приложение, тем выше шанс, что такая утечка проявится только в production. Как искать и локализовать утечку дескрипторов, разобрано на примере в статье о сбоях промышленной камеры при долгой работе.

8. Итог

Дерево решений: какой из четырёх вариантов брать

Варианты ①–④ из начала статьи сужаются, если задавать вопросы в таком порядке.

1. Печать вообще нужна? Если на выходе достаточно PDF-файла, а на бумагу пользователь печатает сам по желанию, самый прямой путь — ③ (прямая генерация библиотекой PDF), без конвейера печати. Microsoft Print to PDF предполагает интерактивный вопрос о пути сохранения и для пакетной обработки без оператора не подходит (глава 5).
2. Нужно ли переиспользовать существующий шаблон Excel или Word? Тогда ④. Автоматизацию COM из постоянно работающей службы или пакетного задания Microsoft явно не поддерживает, поэтому склоняйтесь к прямой генерации через Open XML SDK (глава 6).
3. Экраны на WinForms или на WPF? Ориентируйтесь на фреймворк существующего приложения. WinForms — ①, WPF — ②. Смешивать технологии не нужно (главы 3 и 4).
4. Если выбран WPF: перетекание или фиксированная вёрстка? Внутренний отчёт, где важнее читаемость, — FlowDocument; накладная или этикетка, где фиксируют положение линий, — FixedDocument (глава 4).

Что проверить до реализации

• Сначала зафиксируйте единицы и систему координат. Экранные пиксельные координаты в печать как есть не переносите. Опирайтесь на сотые доли дюйма или на физический размер в миллиметрах и дюймах (глава 2).
• Поля — два уровня. Рисуйте от MarginBounds, не от PageBounds. Даже при Margins равных нулю вывести можно только внутри аппаратных полей (глава 2, рис. 2).
• Явно задавайте HasMorePages. Сначала решите, остались ли строки для рисования, и только потом ставьте свойство. Значение по умолчанию — false; пропуск настройки — типичная причина «вторая страница не выходит» (глава 3).
• Явно храните принтер назначения. Не опирайтесь на принтер по умолчанию: имя держите в конфигурации или на экране настроек приложения (глава 7).
• Ресурсы GDI всегда освобождайте через using. Утечка Font, Brush, Pen проявляется только при долгой работе в production (глава 7).
• Печать из службы с самого начала сверяйте с границей сеанса. В сеансе 0 диалог показать нельзя, и сетевые принтеры пользователя тоже не видны (глава 7).
• Проверяйте на нескольких моделях. Размер аппаратных полей зависит от модели: на машине разработки всё может быть в порядке, а у заказчика обрежутся линии (глава 3).

Связанные статьи

• Как строить вывод Excel-отчётов: COM, Open XML, шаблоны
• Когда при работе с Excel из C# остаётся EXCEL.EXE: как освобождать ссылки COM и когда менять подход
• Как создавать службы Windows и как их эксплуатировать: от Планировщика заданий до превращения BackgroundService в службу
• Как понимать изоляцию сеансов Windows: сеанс 0, RDP и одновременная работа нескольких пользователей
• Расследование сбоев промышленной камеры при долгой работе: утечка дескрипторов

Связанные области консультаций

KomuraSoft LLC консультирует по проектированию печати и вывода отчётов в Windows-приложениях, по перестройке отчётов с использованием существующих активов Excel и по проектированию печати и вывода из постоянно работающих служб.

• Техническая консультация и ревью дизайна
• Разработка Windows-приложений
• Контакты

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Что выбрать: PrintDocument или печать WPF?

Если экраны на WinForms, естественный выбор — PrintDocument; если на WPF — FlowDocument или FixedDocument. Смешивать технологии не нужно: на практике ориентируются на UI-фреймворк уже существующего приложения. Если для нового проекта берёте WPF, заранее решите, будет ли отчёт в основном перетекать или у него фиксированная вёрстка, и от этого выберите FlowDocument либо FixedDocument.

Стоит ли покупать библиотеку отчётов?

Если самостоятельно собирать сложные формы с множеством линий, несколькими размерами бумаги, встраиванием японских шрифтов или вертикальным письмом средствами GDI+ или WPF дорого, библиотека отчётов часто обходится дешевле. Для простого списка на A4 обычно хватает собственного PrintDocument или FixedDocument. Безопаснее сначала оценить сложность требований.

Можно ли делать только PDF и не печатать?

Да. PDF — лишь один из форматов вывода; прямая генерация библиотекой PDF, без диалога печати и без принтера по умолчанию, чаще лучше сочетается с пакетной обработкой и автоматизацией. Microsoft Print to PDF — драйвер для интерактивной работы и не подходит для генерации PDF без участия пользователя.

Поддерживаются ли принтеры этикеток и чековые принтеры?

Да, но это не всегда продолжение обычного PrintDocument или FixedDocument. У многих принтеров этикеток свой командный язык или SDK, и управление идёт не по стандартному пути печати Windows. Сначала выясните, ведёт ли нужная модель себя как обычный драйвер Windows или требует отдельный SDK.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.