FontForgeでフォントに「文脈依存の置換(conditional features)」を設定する


FontForgeでフォントに「文脈依存の置換(conditional features)」を設定する手順を解説します。
文脈依存の置換は、前の文字によって次の文字を異字体に置き換える機能です。
筆記体(Script)書体にはぜひ必要な機能です。文字間の線を滑らかに繋げるために、前の文字に合わせて字形を変えなければならないからです。
Conditional Feature in my font.
caltにより設定された条件により、aaltによる置換を呼び出すものと思われます。 わたしも本設定を試している途中なので詳細はまだ不明です。
 
なお、本手順中でLookupとSubtableの名称は、FontForgeが自動生成するデフォルトのものを使用しました。
FontForgeは、日本語環境では日本語の設定名を生成します。
今回は、LANG=Cを頭に付けたコマンドライン呼び出しにより、英語ロケールとUIで作業を行いました。
英語のリファレンスを検索しやすい、などの利点もあるので、英語ロケールで作業することをおすすめします。


References:
『チュートリアル (その 7)』による条件付き機能による置換を使用します。英語版『Tutorial #7 (Conditional Features )』も、日本語版が少し古くなっているので、必要に応じて参考にしました。
しかし、この英語版も説明が丁寧ではないので(あるいは英語版も古くなっているので) 、既存の条件付き置換を使用したフォントをFontForgeで開いて設定を読んだりしました。

This sample setting:
letter "b" を前の文字によって "b.high" に置き換えます。
"b.high"には適当なコードポイントを割り当てました。これがテストであるためです。本当はフォント固有の異字体を置くためのコードポイントが定義されているので、その領域を使うべきです。

## Create "b.high" letter




適当なコードポイントに"b.high"を作成します。
デフォルト設定では、一部の文字を覗いてユニコードコードポイントによる"uniXXXX"といった名前が付いています。エディタ上部の名前入力欄か、MenuのElement>GlyphInfo(グリフ情報)から、グリフの名称を"b.high"に変更します。

Setting lookup aalt(Access All Alternates)

Lookup aalt

Menu "Element" > "Font Info"
エレメント > フォント情報

"Lookup"/"GSUB" tab > "Add Lookup" button
 Lookups タブの "add lookup"

Type: "Single Substitution" > Feature: "Access All Alternates" (aalt)
種類:単純置換 > 機能:すべての異字体へのアクセス

どれがaaltなのかわからない場合は、種類:単純置換 > 機能:必須の機能 で出てくる RQDを指定してから、直接"aalt"とタイプして書き換えることができます。

Select GSUB Lookup features.

# Subtable aalt

Selected target aalt lookup.
"Add Subtable" button
Base Glyph Name: "b" / Replacement Glyph Name: "b.high"



aalt setting.

## Setting lookup calt(Contextual Alternates)

# Lookup calt

"Lookup"/"GSUB" tab > "Add Lookup" button
Type: "Contextual Chaining Substitution" > Feature: "Contextual Alternates" (calt)
種類:文脈連鎖依存の置換 > 機能:文脈依存の異字体

GSUB add lookup.

注意:この時、Type: "Contextual Substitution"を選んでもcaltを作成することができますが、
こちらは同じcaltでも、目的である文脈連鎖による異字体の設定ができません。
必ず、Type: "Contextual Chaining Substitution" を選択してください。



# Subtable calt

Edit Cahining Substitution "By Classes" / Dialog Type:"simple"
"クラスで指定" / Dialog Type:"シンプル"

以下は日本語環境でも同じ
Match Classes(1) Name:"hight-after" Glyphs in the class:"v"
Match Classes(2) Name:"letters" Glyphs in the class:"a b c d e f g"
Matching rules based on a list of classes:
"high-after | letters @<'aalt' Access All Alternates in Latin lookup 0> |"


select match type and dialog type.


edit calt features.

# Check setting conditional features.

Menu: Window > New Metric Window
Menu:ウィンドウ > メトリックウィンドウを開く
write: "abvb"

Conditional Feature (Metric Window).

この記事は「FontForge conditional features (calt/aalt)」の日本語版です。


by MichinariNukazawa(ja) @ Project daisy bell(product freefont/font)

ffmpegフォークで、動画から静止画を連続キャプチャ (Ubuntu 15.04)

ソルジャーレギオンのデザインが知りたくなったので、「ガメラ2 レギオン襲来」を静止画キャプチャして観察することにしました。
最初は、VLCのキャプチャ機能で、シーンを前後しつつ撮っていたのですが、フレームを指定して移動する機能がVLCに見つからず、映りの良い静止画を撮るのが難しかったため、ffmpegで一括取得した静止画から良さそうなフレームを抜き出すことにしました。
ソース動画はBD由来、ただし北米版です。
作業環境はUbuntu15.04。

キャプチャした静止画像
(『ガメラ2 レギオン襲来』(1996)より)


