Windows 8 Metroは、多くの変更を提供し、印刷に関しても例外でない。charmのコンセプトにおいて、印刷のための新しいAPIと拡張可能なユーザーインターフェイスが存在している。このAPIは、XAMLとJavaScriptベースの両方のアプリケーションに提供されている。
プリンターのサポートは、常に重要なWindowsのセールスポイントである。プリンタドライバのサポートは、しばしばWindowsがIBMのOS/2に勝った理由として挙げられる。ユーザーインターフェイスについては、マイクロソフトに無視されており、各アプリケーションは通常、独自のユーザーインターフェイスを作り上げている。
最初の問題は、.NETが提供している標準印刷ダイアログである。これは、基本的なプログラムで動作し、拡張性をほとんど提供しない。開発者は標準じゃないものが必要なときには、スクラッチから構築する必要がある。Metroアプリケーションにおいては、PrintTaskAdvancedOptionsクラスを通じて、アプリケーション固有のプリンタオプションが提供されている。これは、フォームのテキストフィールドとオプションリストを拡張することができ、XAMLとJavaScriptベースのアプリケーションの両方で、きちんと動作するはずである。
他の問題は、印刷プレビューを提供する場合、各プログラムがその責任を持つ必要があるという問題である。Windows 8 Metroは、印刷プレビューウィンドウと印刷ダイアログを組み合わせることで、この問題を解決した。印刷をサポートするが、印刷プレビューは提供しないアプリケーションは、ユーザーには破れたように表示される。
印刷機能のコア機能は、Windows.Graphics.Printing名前空間で提供されている。このAPIは、XAMLとJavaScriptベースのどちらのアプリケーションからも同じように使うことができ、理論的には同じユーザーエクスペリエンスが得られる。JavaScriptベースのアプリケーションでは、開発者は印刷のためのアプリケーションを登録して、メディアクエリを使ったCSSをつかって、画面を再フォーマットするだけである。
XAMLベースのアプリケーションでは、プレビューと印刷されたページのレイアウトのためにXAMLを使って、開発者はもう少し作業を行う必要がある。多くのWPFとSilverlightの印刷と同様に、PrintDocumentのインスタンスから発行されるイベントをリッスンする必要がある。（このバージョンのクラスは、Windows.UI.Xaml.Printing名前空間で見つけることができる。）
- AddPage: ページが印刷に必要であることを示す
- Paginate: ユーザーがドキュメントのページ設定を変更したときに発行される
- GetPreviewPage: ページのプレビューが必要であることを示す
Windows.UI.Xaml名前空間をベースにしているため、印刷ロジックはMetroとデスクトップスタイルのアプリケーションで共有することはできない。