unixuser200403-1

UNIX USER 誌 2004 年 3 月号 のフォント特集の元原稿より

Linux などのいわゆるフリー Unix も、従来のサーバ中心の用途から、パーソナルなデスクトップ用途へとようやく広がってきた。 そんな流れが今後ますます加速していく中で、普通に文書を閲覧し、普通に文書を作成し、普通に文書を出力する、その中心には書体があり、文字がある。 この特集では、フリー Unix における電子書体の扱いについて、技術的基盤からその作成の基礎まで、幅広く紹介する。

執筆

• かずひこ < http://www.fdiary.net/ >
• 村田賢太 *1
• 山下繁行 *2

---- Part 1 フォント関連の基礎知識

• 「字体」と「書体」と「グリフ」と「フォント」

これらの用語はしばしば混同して使われているが、ここで改めてその違いを確認しておきたい。

「字体」というのは文字の構造、骨格のことで、「口」という字は四角い形をしているとか、「日」という字は四角い形の真ん中あたりに横線が引いてあるとか、そういう構造のことを指している。

★「図? 中心の骨格が字体」jitai.eps.gz

文字の骨格たる「字体」に対して、筆法や意匠などに基づく統一的な字形を与えたものが「書体」で、アルファベットだとセリフ体やサンセリフ体、漢字だと明朝体やゴシック体といったスタイルのことを指している。

★「図? 様々な書体。左から順にセリフ体 (Garamond)、サンセリフ体 (Frutiger)、明朝体 (ヒラギノ明朝)、ゴシック体 (ヒラギノ角ゴシック)」shotai.eps.gz

ただし、本来書体とその骨格である字体とは依存しているものであり、書体が変われば字体も変わり得る。よって、これは、現在の電子書体の状況*3 (あるいはその背景となる文字使用状況) を説明するための便宜的なものといえる。

そして、個々の文字の可視化表現がグリフであるが、さらにその具体的な形象をグリフ・イメージと区別して呼ぶこともある。

最後に「フォント」とは、元々は同一書体・同一サイズの活字の一揃いのことだが、電子活字では一つのファイルで複数のサイズや複数のウェイト (太さ) の文字を出力できたりするなどその定義は曖昧になり、ここでは電子活字として実装された書体のことを「フォント」と呼ぶことにする。

なお、これらの用語については TR X 0003:2000『フォント情報処理用語』*4が参考になるので、興味のある方はそちらを見てほしい。

• 書体のファミリー

ファミリーとは、ある一つのデザインから生み出されたさまざまな書体群のことを指す。

• • 太さ (ウェイト)

書体の太さを表す言葉としては、従来の活字書体では書体によってライト、レギュラー、ミディアム、ローマン、ボールド、ブラック、ヘビーなど様々な言葉が用いられていたが、ISO/IEC 9541-1 では以下の 9 段階に分類して、それぞれに対応する英語表記が与えられている。

なお、CSS (Cascading Style Sheets) 2 *5では font-weight プロパティに相当し、直接指定では「100, 200, 300, 400, 500, 600, 700, 800, 900, normal (400 と同じ), bold (700 と同じ)」を用い、間接指定では「bolder (次に太い書体), lighter (次に細い書体), inherit (親要素と同じ)」を用いる。

• • 字幅 (ワイズ)

字幅を表す言葉も書体によって若干のバリエーションがあるのだが、通常の字幅のものはレギュラーまたはノーマル、幅の狭いものはナローまたはコンデンス、幅の広いものはエクスパンドまたはワイドと呼ぶ。

CSS 2 では font-stretch プロパティに相当し、直接指定では狭いものから順に「ultra-condensed, extra-condensed, condensed, semi-condensed, normal, semi-expanded, expanded, extra-expanded, ultra-expanded」を用い、間接指定では「wider (次に広い書体), narrower (次に狭い書体), inherit (親要素と同じ)」を用いる。

• • スタイル

フォントのスタイルには、ローマン、オブリーク、イタリックの三つがある。 ローマンは通常の垂直に立った書体のことで、正体またはアップライトとも呼ぶ。 イタリックとは、その名のとおりイタリアの筆記体を起源とするもので、字形もローマンのものとはやや異なる。 オブリークはローマンの字形を右に傾けた書体で、斜体とも呼ぶ。