簡易まとめ:
・ffmpegフォークのavconvを使う
・'-ss'オプションを先にしても高速化は望めない?
・'-qscale'は必須
・'-qscale'は0でも1でも結果は同じ

avconvを使う

Ubuntuは15.04の時点で、ffmpegフォークでコマンド互換のavconvを採用しています。
手間をかけて外部からffmpegを持ってくるよりも、avconvを使うべきです。

静止画取得のオプション指定

今回のコマンドは以下のようにしました。
 avconv -ss 2250 -t 22 -qscale 1 -f image2 %06d.jpg -i

'-ss'は抜き出し開始位置を指定します。
『'-ss'オプションを'-i'より先に指定すると、開始位置から動画を読むので高速化する』というTIPSがあるとされていますが、今回作業した環境ではその効果が見られませんでした。
(オプション位置を逆にした版を試していないので、もしかしたら効果があったのかもしれませんが。効果がなくても目的は果たせるので確認していません。)

'-t' は抜き出し終点とされていますが、これは抜き出し開始時点からの相対的な経過秒です。
絶対時間ではありません。

'-qscale'は静止画のクオリティを指定するオプションです。指定しないと明らかに品質が落ちます。
指定値の最高レベル1を指定しておきます。今回の環境では、指定値は0でも1でも結果は同じでした。

'-r' はfps固定で動画を抜き出すオプションです。今回は、gif動画を作るわけではないので、固定フレーム24fpsにする必要はありません。よって'-r'オプションは不要です。


備考

・同一ディレクトリ内に多量の画像を置くと、nautilusファイルマネージャの反応が明らかに悪くなるので、一度に静止画キャプチャする時間は短いほうが良い。
・大量のBD(フルHDサイズ)静止画をUbuntuデフォルトの画像ビューアで閲覧するのは辛いので、別途ビューアを用意するべき。 参考:『Ubuntu14.04で使える画像ビューア一覧 』

・今回の動画(平成ガメラ)はBD由来といっても、BD登場前の作品であり、動画はリマスターか何かなので画質には限界がある。
・しかも北米版(G1/G2は同一ディスク内に収録)なので、日本語版よりたぶん少し画質が落ちている。
・後半のソルジャーレギオンの戦闘シーン、紫のフラッシュが炊かれる2~3フレームの箇所が顔アップなので観察しやすそう。
・やっぱり平成ガメラは良い。

なお、スクリーンショットに使った画像の一部は、
「『ガメラ2 レギオン襲来』(1996) 監督:金子修介」
より。

主な参考URL
基本オプション:
http://qiita.com/matoken/items/664e7a7e8f31e8a46a60
qscale:
https://trac.ffmpeg.org/wiki/Encode/MPEG-4
画像ビューア:
Ubuntu14.04で使える画像ビューア一覧 

イラスト作業に適したデスクライト LK-H766B を買った

フォントデザイン作業やイラスト練習をする際、手の影が邪魔だったので、それまで使ったことのなかったデスクライトを導入してみようと思い立ちました。
この記事は、実際に使ってみた際の防備録です。

購入したのは、イラスト描きに適したデスクライトを調べて見つけた『TWINBIRD アーム型タッチインバータ蛍光灯 ブラック LK-H766B』です。
ついでに、蛍光ランプを交換するのがオススメとのことだったので、『三菱 FPL27ANX』への交換も試してみました。




開封

私が購入した際にデスクライトに同封されていた蛍光ランプは『三菱 FPL27EX-N』でした。

デスクライトを開封したところ。(+交換用に別購入した蛍光ランプ)
 アームの根本は差し込み式で回転します。アームとヘッドはつながった状態で封入されています。
(油性ペンはサイズ比較用に置きました。)


デスクへ配置

私の机には、中央にディスプレイ(27型)が配置されています。
何も考えずにディスプレイの脇にデスクライトの支柱を立てると、視界の中でディスプレイに被ってしまいます。


ディスプレイ脇に配置


少し離した位置に配置します。
(ヘッド部分はこれ以上アーム側に回転しません。)

ディスプレイとかぶらないように再配置
ライトの映り込みは、角度によります。今デスクライトが点いた状態でPCを使っていますが、写真のように画面上の表示が潰れてはいません。


効果

工事現場のライトのようなものを想像していたため、第一印象では思ったより明るくないように感じたのですが、実際に使ってみると、手元とペン先を照らすには十分でした。

デスクライトを点けていない場合

デスクライトを点けた場合

備考:蛍光ランプの交換


Web上で紹介されている蛍光ランプの交換をしてみました。

蛍光灯の光の色が、確かに少し違います。
色の再現度や目への負担が、どの程度違うのかはわかりません。
蛍光灯自体は安いので、わたしは交換部品の確保も兼ねて、買ってみて試したのですが。


MyPaintをビルド(on ubuntu 14.10)


