原因として、.Net Frameworkではグラフィック処理の仕様が変更され、デバイスフォントが使用できなくなったことが原因です。
弊社で調査した結果、理由としまして以下のようなことが推測されます。
（Windows内部の処理のことなので、理解が異なっている部分があるかもしれません。）
Windows OSは開発当初（Windows2.xx)より、画面表示や印刷などのビットマップ展開処理には、Win32APIのGDI(Graphic
Device Interface)機能を使用してきました。
Windowsが登場した当初は、ハードウェアは進化の過程にあり、表示や印刷などのデバイスは、いろいろなサイズの表示エリアや色数などを持っており、新しく登場してくる装置にも対応
ができるように、各装置ごとにデバイスドライバというインターフェースソフトウェアを備えています。
表示や印刷などのデバイスへ出力を行う場合、出力先（デバイスハンドル）をGDIに指示することで、GDIは必要に応じてデバイスドライバの展開ルーチンを呼び出し、各デバイスに適したレンダリング
処理（ビットマップイメージへの展開処理）を行います。
しかし、各デバイスドライバにレンダリング処理をゆだねることにより、装置により（デバイスドライバにより）出力結果が微妙に異なるなど、互換性や管理の問題を抱えることとなりました。
XP以降のOSで標準採用となった、.Netframeworkをベースとした技術を用いた印刷では、GDI+機能を呼び出して、表示や印刷などのレンダリング
処理を行います。
GDI+ではGraphicsクラスというオブジェクトとして扱うため、GDIとは考え方が異なります。
＋（プラス）とは呼ばれていますが、基本的な考え方から異な
った設計の為、両者の使用方法をそのまま置き換えることなどはできません。
GDI+ではフォントのビットマップ展開をGDI+自身で行い、展開処理されたイメージデータをデバイスへ送り出す方法をとっているようです。
GDI+で使用できるフォントは、OSが管理しているTrueType フォントと OpenType
フォントに限定され、それ以外のフォントは、すべてMicrosoft Sans Serifに置き換えられます。
その為、GDI+では、プリンタフォント、プリンタ内蔵バーコード、プリンタコントロールフォント（レシートカットなど、プリンタ独自機能の実行
するためのフォント）はMicrosoft Sans
Serifに展開されてしまい、プリンタドライバには渡されないため、機能することはできません。
.Netframeworkは、Win32APIの代替ファンクションは多く準備されていますが、上記問題に対応した代替ファンクションはありません。
.Netframeworkで動作するプログラムから、Win32APIを呼び出すこと
によりGDI機能を使用することはできますが、たとえばGDI+の印刷ルーチン内で、GDIを用いたフォント展開を行うなど、考え方が異なるものを単純に組み合わせての使用はできません。
Visual Studio.Net, Visual
Studio2005などの開発環境での印刷は、GDIを用いた印刷はサポートされませんので、GDIを使用するのであれば、Win32API関数を用いて、すべて自前で
印刷ルーチンなどを作成する必要があります。（出来なくはないと思いますが...）
この現象はMicrosoft OfficeのWORDでも再現し、同様の理由と考えられます。
最近のWORD文章上では指定どおりにバーコードフォントを指定してもバーコードは印刷されません。
しかし、Windows付属のワードパッドで同様のことを行い、印刷をおこなうとバーコードは印刷できます。
ワードパッドは設計されたのが古いために、COMで作成されGDI+が使用されていないためと思われます。
.NetFrameworkなどに関係なく、いずれのWindowsでもGDI自体はサポートされていますので、GDI経由での出力を組み込むことは可能ではあると思います。
ただし、GDIを使用する場合、全てを自分でサポートする必要があるため、かなりGDIに精通している必要があります。
それ以外での対応案としましては、以下の方法もご検討ください。
●印刷書式として、フォント種類やサイズを組み合わせて印字する必要があるか?
あくまでWindowsとして印字したい場合、開発環境としてVB6への変更を行う。
→MSではVB6をVista対応としたため、最近MSDNでのVB6（VisualStudioでなくVB6単体）の配付を再開しています。
●ビットマップフォントでの印字で可能であるのであれば。
シリアルポートへESC/POSコマンドを出力し、プリンタを直接制御する。
→VisualStudio2005では、SerialPortクラスやコントロールが準備されています。
→プリンタがUSB I/Fの場合、TMCOMUSB Serial Emulation Driverを用いる事で対応できる。
OPOS ADKを用いる。
→ただし、このドライバもOCXなので、.Netframework環境下ではあまりお勧めではありません。
●プリンタフォントやコントロールフォントは必要なく、バーコードだけで使えればよい。
市販のBarCode生成コントロール利用する。
VB-Barcodeなどを用いる。
ツルータイプバーコードフォントを用いる。
ツルータイプフォントは高解像度プリンタでは問題ありませんが、ラベルプリンタは解像度が低いために
ドット変換の際の画像乱れが発生するために、プログラムでの扱いには注意を要します。
（ラベルプリンタ印字の場合、弊社では推奨しません。）
●ドロワオープンのコントロールフォントが使用できない。
最新のAdvanced Windows Printer
Driverでは、ページ送りにドロワ制御をリンクしており、コントロールフォントを使用しなくともドロワオープンができます。
その他、印刷機能のみWin32APIを用いたモジュールとし、DLLやコントロールとして結合するなども考えられます。
印刷プログラムについては、過去から何度かその方法が変更されてきた経緯があります。
機器制御が必要なプリンタで、OSなどの要因により影響を少なくしたい場合、プリンタコマンド（ESC/POS）による直接制御などが有効と思います。
（本来であれば、機器制御をアプリから切り離すことが共通化のはずなのですが.... まあ、この辺はMSさんの方針次第なので...）
テクノベインズ株式会社
〒113-0034 東京都文京区湯島3丁目31-4 ツナシマ第1ビル 電話：03-3832-7460 (平日:09:00-17:30)
FAX：03-3832-7430