★「図? 左から順に、Times Roman、Times Italic、Optima Oblique」italic.eps.gz

ただし書体によっては、本来オブリークと呼ぶべきものをイタリックと呼んでいる場合もある。

CSS 2 では font-style プロパティに相当し、それぞれ「normal, italic, oblique」を用いる。

フォントファイルは、そのままではあくまでもただの電子データであり、それを何らかの形で可視化することによって、はじめて文字として見えるものになる。 そこで、ここではフォントファイルにどのように文字データを記述するかというフォーマットについてと、それをどのように紙やモニタ上に再現するかというレンダリングについて解説する。

フォントをどのように記述するか

フォントは、各文字をどのように記述するかで、まず点で記述するビットマップフォントと線で記述するベクトルフォントの二つに分けられる。 ベクトルフォントは、さらに文字の骨格を線で記述するストロークフォントと、文字の輪郭を線で記述するアウトラインフォントの二つに分けられる。 ストロークフォントとは文字の骨格を線で表したフォントで、その性格上 CAD のプロッタ出力などで多く用いられるものなので、本稿では詳細は割愛する。

            ┌──ビットマップフォント
フォント──┤                        ┌──ストロークフォント
            └──ベクトルフォント──┤
                                      └──アウトラインフォント

★「図? フォントの分類」

• ビットマップフォント

ビットマップフォントとは、ビットマップ、すなわち点の集合によるフォントである。特定の解像度の特定のサイズで用いるためのものであり、拡大しても文字を構成する点が大きくなるだけで、ガタガタの文字になる。 そう書くと、いかにも使い勝手の悪いだけのフォントのように聞こえるかもしれないが、入念に作られたビットマップフォントは、その意図された解像度・サイズで使用されれば、後述するアウトラインフォントよりも遥かに見やすいものになる。

• • BDF と PCF

X11 環境ではビットマップフォントは BDF (Bitmap Description / Display Format) 形式もしくは、それをバイナリ形式に変換した PCF (Portable Compiled Font) 形式を使うことができる。

BDF 形式の中身は、フォント情報を記したヘッダ部と、各グリフのデータからなる。

STARTFONT 2.1
COMMENT
COMMENT Shinonome 16dot font for JISX 0208, 1983/1990
COMMENT
COMMENT The original is designed by
COMMENT   Yasuyuki Furukawa <Furukawa.Yasuyuki@fujixerox.co.jp>, 2000.
COMMENT   (Public Domain)
COMMENT
COMMENT > NOTE: Some characters of XFree86 "jiskanji16" are included as
COMMENT >       symbols' design pattern.
COMMENT
COMMENT Modified and Maintained by /efont/.
COMMENT
COMMENT (c) /efont/ -- Efont Open Laboratory 2001
COMMENT http://openlab.ring.gr.jp/efont/
COMMENT
FONT -Shinonome-Gothic-Medium-R-Normal--16-150-75-75-C-160-JISX0208.1990-0
SIZE 16 75 75
FONTBOUNDINGBOX 16 16 0 -2
STARTPROPERTIES 20 ← 以下 20 行、属性情報が入る
FONT_ASCENT 14
FONT_DESCENT 2
DEFAULT_CHAR 8481
COPYRIGHT "Public Domain"
FONTNAME_REGISTRY ""
FOUNDRY "Shinonome"
FAMILY_NAME "Gothic"
WEIGHT_NAME "Medium"
SLANT "R"
SETWIDTH_NAME "Normal"
ADD_STYLE_NAME ""
PIXEL_SIZE 16
POINT_SIZE 150
RESOLUTION_X 75
RESOLUTION_Y 75
SPACING "C"
AVERAGE_WIDTH 160
CHARSET_REGISTRY "JISX0208.1983"
CHARSET_ENCODING "0"
_XMBDFED_INFO "Edited with xmbdfed 4.4."
ENDPROPERTIES
CHARS 6879 ← 以下 6879 個のグリフが入る
STARTCHAR 2121
ENCODING 8481
SWIDTH 960 0
DWIDTH 16 0
BBX 16 16 0 -2
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
ENDCHAR
(以下略)

★「BDF フォントの例 (東雲ゴシック 16 ドット)

なお通常は、ディスク容量の節約とロード時間の短縮のために、PCF 形式、もしくは PCF 形式を gzip で圧縮したものを用いる。

