問題タブ [printdocument]

ヘッダーとフッターを .Net PrintDocument オブジェクトに実際に、または設計時に追加する最も簡単な方法は何ですか?

具体的には、サード パーティのグリッド コントロール (Infragistics GridEx v4.3) を印刷しようとしています。これは、PrintDocument オブジェクトを受け取り、それ自体を描画します。

結果のページにはグリッドとその内容だけが含まれていますが、印刷されたレポートを識別するヘッダーまたはタイトルを追加したいと考えています。

VB.Net 2.0 を使用しています。

ご協力いただきありがとうございます！

私の WinForms アプリでは、データをさまざまな場所に印刷できます。ユーザーが印刷するたびに、新しい PrintDocument インスタンスを作成します。これは、現在の印刷ジョブに使用されてから破棄されます。すべてが機能していますが、[印刷] ダイアログは常に既定のプリンターとその既定のパラメーターに戻されます。別のプリンターが選択されている場合、ユーザーは何度も何度もそのプリンターを選択する必要があります。

グローバルな PrintDocument インスタンスを 1 つ作成し、それをアプリケーション全体のすべての印刷ジョブで共有するのは一般的な方法ですか? このように、最後に選択したプリンターが常に使用されます。それとも他に方法はありますか？

ありがとう、ペトル

印刷時に180度反転/回転させたいドキュメントがあります。（これは、プリンターのラベルストックの向きによるものです）。

プロパティPrintDocument.PrinterSettings.LandscapeAngleがありますが、読み取り専用です。

このプロパティはプリンタドライバの影響を受けるため、「設定可能」ではないと思います。

厄介なことを何もしなくても、プリントを180度回転できる良い方法はありますか？

印刷用に独自の PrintDocument オブジェクトを生成する Winforms アプリケーションがあります。私自身のテストでは XP と Windows 7 で問題なく動作しますが、あるユーザーは、開いているドキュメントで印刷コマンドを選択すると、Vista で次の例外を受け取ります。

このエラーの性質と、これを複製する可能性のある方法を突き止めるのに苦労しています。実行可能ファイルのマニフェストは「制限付き」アクセス許可モードになっており、ユーザーが管理者としてアプリケーションを実行してもエラーが発生します。

当社では、MindFusion の WPF ダイアグラム コンポーネントを使用してアプリケーション (.NET 3.5 をターゲットとする WPF) を開発しています。明らかに、XPS ドキュメントを印刷および保存すると、さまざまなシステムでさまざまなエラーが発生します。

問題をアプリケーションから作成された 1 つのサンプルXPS ドキュメントに減らしました。まず、関連するシステムの概要を示し、xps ドキュメントを保存するときと、新しい WPF 印刷パスを使用して図のビジュアルを印刷するときの問題を分析します。次のリスト:

注: 3 つのシステムすべてに、Windows XP SP3 と .NET 3.5 Framework SP1 がインストールされています。

XpsDocumentWriter を使用して、Paginator で XPS ドキュメントを作成します。

PC 1 - XPS ビューアー (IE 7.0 で動作) が機能しません (.Net 3.5 の再インストール後でも)。Essential Pack の XPS Viewer でドキュメントを開きますが、ビューが完全にぼやけています。しかし、ご覧のとおり、スクリーンショットの右側にあるアプリケーションはDocumentViewer を使用してこの問題をテストしており、正しく動作しています。破損した XPS Viewer から印刷すると、画面上と同じ出力が得られますが、DocumentViewer の統合された印刷機能から (アプリケーションからの介入なしで) 印刷すると、ぼやけた出力が得られます。

PC 2 - IE XPS Viewer は正常に動作します。印刷出力に一貫性がありません。場合によっては、グラフィック (形状) が完全でないか、印刷デバイスが (同じドキュメントで) メモリ不足を通知します。

PC 3 – IE XPS Viewer は正常に動作しますが、印刷ジョブを開始すると常にIE 自体でこの例外が発生します。注: これまでに説明したすべての問題は、アプリケーションによって作成されたXPS ドキュメント(前述)でテストされています。

PrintDialog.PrintDocument と Paginator を使用して印刷ジョブを作成する:

私たちのアプリケーションから印刷すると、すべてのシステムで一貫した出力が得られます。ドキュメントが大きくなればなるほど (ページのメディア サイズに関して言えば)、ぼやけてしまいます。残念ながら、潜在的な原因の多くはすでに省略されています。ドキュメントを印刷するためのコードはかなり単純です。

• 独自のPaginatorを使用する代わりに、後者を、使用する MindFusion WPF ダイアグラム コンポーネントの別の Paginator 部分に置き換えました。私は同じ結果を達成しました。(このステートメントは、ファイルとして保存された XPSDocuments にも当てはまります)。

• 利用可能な最新の印刷ドライバーを使用しました

• PrintTicket Resolution の変更は、出力にまったく影響を与えないようです。

• ダイアグラムの代わりに別のビジュアル (アプリケーション自体のウィンドウなど) を使用しても、出力には影響しません。

これらのさまざまな問題により、複数の原因も考えられるようです。以前の除外により、いくつかの重要な設定がPrintTicketに欠落しているか、XPS から GDI への変換の背後で何かひどく問題が発生していると推測されます。これらの仮定とは別に、私はアイデアを使い果たしています。

注: すべての印刷デバイスには、XPS 以外のドライバーがあります。HP Designjet 500、HP 2100

最後に、XPS ドキュメント ファイルと印刷ジョブに使用されるものと同じPrintTicketをシリアル化しました。誰かが同様の問題を経験した場合、私は感謝します。どんな提案でも大歓迎です。

レシートを生成し、Graphicsオブジェクトを使用してDrawStringメソッドを呼び出し、必要なテキストを印刷しています。