2014年1月時点でのMyPaintソースコードを、Ubuntu14.10上でビルドした防備録です。
前回試した時の 『MyPaint1.1+のGitリポジトリ版をUbuntu13.10で試す 』とは、少し変わっているようです。

ビルドしたMyPaintを実行したところ

まずソースコードを取得します。
私が前回試した際の古いリポジトリをpullして更新したディレクトリではビルドに失敗したので、今回は新規にcloneしました。
git clone https://github.com/mypaint/mypaint.git

とりあえず依存パッケージを追加しておきます。
sudo apt-get build-dep mypaint -y
足りないパッケージは手動で導入します。

pygobjectを要求されたら python-gi-dev を導入します。

sudo apt-get install libgtk-3-dev -y
sudo apt-get install python-gi-dev -y

前回に対して、サブモジュールの導入が増えています。
私は一度サブモジュールの導入を行ったのですが、『brushlib/mypaint-brush-settings.c:36:31: fatal error: brushsettings-gen.h: そのようなファイルやディレクトリはありません』などとエラーが出たので、再度実行してからビルドしました。
git submodule update --init --force
scons

実行します。
./mypaint

以上です。

SVG画像の分割スクリプトをPythonに移植した話 - SVG Advent Calendar 2014-


この記事は、SVG Advent Calendar 2014の参加記事です。前回(20日)は @hashcc さんの「東京の鉄道路線図SVGを作りました&パブリックドメインで配布します」でした。
@hashccさんの力作の翌日を担当することになってしまいましたが、微力ながら相応の記事になるよう力を尽くす所存です。

今回は、ルーン文字フォント制作に使用している手製のSVG画像の分割スクリプトを使うことになった経緯、その再実装(リファクタ)に至る過程、そしてその結果について書かせていただきます。

RuneAMN_Pro_Blackletterより


オリジナルフォント作りと、SVG画像の分割スクリプト

わたしが現在公開しているRuneAMNシリーズフォントは、イラスト・デザイン向けに作られたルーン文字フォントです。普通のアルファベットを入れてフォントを適用するだけで簡単に、ルーン文字をデザインに使えるようになっています。
シリーズ構成は、独立したFree版とPro版(有償)があり、それぞれ重複しない独自の書体を収録しています。
他に、Project "daisy bell"の製品として、OlChikiAMN(オルチキ文字フリーフォント)も配布しています。

これらのフォントを制作する際、Illustratorで書体デザインを行っています。そして、SVG画像への書き出しを経由して、FontForgeに読み込ませてフォント化しています。
なぜフォントエディタの編集機能で完結させず、複雑なビルド手順を踏む選択をしたかといえば、FontForgeよりIllustratorのほうが、ベクタ画像のエディタとしては使い慣れており高機能だったという点に尽きます。
また、フォントのデザインの中には、フォントエディタでなければ事実上デザインが不可能なもの(Multiple Masterなど)もありますが、今回はそういったフォント機能を使う予定がなかったため、この手法を選択することができました。

SVG分割スクリプト(svg_splitter.pl)の機能拡張

フォントの制作プロセスにおいて、『すべてのグリフ(文字)を一枚のSVG画像に描いて、後から自動分割したい』という要求がありました。
すべてのグリフを1枚の画像に描きたかったのは、そのほうがファイルの管理が簡単で、デザインを統一しやすいためです。
自動分割というのは、スクリプトにより1枚の画像から、1文字につき1ファイルの状態に分割することができる、ということです。SVG画像の分割を、makeを使ったビルドプロセスに含めるために必須でした。

OlChikiAMN_Series_Fontsより


ところで、SVG画像の圧縮は熱心に研究されている一方で、SVG画像の分割は 、あまり試みられていないようです。
私が見た限りでは、

・Illustrator(スクリプト)は、アートボードで範囲を区切って書き出しても、範囲外の表示されないすべての要素もSVGファイルに含めたまま出力する。
・ InkScapeにはスクリプト化の方法が2種類ある。
  コマンドライン引数の方法では、詳細な制御ができない。
  Python拡張版(inkey)ではなぜかLGPL汚染が懸念されており、さらにAPIの網羅されたドキュメントを見つけることができない。
・Perl、PythonにはSVGを処理する多くのライブラリが存在するが、そのほとんどが「SVGを圧縮」するか「SVGをラスタ画像に書き出す」機能しか持っていない。
  (参考として、PythonのSVG関連ライブラリを調べた方が作った一覧がこちら。 )

結果的に、SVG画像を画像として扱う"まともな"分割器を見つけることができませんでした。