• アウトラインフォント

アウトラインフォントの主な形式には、Type 1 形式 と TrueType? 形式があり、最近ではそれらをまとめた OpenType? 形式が普及しつつある。

Type 1 フォント

Type 1 フォントとは、Adobe 社が開発したフォント形式で、俗に PostScript? フォントとも言われている。 曲線の記述には、PostScript と同じく 3 次ベジエ曲線*6が用いられている。 ファイル構成は、グリフのアウトラインデータなどを納めた PFA (アスキー) または PFB (バイナリ) 形式のフォントファイルと、各グリフの横幅や文字間のカーニング*7などのメトリクス情報を納めた AFM 形式のファイルからなる。

StartFontMetrics 2.0
Comment Generated by pfaedit
Comment Creation Date: Tue Dec 31 16:51:01 2002
FontName NimbusSanL-Regu
FullName Nimbus Sans L Regular
FamilyName Nimbus Sans L
Weight Regular
Notice (Copyright (URW)++,Copyright 1999 by (URW)++ Design & Development; Cyrillic glyphs added by Valek Filippov (C) 2001-2002)
ItalicAngle 0
IsFixedPitch false
UnderlinePosition -151
UnderlineThickness 50
Version 1.06
EncodingScheme AdobeStandardEncoding
FontBBox -174 -285 1028 953
CapHeight 729
XHeight 524
Ascender 729
Descender -218
StartCharMetrics 560
C 0 ; WX 278 ; N .notdef ; B 0 0 0 0 ; ← 左から順に、文字コード (256 以上は -1)、文字幅、名称、グリフが占めるエリアの座標 (左・下・右・上)
C 32 ; WX 278 ; N space ; B 0 0 0 0 ;
C 33 ; WX 278 ; N exclam ; B 124 0 208 729 ;
C 34 ; WX 355 ; N quotedbl ; B 52 464 305 709 ;
(中略)
EndCharMetrics
StartKernData
StartKernPairs 974
KPX quoteright y -6 ← 右引用符と y の間は 6 つめる
KPX quoteright w 2 ← 右引用符と w の間は 2 あける
KPX quoteright v -2
KPX quoteright t -7
(中略)
EndKernPairs
EndKernData
EndFontMetrics

★「AFM ファイルの例 (Nimbus Sans L フォント)

Type 1 フォントは 1 バイト、すなわち 256 文字までしか扱えない形式なので、日本語フォントなどでは複数の Type 1 フォントを一まとめにして一つのコンポジットフォントとして扱う必要がある。 コンポジットフォントとして現在主に使われているのが CID フォント (Character IDentifier Keyed Font) で、コンポジットフォントのコードに、CID フォント独自のコードを割り当てることで、JIS X 0208-1983 や JIS X 0208-1990 といった複数の文字セットへの対応ができるようになっている。 ファイル構成は、グリフのアウトラインデータなどを納めた CID フォントファイルと、メトリクス情報を持つ AFM ファイルと、さらに文字配列を CID 番号で管理する CMap (Character Mapping) ファイルからなる。

TrueType? フォント

TrueType? フォントは、前述の Type 1 フォントに対抗して Apple 社と Microsoft 社が開発したフォント形式で、Microsoft Windows や MacOS が標準で対応したことで一気に普及した。曲線の記述には 2 次ベジエ曲線*8が用いられている。 TrueType? フォントは、Type 1 フォントと異なり、グリフデータとメトリクス情報を同じ一つのファイルに持つ。

OpenType? フォント

OpenType? フォントは、Type 1 フォントも扱えるようにした TrueType? フォントのスーパーセットで、CID 形式のフォントも扱うことができる。 ユーザから見れば Type 1 か TrueType? かという内部の記述形式を気にせずに一つのフォーマットで使える。

なお、各種フォントフォーマットの規格については、PfaEdit の参考文献*9に詳細なリンクリストがあるので、より深く知りたい方はそちらを参照してほしい。

フォントをどのように再現するか

アウトラインフォントは文字の形状を 3 次ベジエ曲線などのベクトルデータで保持している。 一方、ディスプレイやプリンタはドットマトリクスであるから、ビットマップフォントの場合は各ドットを対応させることで表示できるが、アウトラインフォントの場合は字形の曲線をビットマップに変換しなければならない。

