الطباعة وإخراج PDF في تطبيقات أعمال Windows ── التمييز بين System.Drawing.Printing و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 تكوين يقدّم أمانة جهاز العرض والطباعة.⁸⁹
• تعيين الورق والدرج يتم بـ PrintDialog وPrintTicket/PrintQueue في WPF. القاعدة قبل الطباعة التحقق والدمج مقابل قدرات الطابعة الفعلية بـ PrintQueue.MergeAndValidatePrintTicket.¹⁰¹¹
• Microsoft Print to PDF برنامج تشغيل طباعة يفترض تشغيلاً تفاعلياً. موضعه طابور طباعة وحزمة برنامج تشغيل محمّلان قياسياً في نظام التشغيل، والتكوين الأساسي أن يتدخّل مربع حوار اختيار وجهة الحفظ في كل تنفيذ، فلا يصلح للمعالجة الدفعية بلا إشراف.¹²
• أتمتة Office COM من خادم أو خدمة Microsoft تعلن رسمياً أنها غير مدعومة وغير موصى بها. صُممت تطبيقات Office بافتراض سطح مكتب تفاعلي وملف تعريف مستخدم، وقد تتصرف بعدم استقرار أو تصل إلى deadlock في بيئة بلا إشراف وغير تفاعلية.¹³
• خدمة 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
    accTitle: مسار طباعة GDI ومسار طباعة XPS
    accDescr: تطبيق WinForms يمر بمسار GDI، وتطبيق WPF بمسار XPS. الإرسال من WPF إلى طابعة لا تدعم XPSDrv يُحوَّل في الطريق إلى صيغة GDI.
    WF["تطبيق WinForms<br/>الخيار ① PrintDocument"] --> GDI["مسار طباعة GDI<br/>لف أوامر الرسم كـ EMF للمُبَكِّر"]
    WPF["تطبيق WPF<br/>الخيار ② FlowDocument وFixedDocument"] --> XPS["مسار طباعة XPS<br/>اللف كوثيقة 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 الطابعة فيعمل بدقة أعلى بكثير، غالباً نحو 600 DPI، تحدّدها PageSettings.PrinterResolution.³ تمرير إحداثيات بكسل محسوبة للشاشة كما هي إلى Graphics الطباعة يرسم أصغر كثيراً مما قُصد (أو أكبر بحسب إعداد الدقة العالية). في الطباعة الأسلم تجميع الإحداثيات دائماً بوحدة 1/100 بوصة (hundredths of an inch) أو بالقياس الفعلي (ملليمتر أو بوصة)، بتصميم لا يعتمد على دقة Graphics.

وما يسهل تفويته أيضاً المنطقة الفيزيائية غير القابلة للطباعة التي تملكها الطابعة. كثير من الطابعات لا تطبع نطاقاً بعدة ملليمترات من طرف الورقة. هذا القيد الفيزيائي يُحصَل عليه بـ PageSettings.HardMarginX/HardMarginY، وتشرحه الوثائق الرسمية بأنه «يمثّل الهامش الفيزيائي الذي تضبطه الطابعة».⁴ الهامش المنطقي الذي يحدّده جانب التطبيق هو PageSettings.Margins (الافتراضي بوصة واحدة من الجهات الأربع)، وحتى ضبطه على 0 لا يُخرج إلى داخل أضيق من الهامش الصلب للطابعة.⁵ كثير من أعطال «ضبطت الهامش على 0 فانقطع الطرف / انزاح أكثر مما ظننت» سببها عدم وعي وجود هذا الهامش الصلب.

المهم هنا أن هذين يُقرَّران منفصلين. الهامش الصلب تقرّره الطابعة، وMarginBounds يُحسب من Margins التي حدّدها التطبيق فقط. MarginBounds لا يُقرَّب تلقائياً إلى النطاق القابل للطباعة. العلاقة إذا رُسمت ليست تداخلاً متداخلاً، بل كالتالي.

flowchart TB
    accTitle: MarginBounds والهامش الصلب يُقرَّران منفصلين
    accDescr: يُحسب MarginBounds من Margins فقط ولا يُقرَّب إلى النطاق القابل للطباعة. إذا صغّرت Margins عن الهامش الصلب، خرج MarginBounds من النطاق القابل للطباعة.
    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 (وحدة 1/100 بوصة).¹⁷
• MarginBounds: منطقة الرسم التي تعكس Margins التي حدّدها التطبيق (الافتراضي بوصة واحدة من الجهات الأربع).⁵

أي أنه عندما يكون الهامش المنطقي أصغر من الهامش الصلب كما عند ضبط Margins على 0، يخرج MarginBounds خارج النطاق القابل للطباعة. الرسم عندئذ بمعيار MarginBounds يقطع محتوى الشريط الخارج فلا يُطبع. هذا هو حقيقة «ضبطت الهامش على 0 فانقطع الطرف».

للميل إلى الجانب الآمن خذ أحد التالي.

• اجعل الهامش المنطقي أكبر من الهامش الصلب أو مساوياً له. قارن كل ضلع من Margins بـ HardMarginX / HardMarginY، وارفع الأصغر
• اطلب المستطيل المستخدَم في الرسم بتداخله مع PrintableArea. لا تستخدم MarginBounds كما هو، وخذ الجزء المشترك مع النطاق القابل للطباعة بـ Rectangle.Intersect

// PrintPage イベント内。単位はすべて100分の1インチ
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
{
    // 印刷対象データ。1行1件の伝票明細を想定
    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になる(オフライン検知には使えない)
        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("メイリオ", 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، فاضبط بعد الحكم صراحة على «هل بقيت أسطر ينبغي رسمها».¹² إذا أردت عكس إعدادات مختلفة لكل صفحة (مقاس الورق أو الاتجاه وغيرها) يمكن الاستفادة أيضاً من حدث QueryPageSettings إضافة إلى PrintPage.

النمط النموذجي لعطل «الهامش ينزاح» تجميع الإحداثيات بمعيار e.Graphics.VisibleClipBounds أو e.PageBounds، وتجاهل MarginBounds (المنطقة التي تعكس الهامش المنطقي) وHardMarginX/HardMarginY (القيد الفيزيائي للطابعة).⁴ خصوصاً أن طابعة جهاز التطوير قد يكون هامشها الصلب صغيراً فلا تظهر المشكلة مصادفة، وفي جهاز آخر عند التسليم يكون الهامش الصلب كبيراً فتبدو الخطوط والبنود مقطوعة. التحقق بالطباعة على أجهزة عدة مرحلة يسهل تفويتها عند التطوير.

عند تقديم معاينة استخدم PrintPreviewDialog وعيّن PrintDocument نفسه لخاصية Document، فيُعاد استخدام منطق حدث PrintPage كما هو.¹ إذا أردت تبديل الإخراج حسب دقة الطابعة، احصل على الخيارات من PrinterSettings.PrinterResolutions وعيّنها في PageSettings.PrinterResolution.³

4. WPF: FlowDocument / FixedDocument وPrintDialog

في WPF يتغيّر محور FlowDocument أو FixedDocument بحسب طبيعة الوثيقة.

• FlowDocument. وثيقة تقدّم القراءة، تعيد تخطيط المحتوى ديناميكياً حسب متغيرات وقت التشغيل مثل حجم النافذة وإعداد الخط. تملك قياسياً وظائف البحث والترقيم وتغيير وضع العرض.⁸
• FixedDocument. وثيقة WYSIWYG تقدّم الأمانة، يتحكم جانب التطبيق في التخطيط تماماً. تناسب عندما تلزم إعادة إنتاج عالية الدقة لجهاز العرض والطباعة.⁹

الخط الأساسي: تقرير داخلي يقدّم سهولة القراءة بالتدفق فـ FlowDocument، وقسيمة أو ملصق تريد تثبيت موضع الخطوط والبنود بالبكسل فـ FixedDocument.

الطباعة الأساسية تتم بـ System.Windows.Controls.PrintDialog. هذا الصنف غير System.Windows.Forms.PrintDialog، وهو خاص بـ WPF.¹⁰

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».
• تشغيل Excel.Application فعلاً عبر Excel COM Interop. يُختار عندما تريد إعادة استخدام مصنف Excel قائم كما هو بما فيه وحدات الماكرو وإعادة الحساب المعقّدة، لكن يسهل وقوع مشكلة بقاء عملية EXCEL.EXE بتسرّب مراجع COM، والإجراءات ومعيار الحكم متناولان في «مشكلة بقاء EXCEL.EXE عند التعامل مع Excel من C#».

المهم هنا أن أتمتة Office COM من جانب الخادم أو خدمة Windows Microsoft تعلن رسمياً أنها «غير موصى بها وغير مدعومة». تطبيقات Office مصممة بافتراض سطح مكتب تفاعلي وملف تعريف مستخدم مسجّل دخوله، ويُقال إنها قد تتصرف بعدم استقرار أو تصل إلى deadlock إذا نُفّذت في بيئة بلا إشراف وغير تفاعلية.¹³ ومن جهة الترخيص أيضاً، استخدام يقدّم وظائف Office للعميل بأتمتة في جانب الخادم ليس مفترضاً في EULA العادي.¹³

لذلك إذا أردت إدماج إخراج التقارير في خدمة مقيمة أو مهمة دفعية، حتى مع إعادة استخدام قالب Excel قائم، فالأسلم تجنّب التكوين الذي يشغّل Excel.exe فعلاً وقت التشغيل (COM Interop) والميل إلى التوليد المباشر للملف بـ Open XML SDK وغيره. إذا لزم COM Interop حتماً، فالتمييز الواقعي تكوينه تطبيقاً مقيماً يعمل في جلسة مستخدم مسجّل دخولاً تفاعلياً (وليس خدمة).

7. مطبات الممارسة

الطباعة من خدمة Windows والجلسة 0

الاستشارة بإدماج معالجة الطباعة في خدمة مقيمة ليست قليلة، لكن خدمة Windows تعمل في الجلسة 0. الجلسة 0 جلسة محجوزة منذ Windows Vista للخدمات والعمليات غير المرتبطة بمستخدم تفاعلي، ومفصولة عن الجلسة التفاعلية للمستخدم.¹⁴ بهذا العزل، حتى إذا عرضت الخدمة مربع حوار لم يره المستخدم، وشيفرة تنتظر إدخال المستخدم (انتظار عرض مربع حوار الطباعة مثلاً) تبدو معلَّقة.¹⁴

وما يسهل أن يصير مطبقاً عملياً أيضاً كيفية ظهور طابعة شبكة أو طابعة معيَّنة فردياً للمستخدم. طابعة الشبكة التي اتصل بها المستخدم بعد تسجيل الدخول كثيراً ما تظهر مرتبطة بجلسته التفاعلية، ومن سياق عملية الخدمة في الجلسة 0 (جلسة أخرى) لا تظهر بالمثل. معالجة مقيمة تصاحبها طباعة يلزم تأكيد «من أي حساب وأي جلسة تُرى أي طابعة» في أول التصميم. الصورة الكلية لعزل الجلسات مرتّبة في «كيف نفهم عزل الجلسات في Windows»، وأساس التنفيذ والتشغيل كخدمة في «كيفيّة إنشاء خدمات Windows وتشغيلها».

السلوك عند غياب الطابعة أو كونها غير متصلة

تعيين اسم طابعة غير موجودة في PrinterSettings.PrinterName، أو التنفيذ في بيئة بلا طابعة افتراضية مضبوطة، يُحدث استثناء أو فشلاً عند محاولة الطباعة. التحقق مسبقاً بـ PrinterSettings.IsValid، وتصميم إعادة المحاولة وإشعار الخطأ بافتراض فشل الطباعة، نقطتان يُراد تثبيتهما كحد أدنى. إذا كانت طابعة الشبكة غير متصلة مؤقتاً، قد تُكدَّس المهمة في المُبَكِّر ويبقى الإخراج الفعلي متوقفاً، فلا تُنهِ نتيجة الطباعة عند «أُرسلت»، وانظر عند الحاجة آلية تؤكد حالة المهمة.

خطر الاعتماد على الطابعة الافتراضية

تنفيذ لا يصرّح بـ PrinterSettings.PrinterName ويعتمد دائماً على «الطابعة الافتراضية» يصير خطراً كلما طال التشغيل. تغيّر البيئة ── المستخدم يغيّر طابعة أخرى إلى الافتراضية، أو يُخرج حاسوباً محمولاً إلى مكان آخر فتتغيّر الطابعة الافتراضية ── يرسل إلى وجهة غير مقصودة. التقارير المهمة للعمل ينبغي أن تحتفظ صراحة باسم طابعة الوجهة في ملف إعداد أو شاشة إعداد داخل التطبيق، بتصميم لا ينجرّ وراء تغيّر الطابعة الافتراضية.

تسرّب مقابض GDI في التشغيل الطويل

كتابة شيفرة داخل معالجة الطباعة لا تحرّر موارد GDI/GDI+ مثل Graphics وFont وBrush وPen بـ using أو Dispose() تؤدي بعد التشغيل الطويل إلى نضوب مقابض كائنات GDI، فتبدأ استدعاءات واجهات الرسم بالفشل. مقابض كائنات GDI سقف افتراضي لكل عملية، مورد محدود يمكن ضبطه في نطاق 256 إلى 65,536 بقيمة سجل GDIProcessHandleQuota.¹⁵ كلما كان التطبيق مقيماً يطبع بكثرة، مال هذا النوع من التسرّب إلى عطل لا يظهر إلا في بيئة الإنتاج. طريقة البحث عن تسرّب المقابض وعزله مشروحة بتفصيل في «حين يتعطّل تطبيق التحكّم بكاميرا صناعيّة فجأةً بعد شهر (الجزء الأوّل)» التي تناولت حالة تعطل تشغيل طويل لكاميرا صناعية.

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).

ما تؤكده قبل التنفيذ

• قرّر الوحدة ونظام الإحداثيات أولاً. لا تُعد استخدام إحداثيات بكسل الشاشة في الطباعة كما هي. اجعل وحدة 1/100 بوصة أو القياس الفعلي (ملليمتر أو بوصة) معياراً (الفصل 2).
• افهم أن الهامش مستويان. ارسم بمعيار MarginBounds لا بمعيار PageBounds. حتى ضبط Margins على 0 لا يُخرج إلا داخل الهامش الصلب (الفصل 2، الشكل 2).
• اضبط HasMorePages صراحة. اضبط بعد الحكم على «هل بقيت أسطر للرسم». الافتراضي false، ونسيان الضبط السبب النموذجي لـ «الصفحة الثانية لا تخرج» (الفصل 3).
• احتفظ صراحة بطابعة الوجهة. لا تعتمد على الطابعة الافتراضية، واجعل اسم الطابعة في ملف إعداد أو شاشة إعداد التطبيق (الفصل 7).
• حرّر موارد GDI حتماً بـ using. تسرّب Font وBrush وPen لا يظهر إلا في بيئة إنتاج تشغيل طويل (الفصل 7).
• الطباعة من خدمة أكّد الحد أولاً. في الجلسة 0 لا تُعرض مربعات الحوار، ولا تُرى طابعات الشبكة المرتبطة بالمستخدم (الفصل 7).
• تحقق على أجهزة عدة. حجم الهامش الصلب يختلف حسب الجهاز، فقد لا تكون مشكلة في جهاز التطوير وتنقطع الخطوط عند التسليم (الفصل 3).

مقالات ذات صلة

• كيف تبني إخراج تقارير Excel - COM وOpen XML والقوالب
• مشكلة بقاء EXCEL.EXE عند التعامل مع Excel من C# ── أنماط تحرير مراجع COM وقرار الاستبدال
• كيفيّة إنشاء خدمات Windows وتشغيلها ── من التمييز عن جدولة المهام إلى تحويل BackgroundService إلى خدمة
• كيف نفهم عزل الجلسات في Windows ── Session 0 وRDP وتشغيل عدة مستخدمين معاً
• حين يتعطّل تطبيق التحكّم بكاميرا صناعيّة فجأةً بعد شهر (الجزء الأوّل) - كيفيّة العثور على handle leak

مجالات استشارية ذات صلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تصميم ميزات الطباعة وإخراج التقارير في تطبيقات أعمال Windows، وإعادة بناء التقارير بالاستفادة من أصول Excel القائمة، والاستشارة التقنية في تصميم الطباعة والإخراج من خدمة مقيمة.

• الاستشارات التقنية ومراجعة التصميم
• تطوير تطبيقات Windows
• تواصل معنا

روابط مرجعية

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

أيهما ينبغي استخدامه: PrintDocument أم طباعة WPF؟

إذا كانت الشاشة WinForms فاستخدم PrintDocument ببساطة، وإذا كانت WPF فاستخدم FlowDocument/FixedDocument. لا حاجة لخلط التقنيتين، والمعيار العملي مطابقة إطار عمل الشاشة القائم في التطبيق. وإذا اخترت WPF في تطوير جديد، فتقرير محور FlowDocument أو FixedDocument مسبقاً بحسب كون التقرير تدفقاً أو تخطيطاً ثابتاً يمنع التردد لاحقاً.

هل ينبغي شراء مكتبة تقارير؟

إذا كانت تكلفة بناء تقارير معقّدة كثيرة الخطوط، ودعم مقاسات ورق متعددة، وتضمين خطوط يابانية أو كتابة عمودية، ذاتياً برسم GDI+/WPF كبيرة، فغالباً ما تكون تكلفة إدخال مكتبة تقارير أرخص. وبالعكس، لتقرير بسيط بحجم قائمة A4 غالباً يكفي التنفيذ الذاتي عبر PrintDocument أو FixedDocument، فالأسلم تقدير تعقيد المتطلبات أولاً ثم الحكم.

هل يجوز تكوين ينشئ PDF فقط دون استخدام الطباعة؟

جائز تماماً. PDF صيغة إخراج واحدة، والتوليد المباشر بمكتبة PDF لا يعتمد على مربع حوار الطباعة أو الطابعة الافتراضية، وغالباً ما يتوافق أفضل مع المعالجة الدفعية والأتمتة. أما Microsoft Print to PDF فبرنامج تشغيل يفترض تشغيلاً تفاعلياً، ولا يصلح لتوليد PDF بلا إشراف.

هل يمكن دعم طابعات الملصقات أو طابعات الإيصالات؟

ممكن، لكن قد يصعب أحياناً كامتداد لـ PrintDocument/FixedDocument العام. فكثير من طابعات الملصقات لها لغة أوامر خاصة أو SDK، وكثيراً ما تُتحكَّم عبر مسار منفصل عن مسار الطباعة القياسي في Windows. ابدأ بتأكيد هل الجهاز المستهدف يتصرف كبرنامج تشغيل طابعة عادي في Windows، أم يحتاج تحكماً عبر SDK مخصّص.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.