見つかったのは、mashabow@しろもじ氏の手書き文字「てきとうに書いてつくったフォント」用SVG分割器と、M+フォントのビルドシステムに含まれているSVG分割器でした。
このどちらも、SVGを画像ではなくXMLテキストとして解析した後で、SVG要素を独自に計算することでSVG画像の分割を実現しています。
M+の分割器は、SVGの多くの要素に対応していた反面、日本語フォント1万2000文字オーバーをすべて分割できる機能を持たせるために、複雑な構造となっています。(2ファイルに分割されており、内部動作もマルチスレッド化などがされている)。
一方、手書き文字フォントの分割器は、対応要素がpolygonだけである代わりに、1ファイルに完結しており動作も容易に追うことができました。
以上のことから、RuneAMNでは、手書き文字フォントの分割器を、拡張しながら使っていくことにしました。

リファクタ・PerlからPythonへの移植

このスクリプトは、RuneAssingMN_Free、OhChikiAMN_Free、RuneAMN_Proの制作に、機能拡張しながら使われました。ほぼすべての拡張が「その場しのぎのやっつけ仕事」で行われました。そのため、コードベースは混乱を極めており、コピーペーストされた同じ処理がいくつもの場所に分散しており、機能拡張とバグ修正は困難を極める状態になっていました。
例:
・SVG要素を切り出す際、配置位置の計算は、分割サイズで割って余りを出すだけ
 (マイナス値など、グリフ形状が文字の枠からはみ出す部分を持つことを考慮していない)
・分割判定部は、SVG要素の数だけコピーペーストした
 (polygon/rect/circle etc...)

『控えめに言ってこのスクリプトは公開することで私の(あって無いような)キャリアに傷をつけるのではないかと危惧するほど汚いfixやその場凌ぎのコードで満ちている。しかし、スクリプトがたとえ飛び出したクジラの内蔵の干物のようであったとしても、生成されたフォントの美しさはカケラも損なわれない。グリフのデザインは、1/10ピクセルも、まったく、狂わないからだ。ならばリファクタリングは時間の無駄と言える。』
(Pythonによる再実装を行う前の、本記事の原稿より。)

もちろん、コードが汚いからといって、フォント自体は1ピクセルも変化したりはしないことは誰でもわかっています。コードが綺麗であろうがクジラの内蔵が飛び出した状態であろうが作られたフォントの美しさは全く損なわれることがないことは間違いありません。

『しかし実のところ、svg_splitter.plの次の機能追加やバグフィックスは困難を極めるだろう。私は有名な「すべてを一から書き直したい病」にかかっており、誰かがこのスクリプトを使いたいと言ったならば、私は間違いなくすべてを書き直す。そしてその時はPythonを使う。フォントプログラミングとPythonは相性がよく、例えばFontForgeはネイティブ言語とは別にPythonスクリプトによる制御を提供している。また、PythonにはPerlと同じように、SVGのベースであるXMLを処理するためのライブラリがあらかじめ用意されている。余録として、将来Windows環境をサポートする際に、FontForgeのWindowsポート版がPythonインタプリタを持っていることが期待できる。』
(Pythonによる再実装を行う前の、本記事の原稿より。)

RuneAMN_Free/Proのアップデートを決意した私は、そのためにはSVG分割スクリプトに新機能が必要であると判断しました。
そこで、以前から考えていた、リファクタを兼ねたPythonへの再実装を行うことにしました。




リファクタリングの結果

再実装中のPythonスクリプト版


Pythonへの移植を行ったため、当然ながら、すべてのコードが1から書きなおされました。
リファクタリングでは「新しい機能はひとつも追加しない」のが鉄則ですが、今回はいくつかの新機能・機能改善を含みます。
以下が、リファクタ作業の結果です。

・見通しの良いコード
   ・すべての機能は関数に分割された。
   ・新しいmain部は20行ほど
   ・新フォントのための新機能を容易に追加できる
   ・transform属性を処理する部分が関数に共通化された。
   ・アプリケーション・ハンガリアン記法になった。
リファクタリング以前、SVG分割器の機能は関数化されていませんでした。
度重なる機能追加により同じ機能があちこちに散らばり、処理の流れが簡単にはわからない状態になっていました。
また、変数名や関数名にもルールらしいものはなかったため、可読性が低く処理を追いかけることが困難になっていました。
リファクタリングの後、多くの部分が適切に関数化され、処理を以前より容易に把握することができるようになりました。
アプリケーション・ハンガリアンは(リファクタリングと共に)Joel on Softwareの受け売りですが、命名規約があることにより以前よりコードが読みやすくなったことは確かです。

・引数の処理を改善。プログラム内部でも、設定値が読みやすくなった。
・SVG要素の再配置の計算を正しい方法に直した
 「分割サイズで割って余りを出す」のではなく、「(分割セル上の行列位置×分割サイズ)を現在位置から引く」ことで、分割セルからはみ出したポイントなどを正しく分割後再配置できるようになりました。
・グループ要素(<g>)を再帰的に探索できるようになった。
 perl版では、対象1グループの中に含まれる(つまり1レイヤーの)SVG要素しか対象にすることができませんでした。
 そこで、グループを再帰的に探索するよう機能拡張しました。
 IllustratorやInkScapeで、書き出し前にレイヤ統合やグループ化解除をする必要がなくなった。