これは、私が必要としていたことに対しては問題なく機能します。私は自分が何を印刷しているのかを常に知っていたので、80mmのレシート用紙に適切に収まるように文字列を手動でトリミングすることができました。次に、これをより柔軟にする機能を追加する必要がありました。ユーザーは、下部に追加される文字列を渡すことができます。

彼らが何を入れようとしているのかわからなかったので、ラップする文字数と文字列自体を取り込む独自のワードラップ関数を作成しました。文字数を調べるために、私は次のようなことをしていました。

これで、幅は283を返します。これは、mmで約72です。これは、80mmの用紙の余白を考慮すると意味があります。

しかし、MeasureStringメソッドはCourierNew8ptフォントで10.5を返します。したがって、36〜40であると予想していたものを回避する代わりに、26を取得し、2行のテキストが3〜4に変換されます。

PrintableArea.Widthの単位は1/100インチで、グラフィックスオブジェクトのPageUnitはDisplayです（これは通常、プリンターの場合は1/100インチです）。では、なぜ私は26しか戻ってこないのですか？

OnPrintPage イベントを処理する .NET PrintDocument クラスを使用して、C# で印刷ルーティングを作成しています。

余白を最大化し、画像を横向きモードで印刷することに成功しましたが、デフォルトの画像プレビュー プログラムであるWindows フォト ギャラリー (以前の Windows 画像と FAX ビューアー) から同じ画像ファイルを印刷した場合ほど見栄えがよくありません。 Windows Vista で。

「印刷用に画像をシャープにする」を選択するオプションがあることに気付きましたが、それは何をしますか?

最初に Windows フォト ギャラリーから画像のコピーを印刷してから、必要なカスタム オーバーレイを印刷するために、もう一度プリンターにシートを送信することを考えましたが、毎回並べるのは難しいです。必要な精度を持たずにシートインする...だから、画像を含め、C#内ですべての描画コマンドを実行する必要があります。

ビットマップで前処理を実行して、Windows フォト ギャラリーと同じようにきれいに印刷する方法を知っている人はいますか? フォト ギャラリーの印刷出力を、.NET Image クラスで読み取ることができる標準の画像ファイル (bmp、png など) としてインターセプトできる単純な印刷ドライバーはありますか? 私はここですべての創造性に賛成です。

いくつかの論理プリンターが構成されており、同じ物理プリンターを指しています。各論理プリンターは、特定の入出力トレイで構成されます。pdf などのドキュメントを開き、これらのプリンタのいずれかに印刷すると、正しい入出力印刷が行われます。ただし、Windows サービス (win2003) を開発しましたが、PrintDocument クラスを使用して印刷すると、プリンターはターゲットの論理プリンターの構成を無視し、(表示される) デフォルト設定を使用して印刷します (たとえば、任意の入力トレイ => トップ排紙トレイ）。XP マシンで同じサービスを試してみましたが、すべて正常に動作します。

何か案は？

ありがとうショーン

printDocument を 2 番目のフォームに送信して、2 番目のフォームに配置された printPreviewControl に表示したい。

form1コード

form1 で public アクセスを持つ定義された printDocument クラス

form2コード

form1のprintDocumentには印刷するドキュメントがあると確信していますが、form2がロードされたときにprintPreviewControlに何も表示されませんでした。form2 を表示する前に、form1 の printDocument のどのメソッドを呼び出す必要がありますか?

私の問題は、ネイティブ API を使用して、標準コントロールにはない多くの RichEdit 機能を追加する「拡張」RichTextBox コントロールを作成したことです (つまり、他のフォント プロパティを変更せずに、選択範囲の単一のフォント プロパティを変更し、 [ワードパッドのような] プリンターへのワードラップなど)。コントロールの一部として、RichTextBox の書式設定されたコンテンツを印刷するために使用される PrintDocument を公開します。wordwrap が "Wrap To Printer" に設定されている場合、EM_SETTARGETDEVICE メッセージを RichTextBox に SendMessage し、適切な長さに折り返すようにします。

何か (ユーザー/コード) がコントロールの WordWrap プロパティを変更すると、これはすべて正常に機能します。ただし、その後 PrintDocument が変更された場合、それを知る方法はありません。したがって、ユーザーが PrintDocument の余白を変更した可能性がある場合でも、WordWrap プロパティが変更されるまで、RichTextBoxEx は新しい幅の EM_SETTARGETDEVICE を再送信しません。

これを克服するためのいくつかのオプションがありますが、私はそれらのどれも大ファンではありません. ここに私が持っているものがあります:

1. UpdatePrintDocument() メソッドを追加するか、コントロールの外部の何か (つまり、親フォームの PageSetupDialog) が PrintDocument の設定を更新した後に呼び出す必要がある類似のメソッドを追加します。短所: コントロールを配布するので、できるだけ使いやすくしたいと思います。私はいつでもメソッドを呼び出すことを覚えているかもしれませんが、他の誰かがそうしないかもしれない PrintDocument 設定を正常に更新します。長所: 実装は簡単です。

2. PrintDocument を基にして、必要な "Changed" イベントを実装する新しい PrintDocumentEx クラスを作成します。短所: 十分ではない可能性があり、PrintSettingsEx、PageSettingsEx などを作成する必要がある場合があります. 長所: 一度実装すれば、誰もそれについて心配する必要はありません。

＃2は私が使用しなければならないオプションだと本当に思いますが、同様の機能が必要な次のインスタンスではあまり再利用できません. 私が探しているのは、「ジェネリック PropertyChanged イベント」を既存のクラス プロパティにアタッチする方法だと思います。これは、将来の状況で適用できるからです。皆さんが私のために持っているものを見るのが心配です:-)