ベクトルデータにより与えられた形状は直線や曲線を忠実に表しているため、アナログ画像であると考えられる。 これに対してビットマップとして与えられた形状はディジタル画像である。アナログデータからディジタルデータを得る場合、アナログデータに対してサンプリング（標本化）と量子化という処理を行う。この最も身近な例は音声の録音であろう。 PC で音声を録音する場合、マイクから与えられたアナログの波形データを 44.1kHz や 48kHz などのサンプリング周波数で標本点を取り出し、そして得られた各標本点の値を A/D 変換器で量子化し、アナログデータに対応するディジタルデータを生成する。

ベクトルデータによる形状をビットマップに変換する場合も、音声のようなサンプリングおよび量子化を行わなければならない。この時、標本点に相当するのが画素であり、各画素の色を決定するのが量子化に相当する。 これは、スキャンライン法と呼ばれるアルゴリズムにより実現できる。

スキャンライン法による形状の描画

スキャンライン法は、描画対象である形状をピクセルの並びに沿って図? に示 すようにスキャンする描画方法である。形状にヒットしたピクセルにのみ色が 塗られることで、ベクトルデータによる形状がビットマップ画像にサンプリン グされる。

★「図? スキャンライン法の模式図」scanline.eps.gz

アンチエイリアス

ベクトルで与えられた形状をサンプリングすることでビットマップ画像へ変換することができた。しかし、ビットマップの解像度によってはピクセルが目立ってしまいきれいな線が描けない。この現象をエイリアスという。

エイリアス現象は、実際にはほとんど線が乗っていないピクセルであっても、形式的な判定によって色が塗られてしまう事が原因で発生する。しかし、判定条件を細かく設定することで色が塗られなくなったとしても、線の傾きによっては非常にピクセルが目立ってしまう場合がある。

そこで、線の境界に中間色を用いる事で、見た目にピクセルを目立たないようにする方法が考え出された。この方法をアンチエイリアスと呼ぶ。

アンチエイリアスの手法の一つにオーバーサンプリングがある。 オーバーサンプリングは、まず一つのピクセルを複数の小さなサブピクセルの集合体と仮定し、実際の解像度よりも細かくサンプリングする。そして、ピクセルに色を塗る際に、サブピクセルの色の平均値をとることで中間色を得る。

例えば、ピクセルを 2x2 のサブピクセル群で分割した場合、

subpixel.eps.gz

サブピクセルのパターンはこれだけ存在し、1ピクセルは5階調で表わされる。

ClearType?, CoolType?, サブピクセルレンダリング

Microsoft Windows における ClearType、Adobe Acrobat における CoolType、 そして freetype2 におけるサブピクセルレンダリングという技術は、どれも 同じ技術の別名である。

これらの技術は、アンチエイリアスの特殊な場合であると考えることができる。 液晶パネルは CRT と異なり、各ドットが明確に区別され、さらにRGB の各成分も 明確に区別される。そのため、液晶パネルではサブピクセルの配置の仕方で縦 方向もしくは横方向が通常の解像度の3倍となる。

液晶パネルでは、サブピクセルの配置の仕方に特化したアンチエイリアスを行 う事で、通常のアンチエイリアスよりも見た目に滑らかなレンダリングが実現 できるのである。

★「図? 左から順にスキャンライン、アンチエイリアス、サブピクセルレンダリング」 circle-normal.eps.gz circle-antialias.eps.gz circle-subpixel.eps.gz

※ [編集者への注] wiki で見える PNG 画像はあくまで模式図ですが、EPS 画像はちゃんとした図になっていますので、そちらを使ってください。また、ドット数が多すぎて図が見にくいということでしたら、その旨お知らせください。任意のドット数で EPS を生成できるようなプログラムを作っていますので。

ヒンティング

アウトラインフォントのレンダリングにおけるもう一つの品質向上の手法が、ヒンティングである。 これはその名のとおりレンダリングする際の「ヒント」であり、例えば「こことここの直線の幅は同じにする」などの情報である。 ヒンティングを用いることで、文字が真っ黒につぶれたり線がアンバランスになったりせずにレンダリングすることができる。

★「図? 左：ヒンティングなし、右：ヒンティングあり」