・ついでにいくつかの使っていないpolygonパスのコマンドに対応できた
  ほかの未実装部も容易に追加できるはずです。
・RuneAMN_Proを、.pl版と同じように、すべて問題なくビルドできる。
 汎用であることを心がけてはいますが、一方でこのスクリプトはdaisy bellのフォントプロジェクト専用であり、使われない機能は未実装のまま省略することができます。
 Python版がPerl版とまったく等価な出力が可能で、退行(リグレッション)していないことを確認できました。


また、余録として、
・分割スクリプトを通して、SVGの構文について学習することができた
・Python(Python3)処理系について学習することができた
PythonによるSVGの加工を学ぶことで、将来的にもっと高度なフォントデザイン支援を実現するための、足がかりにしようと考えています。
また、SVGはWebデザインなどの分野でこれからより使われるようになると思われ、理解しておいて損はないはずです。(そしてこれはSVG Advent Calender 2014の記事です。忘れてしまいそうになりますが。)

・SVG分割スクリプトのすべてを、自分でコントロールすることができる
機能追加のために行ったことにリファクタリングにより、フォント制作でしか使われないであろうSVGへの処理を、ビルドのコアに含めることが簡単にできるようになりました。これはフォント自体に影響を与えるものではないので、
『それがビジネスの核となる機能なら−−何が何でも自分でやることだ』
(これもJoel on Software ただし書籍)
の系になるのかどうかはわかりませんが。

ソースコードなど

main部分は、たったのこれだけになりました。
実際のコード部分は20行以下になっています。

if __name__ == '__main__':
 
args = docopt(__doc__)

 
# 設定ファイルを解析する
 
settings = getSettingsFromSettingFilePath(args["<listfile>"])
 
settings['output_dir'] = args['--output_dir']
 
pprint(settings)
 

 
# SVGファイルをxmlとして読み込む
 
tree = ET.parse(args["<src_image>"])
 
rootSvg = tree.getroot()
 
# SVGファイルの縦横サイズを取得する
 
widthSvg = getNumericFromStringHead(rootSvg.get("width"))
 
heightSvg = getNumericFromStringHead(rootSvg.get("height"))
 

 
# Todo: プリプロセスとして、非表示のグループとレイヤ名'*_ignoreSSSMN'を持つレイヤを除去
 
# Todo: 透明なsvg要素も除去する。タイミングは未定。


 
# SVGパスをレイヤ(グループ)ごとに分割器にかける(rootにも要素があるのでレイヤ扱いする)
 
dstsTable = [[0 for i in range(settings['col'])] for j in range(settings['row'])]
 
ravelGroup(dstsTable, settings, rootSvg)

 
writeSvgs(dstsTable, settings)


SVG要素の読み出し部分も、以下のように関数化され、整理されました。
さらに、再帰呼出しを使うことで複数レイヤに対応しました。

"""
 @brief xmlツリーからSVG要素を再帰的に検出して分割処理する
 @param 分割済みデータ連想配列
 @param 設定ファイル情報(分割設定)
 @param xmlツリー(グループ要素)
 @return 分割済みデータ連想配列
 

 
 
 
(Todo:エラー処理)
"
""
def ravelGroup(dstsTable, settings, svgGroup):
 
svgTransform = svgGroup.get('transform')
 
if svgTransform:
 
 
print('warning: not inplement transform attr.')
 

 
elems = list(svgGroup)
 
for elem in elems:
 
 
if '{http://www.w3.org/2000/svg}g' == elem.tag:
 
 
 
dstsTable = ravelGroup(dstsTable, settings, elem)
 
 
elif '{http://www.w3.org/2000/svg}path' == elem.tag:
 
 
 
dstsTable = ravelPath(dstsTable, settings, elem)
 
 
elif '{http://www.w3.org/2000/svg}rect' == elem.tag:
 
 
 
dstsTable = ravelRect(dstsTable, settings, elem)
 
 
elif '{http://www.w3.org/2000/svg}polygon' == elem.tag:
 
 
 
dstsTable = ravelPolygon(dstsTable, settings, elem)
 
 
elif '{http://www.w3.org/2000/svg}polyline' == elem.tag:
 
 
 
dstsTable = ravelPolyline(dstsTable, settings, elem)
 
 
elif '{http://www.w3.org/2000/svg}circle' == elem.tag:
 
 
 
dstsTable = ravelCircle(dstsTable, settings, elem)
 
 
else:
 
 
 
print("other tag:" + elem.tag)
 
return dstsTable


本スクリプトのコードは全体で559行あります。

最後に

GithubのRuneAssignMN_Series_Fonts他にて、フォント元画像、ビルドスクリプトなどのすべてを、自由なライセンスで公開しています。
また、RuneAMN_Pro_Series_Fontsについても、やはりGithubにてビルドスクリプトとテスト用のフォント元画像を公開しています。





今回紹介した、Python版のsvg_splitter.pyは、RuneAMNフォントの一部として、githubにてBSD class-2ライセンスで公開する予定です。
リリースの告知はフォントと同じにTwitterなどで行う予定です。もし今欲しいという方がいれば、連絡をいただければ個別に差し上げたり公開を早めたり、対応します。

Project "daisy bell"のフォント関連リリースについては、daisy bellのBOOTHまたはSourceForgeにて確認できます。
@MNukazawa でも告知しています。現在、 このtwitterアカウントでフォント制作過程を毎日報告しています。質問などありましたら気軽にどうぞ。

以上です。


明日のSVG Advent Calendar 2014は syon さんの「SVGでキラキラをつくりたい(願望)」 です。よろしくお願いします。

docoptを使ってみた(Ubuntu14.04 / python3)



現在、フォント制作に使用している、SVGを分割するPerlスクリプトを、Python3に移植中です。

引数の処理をPythonの流儀に合わせようと検索したところ、
『馴染みのあるヘルプを文法に従って書けばパーサを生成してくれます』(リンク先サイト様より引用)というdocoptが紹介されているのを発見。
githubのプロジェクトページによると、MITライセンス。
とても良さそうだったので、導入ついでに引数オプションをいろいろ変更することに。

変数名とコードの整理だけの純粋な移植をするつもりが、早速機能を盛ってしまいました。趣味プログラミングでこれを抑制するのは本当に難しい。



Ubuntu14.04へのdocoptモジュール導入を導入する際、普通にpipコマンドを使うと、Python2の方にdocoptが導入されます。私はPython3で使いたいので、
sudo apt-get install python3-docopt
にてPython3側に導入しました。


以下が、動作確認に使ったコードです。

#!/usr/bin/python3

"""Process some integers.

