リソースフォークを抽出してMacintoshのTrueTypeフォントをWindowsで使えるようにする。日本語フォントはたいてい変換不可能。
CJKのビットマップ入りTrueTypeフォントにも対応している。シェアウェア。PPCアプリなので68K Macのエミュレータでは動作しない。
ビットマップも変換できる?
コンバータ。製品。
makettc/breakttcで.ttc←→.ttfの分解・結合ができる。
TrueKeysを使ってMacのフォントをLinux用に変換する手続きの説明。
gaspテーブルをいじって全サイズでスムージングを有効にする
Windows用→Mac用の変換を行う。
MACFNTEXと同じ。
TTModify 1.1に変換手順の説明あり。
TTFにBDFを埋め込む/TTFからBDFを抽出
MacのTTFそのままでは抽出できない。
一つのbdfを違う大きさで使いまわせるはずだが、★EBLCテーブル内でのリンクではなくEBSCテーブルを使うので(ビットマップフォントが無理やりスケーリングされて)使い物にならない。
ビットマップからttfを作成するツール。
ttf→bdfの変換ツール。
gaspがもともと存在しなくてもテーブルを付け加えてスムージング有効にする。
モナーフォントに付属。BDF→TTFの変換などが行える。Perlスクリプト。
.ttfからビットマップフォント(.fon含む)への変換ツール
BDFを埋め込むsbitRW、フォントの名前を変えるttfname、BDFを抜き出すsbitExtract。
(Windowsの)7, 7.5, 9, 10.5, 13.5, 18pt。
Mac(72dpi)だと9, 10, 12, 14, 18, 24ptに相当。
ビットマップの存在しないサイズだとひどく汚くなる。
★MS明朝では7〜22px(5〜16.5pt)にビットマップがあるが、奇数pxは偶数pxと同じビットマップで、文字間だけを調整したものである。22pxも20pxと同じビットマップを使っている模様。MSゴシックも(調べてないけど)おそらく同様。
(Windowsの)7, 7.5, 9, 10.5, 13.5, 18pt
タイプが'FFIL'クリエータが'movr'
一括コピーを使ってるのでビットマップが消える。TTEditを使わなければいい
(Windowsの)7, 7.5, 9, 10.5, 13.5pt、等幅は 7, 9, 10.5pt。
Macの24, 36ptでは内部で拡大している模様。
ビットマップのない13ptが、dpiの違いからWinでは非常によく使うサイズ(10pt)になるが。
MSゴなどでは1ピクセルゲタをはかせたりしている。sbit32でできるはず? (★実際はできない)
大雑把に分けて〜7.6.1/8〜8.5/8.6〜の3種類。8.6以降は文字間隔が8.5以前と異なる。8.5からFinder表示用にNarrowとBoldが追加。
欧文フォントのようにボールドに別書体を持っていればWin9xでもスムージングが効く。。
ビットマップのゴミの判別方法 Win9xではmetricsを無視してはみ出した分もビットマップが存在する限り表示するので、ゴミが出る。
C G J S (Uも?)が他のアルファベットより大きいため上下が欠ける or バランスがおかしい(★TTEditで作ったNBAAのヒントがおかしいためだと思われ)。
Osakaフォントが含まれる(ダウンロードは無料だがMacがないと.smiから中身を取り出せない)
285ttcをベースにビットマップを別のサイズへ詰めなおしたのが864ttc。
10.5ptのビットマップを12ptへ詰めなおしたのが864ttc2(これは賛否両論)。
864ttc3はたぶん変更しても意味なし。
他に665、Narrow/Bold、OsakaFixなど。
Osaka.zip (285製)
osaka864ttc
Osaka-first/Osaka-WinMX/MCOsaka/Osaka.KT755Ver-OutlineOnly/osakamono_bitmap/Osaka.zip(285)/osaka.unicode
665ttc2/864ttc2/864TTC2_NBAA2/864TTC3a/osaka864ttc/osaka864ttc3/So_0016
22/osaka864ttc3/osaka864ttc/osaka-aa21/864TTC3a/864TTC2_NBAA2/864TTC2_NBAA/864ttc2/665ttc2
665ttc2/864ttc2/864TTC2_NBAA2/864TTC3a/osaka864ttc/osaka864ttc3/So_0016
一番最初に上げられたもの。TrueKeysで変換(手順)。どちらもフェイス名が「Osaka」なので等幅と同時にインストールしてもどちらか片方しか使えない。
「ー」が「・」になる
Osakaのフォント名が「佳慫」になる
Osaka-firstのフォント名を修正して「〜」をMSゴ、MSPゴから移植して7ptからスムージング有効にしたもの。
作り方 TTEditで一括コピーしてフォント名変更・「〜」を追加。TTFMODWでgaspを変えてmakettcで結合。
TTEditでコピーした段階でビットマップが消えるので意味なし。
文字化けはないしエディタで等幅として指定できるがビットマップフォント無しという致命的な欠陥が…。
MacFontExtractで.ttfに変換してTTEditで一括コピー
Osaka-firstとほぼ同じだがフォント名の文字化けが修正されている。
フェイス名が同じなので等幅と併用できないのは同じ。
「〜」を埋め込む。
ビットマップ付き。
フォント名の文字化けなし。
等幅12pxのビットマップをBDF化したもの。
9ptより小さくすると何も表示されない(大きいほうには拡大される)。
文字化けはとくになし。Windowsの機種依存文字も(Osakaにあるものは)使える。
UnicodeフォントではないのでNT系(4.0/2000/XP)では使えない。
OsakaからBDFを抽出した方法は不明。
作成方法は不明(バイナリエディタでゴニョゴニョ?)。
等幅のフォント名を変えているので併用できるが、Osaka−等幅の「−」が全角
7, 9, 10, 13ポイント台(等幅は7, 9, 10ポイント台)はスムージング無効
10ptはビットマップがないのにスムージングを掛けていない
Win9xで等幅の小文字の「L」にゴミが付く。
機種依存文字はMacそのまま。ハートマークや(月)が記号に入っている。
gaspテーブル修正。10ptでスムージングが掛かるようになった。
等幅のフォント名を「Osaka-等幅」に変更。
Win9xのFont Viewerで開けなくなった。
詳細な手順は不明だがMac OS 9のOsakaではビットマップはsbitなのでビットマップ抽出のために特別なことはしていない。sbit32で抽出?
Win9xのFont Viewerで死ぬのは未修正。
等幅9ptで小文字Lのゴミは未修正。2000ではならない。
Win9xのFont Viewerで死ぬ問題を修正。
半角スペースの幅は未修正だが9xでは問題ないらしい。
JIS X 0208にない漢字の文字送りが半角。
小文字Lのほか0(ゼロ)にもゴミが付く(Win9x)。
半角の￥記号がバックスラッシュになる。エンコーディングの違いによる仕様? MacJapanese→Windows Unicodeの変換なのだからそこまで配慮すべき?
行間が広い(仕様?)
行間が広いものと狭めたものの2バージョン。
10ptはビットマップがない。もともとMacにもないのだが。
半角スペースの幅は未修正。全角並みになるという報告と広すぎたり狭すぎたりという報告あり。
0と小文字Lの問題は未修正。スムージング有効でアウトラインを使う場合?(ワードパッドなど)当然ゴミは出ない。
等幅の半角スペース問題を修正
9ptのとき、等幅に比べてOsakaのベースラインが1ドット上にずれる。でも否定報告もあり。全角文字が常に等幅なのはMac OS(9以前)の仕様。
行間が狭いものは「'['，']'，'('，')'，'{'，'}'」などが7.5ptで欠ける。オリジナルは問題なし
osakamono_bitmapはttfに変換しているがこれはBDF版。
行間が狭いものの名称をOsaka-UIに変更(主にメニューで使うため。オリジナルのOsakaだと行間が広すぎてメニューが上下に間延びする)。
等幅のフォント名を再び「Osaka−等幅」に修正。
行間はこれ以上詰められない模様(「g」や「j」、「[」とか「}」の関係)。そこでg、j、yだけ1ドット削って高さ12pxにする案が。
等幅は7, 9, 10.5ptしかビットマップがないので他のサイズはスムージング有効。Osakaは7, 7.5, 9, 10.5, 13.5, 18ptにビットマップあり。
1/2記号が「・」に化ける。1/2記号はLtin-1フォントからのものでOsakaにはない?
JIS外字の文字幅は未修正。文字幅が半角扱いになる文字(確認に使用)
円記号問題はそのまま。MacJapaneseでは005Cは円記号で0080がバックスラッシュらしいのでやはり不具合と思われ
Win9xで0と小文字Lの問題は未修正。
Win98ではボールドでスムージングが効かないがOsakaとは無関係。
Osaka-UIはベースラインが1ドット高い?。
285フォントの最終版と思われ
Osaka-UIの行間を詰めた。7/7.5ptでg,j,p,q,y,{,}の下が欠けるのは無視。9ptのg,j,yについては修正。そのためttcにしたときビットマップがOsakaと共有されなくなってサイズ増加。
ビットマップがないサイズの問題は未修正。ＭＳ Ｐゴシック は9ptと10ptを共有。10ptと10.5ptで共有するという案も。
Osaka-UI 9ptでgの下にゴミが表示される。書き換えミスらしい
Win9xでOsaka-等幅のlと0にゴミが付く問題は未解決。iの下にヒゲが付くのはオリジナルどおり
一部の文字の幅がおかしい。円記号がバックスラッシュになる。
Osaka-UIで10ptにすると下が欠ける
cmapをUnicodeにマップしなおしたもの。285版はUnicodeのcmapを持っているはずだからosakamono_bitmapが元?
BDF抽出による等幅フォント。
手順。sbit32では抽出できないのでsbitgetを使う。sbit32 -lでビットマップの共用ができるはずだがうまくいかない。sbit32 -iでビットマップが共有かどうか確認できる。
Win9xで「0」と「l」にゴミが付く理由 本来表示されない部分のビットマップにゴミがあって、Win9xでは表示されてしまう
対処として1ドットずらして埋めなおした。というわけで10pt、11ptにもビットマップが存在
Osaka-UIはOskaの上2ドット、下1ドットを削って、下1ドットを削った際切れる g j y を9ptのみ修正。
同じビットマップをコピーして埋めなおしているのでサイズ大きくなる。
Osakaの15px用bdfを12ptとして埋め込んだもの。
動作確認 ビットマップの有無はsbit32 -iで、スムージングの確認と変更はttfmodw 0.07でできる。
やはり12ptに10.5pt用のビットマップでは小さいらしく賛否両論。
ttfmodの機能で文字幅を変えようとしたが、失敗したため864TTC2と変わりなし
Osaka-等幅の14pxビットマップからfon形式のビットマップフォントを作成。
8pt、9pt、10pt、11ptの等幅複合フォント。fon形式
AA崩れの少ないOsaka。TTEditで作成したらしい(TTEditの仕様のため一部Unicode文字が消えている)。
10pxと11px、12pxと13px、14pxと15pxは、それぞれ前者のビットマップで後者のそれを代替。
sbit32 -lでビットマップを代替させると線の太さがガタガタになる。これでsubstituteは成功している状態。ビットマップを無理やりサイズ調整しているのだから当然汚くなる。
案の定というかOsakaでやってもあまり意味がないという反応。
%のゴミ(本当はゴミではない)を掃除。等幅のlのゴミを掃除。左側が切れていた©の修正。
Win9xで等幅の0に付くゴミは修正されていない。
864ttcシリーズと同様sbitgetでビットマップを抽出してsbit32で埋め戻したもの。TTEditは使っていない。
誤って取り除かれた%の装飾を修復。等幅の0のゴミを掃除。
Unicodeがない文字はビットマップを埋めても無効化されるため、285製ttfの8121字が7309字になっている(864ttc2は7292字)。マップされない字は全角(プロポーショナル?)ひらがなや単なる空白など、ほとんどが不要のもの。
Mobileは9ptビットマップだけの等幅。Lightはさらにアウトラインをダミーにしたもの。
285ttcや864ttcをベースにいろいろ修正している模様。
285ttcを全ポイントスムージング有効にしただけ。
22はSo_0016が速攻で消えたので上げなおしただけ。圧縮しなおしたためサイズは変わっているが中身は一緒。名前が変わったのはアップローダーの都合。
864TTC3を全ポイントスムージング有効にしただけ。
864TTC3と285製の違いがそもそもビットマップ関係なので、ClearTypeを使っていない限りSo_0016とたぶん同じ。
ClearType有効でもアンチエイリアスが掛かる。
TTEditで作成。
12ptのビットマップを13.5ptから作成。18ptは埋め込んでいない。
9ptのビットマップのズレを修正。