なお、ヒンティング情報は本来フォントの作成者がフォントに持たせるものだが、TrueType フォントが持つヒンティング情報の処理まわりには Apple 社の特許が存在しており、そのため正当なライセンス無しにその情報を使うことができない。 そこで、FreeType ライブラリのバージョン 2 では、元のアウトラインデータから自動的にヒンティング情報をつくり出してそれに基づいてレンダリングするという方法でこの問題を回避している*10。

Part 1 では、書体全般に関する基礎知識と、電子書体の記述と再現について紹介した。 繰り返しになるが、文字は可視化されて初めて文字たりえるので、書体のデザインそのものだけでなくその再現もまた重要であり、再現の技術も日々進化している。

続く Part 2 では、具体的に X Window System が電子書体をどのように扱い、どのように再現するのかについて、紹介したい。

有限の文字の集合に対する文字と数値*11の対応規則を CCS (Coded Character Set; 符号化文字集合) と呼び、ここで文字に対応する数値のことを code-point（符号位置）と呼ぶ。 また、一つ以上の符号化文字集合の符号位置をあるバイト列*12で表現するルールを CES (Character Encoding Scheme) と呼ぶ。 ともに RFC 2130 で規定されている。また、前者は ISO/IEC 2022 や ISO/IEC 10646, JIS X 0208 などの公的標準における定義に由来する。

例えば JIS X 0208 というのは第一水準、第二水準の漢字と仮名や記号などの非漢字が含まれる CCS で、それに対する CES として ISO-2022-JP、EUC-JP、シフト JIS などが存在する。*13*14

「シフト JIS」は単に CES であるが、各ベンダーが元の CCS に独自の拡張を施した結果、多種多様な「シフト JIS」と呼ばれるものが存在することになり、さまざまな混乱が生まれることになった。

'〜' の憂鬱

そもそもこの '〜' は何という字なのか？ これは JIS X 0208/0213 の世界では「波ダッシュ (WAVE DASH)」で、1面1区33点にありシフトJISで表現すれば 0x8160 の文字にあたる。 そして Unicode にも同じく 'WAVE DASH' と名付けられた字 U+301C があり、本来そこにマッピングされる文字である。

ところが、Windows の CP932 という CodePage? ではこの文字が 'FULLWIDTH TILDE' と名付けられた字 U+FF5E にマッピングされてしまうため、Windows 環境とそれ以外の環境での文書のやりとりの際などに、正しく表示されないことがある。 このように CP932 のマッピングがシフトJIS のマッピングと異なる文字は以下のとおり。

特に「〜」「‖」「−」の三つは、幅だけでなく文字そのものが異なるので注意が必要である。

円記号の憂鬱

プログラムコードなどを書いていてある文字をエスケープしなくてはならない時、Cでは ＼ (REVERSE SOLIDUS いわゆるバックスラッシュ)を用いることは読者は良くご存じだと思うが、これは表示に使用する文字符号化方式(エンコーディング)により、あるいは使用するフォントにより、はたまた表示するソフトウェアの実装により、 ＼ (REVERSE SOLIDUS) ではなく ￥ (YEN SIGN いわゆる半角の円記号) のグリフに変わる事になる。

その原因の一つに文字符号化方式により使用する文字セットが違う為に起こることが挙げられる。例えばコードポイント0x20-0x7fの範囲をISO-8859-1では ASCIIの定義のまま用いているが、Shift_JISではJIS X 0201を用い、ISO 646にて置換えが可能とされているコードポイントのうち0x5Cを ASCIIの＼ (REVERSE SOLIDUS) ではなく￥ (YEN SIGN)へ、 0x7Eを ~(TILDE)ではなく￣ (OVERLINE)のグリフに置き換えている。この為、Shift_JISでは

printf("hello ＼"world＼"");

が

printf("hello ￥"world￥"");

と表示される事となる。グリフは違っていてもコードポイントは同じである為ソースコードそのものの意味は変わらないが、気持ち悪いのは事実である。

もう一つの原因として、いわゆる和文フォントとして流通しているTrueTypeFontを使用している事が挙げられる。和文フォントでは、 コードポイント U+005C (※TrueTypeFontではエンコーディングにUnicodeを採用している事が多い為あえてこう表記した) REVERSE SOLIDUS にあたるグリフにJIS X 0201に定義されているグリフを採用している事が殆んどである為である。*15

★「図? DynaFont? の平成角ゴシックW3」