usage: this_script.py [-h] <src_image> <listfile> [--output_dir=<DIR_OUT>] [--width=<NUM_WIDTH>] [--height=<NUM_HEIGHT>]

options:
    -h, --help  show this help message and exit
    --sum        sum the integers (default: find the max)
    --output_dir=<DIR_OUT>    splitted SVG images output dir [default: glyphs_/]
    --width=<NUM_WIDTH>        width for unit of split base squared(cross-section) [default: 1000]
    --height=<NUM_HEIGHT>    height for unit of split base squared(cross-section) [default: 1000]
"""

from docopt import docopt
from pprint import pprint

if __name__ == '__main__':
    args = docopt(__doc__)
    numWidth = args["--width"]
    numHeight = args["--height"]

    widthUnit = numWidth    #
    heightUnit = numHeight    #

    print(widthUnit)
    print(heightUnit)

    pprint(args)


コマンドによる呼び出しと出力結果は以下のとおり。
python3 docopt_t.py RuneAMN.svg RuneAMN.list --output_dir=amn/ --width=800 --height=800800
800
{'--height': '800',
 '--output_dir': 'amn/',
 '--width': '800',
 '-h': False,
 '<listfile>': 'RuneAMN.list',
 '<src_image>': 'RuneAMN.svg'}



オプション引数名は『<angular-brackets> or UPPER-CASE』で指定しなければならないなど、記述フォーマットにいくつかのルールがあるようです。
とりあえず、docoptを記述した『"""形式コメント""" 』は他のコメントより前に置きましょう。他のコメントを前に書くとdocoptが機能しませんでした。ただし、『#』形式コメントが前にあっても問題なく機能します。
なお、直観に反して、[defailt: 値]の指定はデフォルト値を入れてくれるわけではないようです。いろいろ調べるより、自分でNoneをチェックしてデフォルト値を入れる処理を書いたほうが楽です。


docopt取得値の確認にはpprintが便利でした。

RuneAMN_Proの話 - #LOVEFONT Advent Calendar 2014-


はじめまして。Michinari Nukazawaと申します。
今回は、なぜか空いていた #LOVEFONT Advent Calendar 2014 の7日目の代打として、拙作のルーン文字フォントセット「RuneAssignMN_Free」および「RuneAMN_Pro」と、なぜこれらのフォントを作ったのかについて、書かせていただこうと思います。

6日目はMignon Styleさんの「すっきりして可愛い商用可のフリーフォント MigMix」でした。

まさか、初Advent Calendarが代打になるとは思いませんでした。だったら手を挙げるなという話かもしれませんが。
荒削りですが、ご容赦ください。


自作ルーン文字フォントを作るにあたって、紙面でデザインを練った

あなたは誰?

あらためましてはじめまして。MNukazawaと申します。Project "daisy bell" [booth.pm] の主催者です。
現在は、ルーン文字フォントセット「RuneAssignMN_Free」および、
フォントセット「OlChikiAssingMN_Free」をフリーで公開しています。
また、フォントセット「RuneAMN_Pro」を販売しています。

最近ではオープンソースのフォント作成アプリFontForgeの日本語訳ページの不具合修正などをやったりしていました。
わたしは自分の肩書はプログラマだと思っています。...が、いつのまにやら現在の主なプロダクトはフリーフォントになってしまいました。
責任者はどこか。俺か。


RuneAssingMN、フリーフォント版の簡素な紹介画像
RuneAMN_Pro版ではさすがに、見本画像のデザインにも注意した

フリーフォントの配布はSourceForgeでも行っています。
こちらは、サポートのTwitterアカウント。Twitterでは、今のところほぼ毎日、フォント作成の作業経過を報告しています。

daisy bell のBOOTH。この前予告なしにユーザアイコン領域が追加されて驚いた。

これらのフォントは、ただ配布・販売しているだけでなく、その制作に使用したプログラム(ビルドスクリプト)と素材ファイルをgithub上で無償公開しています。
(Pro版も、すべてのビルドスクリプトと、スクリプトの動作検証用に1フォント素材を公開している)


LOVEFONTはフォント利用者の視点がメインのようなので、今回は製作者として。(アドベントカレンダー内でフォント会社の中の人の登場予定とかありそうで怖いですが...。)

RuneAMN_Proフォントセット作成までの過程

最初に重要なことを。

『FreeはProの体験版ではありません』

サブセットでもない。
完全に独立したフォントセットで、どちらかというとProが従(後)。

RuneAssignMN_Freeフォント

ソフトウェア世界には「オープンソース」という考え方があります。
「自分の作ったものを無償公開し、いろいろな人に使ってもらう」
オープンソースに貢献したい、何かをオープンソースで公開してみたい。
そう考えていました。

で、ある時、Puella Magi Wikiの解読班&フォント作成に影響された。
(私が公開しているフリー版ルーン文字フォントの割り当て表は見ましたか?)
重要な点として、私はフォント界隈の外の人間として、その時はじめて、
『フォントはひとの手で作ることができるんだ!』
ということを認識しました。(フォントワークスジャパンとか何の集団だと思っていたんだ私...。)


これらのことが重なって、『そうだ、フォントを作ろう。』と思い立ったわけです。

しかし、1万文字を超える日本語フォントを作るのはとても大変です。
また、普通のフォントは、大手フォントベンダがすでにほぼ作り尽くしています。
(モリサワとフォントワークスがサブスクリプションに移行したのはAdobeと同じ理由で、製品はすでに完成してしまっており、ユーザはもう新製品を買う理由が無くなったからなのだろうと思います。)
そこで、ちょっと狙いを変えたフォントを作ることにしました。
つまり、『ファンタジーなイラストで使えるフォントを作ろう』。
調べたところ、文字にもいろいろあることがわかりました。
そして、『ルーン文字』のフリーフォントは5件しかない。(そしてライセンスを調べると、本当に「フリー」と呼べるものはそのうち3件だけだった。)
イラスト・デザイン向けにルーン文字フォントの需要はあるのではないかと思いました。

そして、3つのフォントをまとめたフォントセットとして、RuneAssignMN_freeフォントセットをリリースしました。
リリースまでは、初めてだらけの行程でした。たとえば、ルーン文字とアルファベットのライセンスフリーかつ完全な対応表が存在しなかったため、自作する必要がありました。
他にもいろいろ勉強し、技術的な問題を解決しつつ、紆余曲折の末のリリースでした。

このフリーフォントのライセンスは、2-clause BSDです。このライセンスはたとえば、
・このまま値段を付けて売っていい!
・このフォントを元に商業フォントを作って売っていい!
・ゲームとかに組み込んでOK!
・もちろんイラストに使い放題!
・上記のことを作者に連絡する必要もない!
といったことが許されます。(なのでぜひ使ってください。)

また、 フォントだけでなく、作り方と使ったプログラムも同じライセンスで公開しました。

で、満足したのでこれで終わるはずだったのですが。

RuneAMN_Proフォント

Q.「オープンソース」と言いながら、なぜフォント”販売”をすることにした?
A.父が定年退職したので。

私は院卒であったため、まだ社会人2年目...。
手っ取り早くお金になるものはないか?

作ったばかりのフォント+ビルドシステム+まだ作り方を覚えている
=そうだ、フォントを作って売ろう!

しかし、既にフリーで公開しているものを売りたくはない。
=そうだ、(フリー版とビルドシステムを元に)まったく新しい書体を作って売ろう!


Pro版制作にあたって、新たに立ちふさがった技術的な課題など、何が起こったかはいずれ、「RuneAMN_Proへの道 part1〜」などと題して記事にするつもりでいます。今ゆっくり書いている。
そのシリーズでは、フォント作成に特有のSVG画像の取り扱いや、グリフデザインの手順、書体見本誌の作成(PDF注意)。そして何より、「フォントファイル」を「フォント製品」にするために私がやったことを、もっと具体的に書くつもりです。


フォント製品には必ず付いてくる書体見本誌(写真は草稿)。
Web上で公開しているので、購入前に見ることができる。

技術的な課題の例:「RuneAssignMN」 ->  「RuneAMN」へシリーズ名を変更。
Windowsのフォント名前数制限に引っかかったので。(32文字だったっけ?)
(この例はしょぼいな...。)

ともかく、そんな感じです。


で、LOVEFONT的に。

Q. 自分の作ったフォントのなかで、どのフォントが好きなの?理由は?
A. FreeならばSerif、Pro版ではBlackletterかな。
    理由? どれも自分の娘のように可愛いに決まっている。

RuneAssignMN_Serifのここがすごい!

RuneAssignMN_Serifの書体素材画像(のjpg出力)

Roman体のような綺麗なセリフ体を目指しました。
ルーン文字の直線からなる角ばった形状に、セリフがよく似合います。
他のルーン文字フリーフォントに、セリフを持っている書体は存在しません。RuneAMNだけです。


RuneAMN_Blackletter のここがすごい!

ブラックレター体の書体見本より。
魔法・魔術と強く印象づけられたルーン文字と、華美な装飾が特徴のブラックレター体。この組み合わせは非常に相性が良く、非日常を演出するのにこれ以上ない効果を発揮してくれるはずです。
もちろん、他のルーン文字フォントにはブラックレター体は存在しません。
(またかよ、と思いますが、実際ないです。(あったら恥ずかしいなこれ。))



RuneAMNシリーズフォント、今後のFuture

といっても、リリースされるのは夏かもしれないし、そうでないかもしれない、というくらいのものです。
また、Pro版は、購入済みユーザには何らかの優待をする予定です。無償アップグレードとか。

ブラックレター体のデザイン方法

RuneAMNとは直接関係ありませんが、私なりにブラックレター体フォントをデザインした際の知見を還元するつもりです。
そのうち図と言葉にまとめて、Pixivなどにアップロードすると思います。

フリーの文字列素材・フリーの魔法陣素材ほか

RuneAMNフォントが使いやすくなるよう、フォントを使って作成済みの素材を、フリーで公開するつもりです。
また、他にもいろいろと工夫をしようと考えています。
今のところは、サポートのTwitterアカウントにて、一日一個のペースで魔法陣素材を作り貯めているところです。



新しい書体!

フォント製品ですから、製品強化するにあたって、新しい書体の追加に勝るものはありません。
今のところ、複数のKnife書体(くさび形文字書体)の追加が決定しています。
各Knife書体は、デザイン済みで校正前。

デザイン作業中の、RuneAMN_KnifeC書体(仮)


他にも構想・デザイン中の新ルーン書体がありますが、それはまたいずれ紹介できればと思います。

総括:みなさんフォント作りませんか!

ビルドスクリプトも画像ファイルのすべて公開しています。
今も改善を続けています。
(たとえば今日、システムの一部をPython移植してリファクタしたので、機能追加しやすくなりました。これも、いずれ公開します。)
MNukazawa / daisy bellは、競合・ライバルを大歓迎しています。


プログラマの方へ:
FontForgeはすばらしいスクリプト環境(ネイティブorPython)を持っており、画像からのフォント生成を自動化できるすばらしいアプリケーションです。
フォント周りで活躍しているプログラマはあまりいないようなので、FontForge周りやSVG周りで暗躍して、もっとデザイナの方がフォントを作りやすい世界を作りませんか。

そして、プログラマでもフォントを作れます。私は作った。
1万文字を超える収録文字数の日本語フォントとか、むしろプログラマにしか(事実上)作れないと思います。私はまだ作ってないけど。
いかがですか。


デザイナの方へ:
今はGlyphs(Web上に日本語利用者の詳しい解説記事が見つからなかったけど)とか、Superpolator(同上)とか、すばらしい(私は使ったこと無いので...)フォントアプリがあるらしいので、フォント作りませんか。
そして、Glyphsとか、利用者の声をネットで訊いてみたいです。

あ、もし、非フォント系デザイナの方で、フォントを作りたい方がいれば、ロハで相談に乗ります。相談だけかもしれませんが。Twitterでお声掛けください。
あと、FontForgeは無料で、しかも親切な日本語マニュアルまでWeb上に無償公開されているのでオススメです。

今どきのFontForge(2014/12)

以上です。


明日の#LOVEFONT Advent Calendar 2014は、sada_hさんの「精興社書体について #LOVEFONT」です。よろしくお願いします。

ComfyUIでXYZ-PlotするワークフローのサンプルとTips(ComfyUI-XYZ-Stitch)

 ComfyUIでAutomatic1111的なXY-Plotをしたいのだが、ComfyUIデフォルト機能には用意されていない。     カスタムノードが必要となるのだが、Webには古いとか何故か動かないとかなXY-Plotパッケージの使ってみた系記事か、githubに上げられた...