しかし和文フォントであっても、U+005Cに ＼ (REVERSE SOLIDUS) のグリフを用いていることがある。東風フォント代用品(kochi-gothic-subst.ttf)などはその例である。

★「図? 代替東風ゴシック」

フォント側がどういうグリフを採用しているかというこの件について、筆者はこういうエピソードがある。各ソフトウェアがfontconfigとXft2に対応してきてAntiAliasの効いた綺麗な表示が増え始めた頃、英大文字のI(アイ)と英小文字のl(エル)や数字の0と英大文字のO(オゥ)の区別が付き易く且つ高品位なフォントを探していた。そこで出会ったのがアニト等幅 http://www.linkclub.or.jp/~typelabo/ というフォントだったのだが、このフォントも多くの和文フォントと同じく U+005CのグリフがYEN SIGNのグリフだった。

ライセンス上、自分勝手に改変することは許可されていなかったので(商用フォントの殆んどはそうであろう)、変更したものをリリースして戴けないかと一縷の望みを託し、作者である佐藤豊氏にメールを送ったことがある。

その時のお返事は

プログラミングでバックスラッシュを使用するのは、知識として知ってはいました。 しかし、日本語フォントに含まれるASCII文字部分としては、円マークにしておかないと、困る人も出てくるわけです。

これまで使用されている日本語フォントの殆どが、その部分を円マークにしていますから。ということで、アニト等幅も円マークにしました…。」

という事だった。まぁこれはしかたがない事かなと思いメールを読み進めると

・前述の理由から、アニト等幅フォントの改変をする予定はありませんが、、、、購入者の方が、購入者自身が改変し、購入者自身が使用する場合のみ、不都合と感じる部分の改変を許容します（この情報は公開して構いません）。

・ただし、改変したフォントを人に譲ったり配布することは、許可しませんので…。バックスラシュキャラクタは、＼u005cに入れてあります。」

とのこと。これを読んで跳び上がるほど喜んだ事は言うまでもない。早速、U+005Cのグリフを REVERSE SOLIDUS に入れ替えて、今現在これがなくては生活できないというくらい愛用している。(例えばWindowManagerのfluxboxやKDEのUIや、xchatのテキストボックスやmozillaのmonospaceフォント等々……あらゆる場所で大活躍である。購入者の改変を快く許可してくださった佐藤氏には本当に感謝している。この原稿を書いている1月11日現在、タイプラボのサイトのQ&Aに購入者の改造を許容する旨を明記してくださっている。

★「図? 改変後の Anito L 等幅」

また、更にソフトウェアの実装に関する問題も挙げられる。文字符号化方式により0x20-0x7fの範囲の一部でグリフの置き換えが行われていることは上に述べたが、表示するソフトウェアがそれに忠実に実装されていれば、ASCIIのグリフを採用しているUTF-8の文書では 0x005Cが ＼ (REVERSE SOLIDUS)で表示されることが期待される。

しかし、mozillaを例に挙げると、本来 U+005C にあるグリフではなく、U+FF5Eにあるグリフで表示している。図は 0x5C ＼ (REVERSE SOLIDUS)をそのままの文字とその数値文字参照 &#92; で記述し表示した例である。おそらくmozillaは「日本語の文書の場合0x5C は YEN SIGN」という独自の解釈で実装されているのではないかと思われる。

★「図? LANG属性がenのISO-8859-1文書をmozillaで表示」

★「図? LANG属性がjaのUTF-8文書をmozillaで表示」

一方、KDEのkonquerorで表示した場合、UTF-8とISO-8859-1の文書ではREVERSE SOLIDUSとして表示し、Shift_JISの文書ではそのままの文字で記述した方はYEN SIGNとして、数値文字参照 &#92;をREVERSE SOLIDUSとして正しく表示している。

★「図? LANG属性がenのISO-8859-1文書をkonquerorで表示」

★「図? LANG属性がjaのUTF-8文書をkonquerorで表示」

★「図? LANG属性がjaのShift_JIS文書をkonquerorで表示」

この様に、文字の世界は複雑怪奇・奇々怪々なのである……。

※ [編集者への注] この節にある＼は実際はいわゆる半角 BACK SLASH で、また￥は、実際はいわゆる半角YEN SIGNで印刷ということでおねがいします。