CHIRASHI バージョンアップのお知らせ

CHIRASHI をダウンロードしてくださった皆様
ありがとうございます。

最新バージョン 1.1 を公開しました。
Mac AppStore でリリースされています。
主に写真とか図形の操作性の向上を行いました。

Updateは無料ですのでどうぞダウンロードしてください。
お使いいただいた後、評価やレビューなどをいただけますと
大変うれしいです。

今後とも、よろしくお願いします。

モピシェイプのギャラリー

まあ、いろいろ絵を描いてみた。
こんなのとか

http://www.nokkeusi.com/mac/ja/mopiShape/gallery.html

カラフルなアヒル

今週は、MopiShape というMac用のアプリをリリースしました。
モピシェイプと読みます。
１０月くらいに、アッヒールちゃんの絵を描いたツールの写真をのせたことがありましたが、
ちゃんとカラフルな絵が描けるようになったアプリです。

このアプリは ベクトル系のドローアプリなどと呼ばれるものの一種です。
画面上のピクセルごとに色をつけて描くビットマップ系の描画ツール（Windowsのペイントみたいなもの）と違って、座標上の点と点を結ぶ線を使って描くアプリです。ビットマップ系のあぷりでは拡大縮小すると絵が粗くなったりしますが、ベクトル系の描画では、
常にきれいに描かれます。
それに、余り絵の上手でない私でも、結構かわいく絵が描けるような気がします。
結構楽しんで描いてます。

CHIRASHI App

CHIRASHI というMacアプリを作りました。
３日ほど前にMac App Storeのレビューがおわり、公開されました。
http://itunes.apple.com/jp/app/chirashi/id482532068?mt=12

１年ほど前からMacでアプリを開発をしようと思い立って、
この夏、８月末頃にCHIRASHIの開発に着手しました。
結局３ヶ月ほどかかりました。
最初はなめていて、頭の中では一ヶ月くらいで作れるつもりだった。
最初の一ヶ月でXCodeのプロジェクトから４度やり直し、おおむね現在の
見た目になった。１０月の２週間くらいでQRコードとJANコードの生成ロジック
を実装し、概ね今の外観になった。
しかし、嫁さんに見せたところ、かなりいまいちな評価となった。
文字が入力しづらいとか、文字の表示がピンぼけになっているとか、図形が足りないとかいろいろ。。。
そこで再度見直した。レイヤーで文字を描画するとピンぼけることがわかり、レイヤーの使用をやめたり、描画コードを書き直し、入力方法も見直した。図形を大幅に追加することを決め、別途図形描画ツールを作ったりした。
Mac App Storeの基準をよくよく調べると、OS X Lionでの動作が必須となっていた。結局、OSをLionに更新した。XCodeのバージョンも上がった。Lionの新機能 フルスクリーンモード、オートセーブ、バージョンなんかについては最初、懐疑的だったが、使ってみると、すばらしいと感じた。そこで、対応することにした。対応すると、他にも気に入らないところがでてくる。だから磨いた。 ぷきぷき。。。

Appleの開発ガイドを読んでいると、開発のフェーズは、大まかに言うと

• デザイン
• 実装とテスト
• 磨く (Polish)

からなる。
Polishが重要なのだという。Polishはテストではない。納得できるまで磨くのだ。
納得できなければリリースするべきではない。
と言うと、私のアプリは永遠にリリースできなさそうであるが、、、


１１月下旬にやっとApp Storeにレビューを申請した。その数日後、不具合に気がつき、
申請を取り下げ、再申請をしたりしたあげく、無事レビュー完了の知らせが届いた。

AppStoreに公開されたのは嬉しかった。
また、次にむけてがんばろー。おー。

Cocoaでの縦書きの実現について

OS/X 10.7 (Lion)では、NSTextView でも日本語のような
縦書による入力が可能になった。
OS標準のテキストエディタでも縦書きができるように
なっている。じぶんではあまり縦書きの文書は書かないので
あるが、使ってみると、なかなかいい。テキストカーソルは
水平になり、変換候補も横方向に縦書きで表示されるので
とても面白い。

NSTextView でレイアウトを縦書きにするには

setLayoutOrientation:　で

NSTextLayoutOrientationVertical　を指定するだけでよいことが

わかった。これだけで、テキストエディタと同じように縦書きで

テキスト入力ができる。

では、NSTextViewを使わずに、NSViewに縦書きのテキストを表示する

にはどうすればいいのか？

以前調べたときCoreTextを使って実現する方法がわかったが、

結構面倒なことになってしまったが、10.7になって、もっと楽な

方法ができたようだ。

CoreTextを使わずにCocoaのテキスト関連クラスで実現できる。

　NSTextStorage

　NSTextContainer

　NSLayoutManager

このうちNSTextStorage はNSMutableAttributedStringを継承している。

つまり、テキストの書式などの属性はテキストと共にNSTextStorageに格納する。

ここで、属性として　NSVerticalGlyphFormAttributeName　を設定すればよいようだ。

NSTextStorage *textStorage; があるとして、

    [textStorage addAttribute:NSVerticalGlyphFormAttributeName 

                      value:[NSNumber numberWithBool:YES] range:NSMakeRange(0, [textStorage length])];

のように指定する。

これで、日本語の文字はは左に９０度回転した状態で水平方向に並ぶようになる。

あとは、あなたも首を９０度傾ければ、縦書き表示が実現する。

首がつかれるので、いやだ？　

冗談はさておき、最初私は、さらに90配置を変更してくれる設定があるのだろうと

探していたが、見つからなかった。

じゃあ、Drawする前に、コンテキストに90度の回転を加えれば、それらしくなる

のかなと思ったのであった。ようは首を傾けるかわりにモニターを傾けるようなものだ。

その際に、表示域の縦と横を入れ替えてTextContainerに指定すればつじつまがあいそうだ。

でも、なんかしょぼい気がするし、NSTextViewはどうやっているのか気になった。

そこでヘッダファイルの説明を読むと、90度回転して表示しているらしいとわかった。

なんだ、同じじゃん！

コンテキストを回転するには     CGContextRotateCTM で90度時計回りの回転を

指定する。私のアプリはもともと任意の角度での回転を施していたんで、回転に

90度を足すだけだった。

やってみると、非常にいいあんばいになった。

もともと水平方向の描画をコンテキストで90回転しているだけなので、

水平方向のテキストアライメント（右寄せとかセンタリングとか）がそのまま

垂直方向に働く。よって縦書きテキストが上寄せ、中央寄せ、下寄せというように。

しかし細かいところで、課題が残った。

例えば水平テキストにアンダーラインを引くと当然、それは文字の下に線が引かれる

ことになるが、垂直なテキストでの傍線は私の実現方法では左側になってしまう。

それは普通、右側に引くものか？という点が気になる。

たぶんそうだ。右利きで鉛筆で縦書きに傍線を引くとき、左側に引こうとすれば

文字が隠れてしまう。よって、右側に引くのが自然だ。

でも、縦書きの印刷物で傍線が引かれたものなんて余り見かけないような気がする。

Appleの人も右側だと考えているようだ。テキストエディタでも右側に

傍線が引かれるようになっている。

しかし、これを実現する方法は今のところわからない。

NSScrollView内のNSViewの位置について

OS/X では、NSViewなどのコンテンツを表示するビューを
NSScrollView内に配置すると、そのNSViewは左下隅に貼り付く。
原点を左上隅にあわせるためには、そのNSViewのサブクラスにて
BOOL isFlipped　をオーバーライドして　{return YES} を
返すようにすればよい。

であるが、ウィンドウをリサイズして、NSScrollViewが小さくなったときに
表示されている内容が上にスクロールしてしまう。

（NSScrollViewは自動的にリサイズするようにしておいたとして。）

絵にするとこんな感じである。

ウィンドウをリサイズすることにつれてスクロールビューもちいさくなる。
そのとき、狭くなった分だけ、表示されている内容が上に上がってしまう。

普通のアプリケーションはそのような状態にはなっていないので、当然なんとかなるはずが
その方法がわからず、なやんだ。
Appleのサンプルプログラムのsketchの状態を調べているうちに
やっと違いが見つかった。

Interface Builder のSize Inspector でのAutosizingの設定が不足していた
ことが原因だった。
これは、コンテンツのNSViewの設定である。

不十分な設定

対策

これによって、問題が解決した。
簡単なことであったが、知らないばかりに悩んでしまった。

まあ、いつも思うことだが、複雑な解決策は何か遠回りをしているものだ。
何かを解決できずはまってしまう時は、間違った方向に難しく考えすぎている
可能性がある。また、その方向で、何とか実現できたとしても、
その方法が自分でも気に入らない時は、おそらく、まだベストではない。
もっとシンプルな方法が見つかるはずなのだ。

Quick Look Pluginプロジェクトの準備

自分のアプリケーションのドキュメントファイルにファインダーなど
でサムネイルやプレビューを表示するためには、
Quick Look Plugin を作成するという方法がある。

1) XCode 新規プロジェクトで　System Plug-in  の　Quick Look Plug-inを選択する。

2) アプリケーションのソースコードを（必要な奴だけ）プロジェクトに参照で追加する。

3) GenerateThumbnailForURL.c , GeneratePreviewForURL.c を

　の拡張子を.m に変更する。

    必要ならばincludeするライブラリを変更する。

　//#include <CoreFoundation/CoreFoundation.h>

　#include <Cocoa/Cocoa.h>

　アプリケーションソースもインクルードする

　例）

　#include "MyDocument.h"  

4) フレームワークの変更

　 必要ならばCocoa.frameworkを追加する。

5) info.plist の編集

　　Document types

　　　　Document Content Type UTIs

　　　　　　Item SUPPORTED_UTI_TYPE    

　　

　　SUPPORTED_UTI_TYPEを自分のアプリケーションのUTIに変更する

6) ターゲットにファイルをコピーするビルドフェーズを追加する。

　　　※絶対パス

　　　※コピー先：　~/Library/QuickLook   （/Library/QuickLook も可)

　　そしてビルドフェーズに Product のオブジェクトを追加（ドラッグで）する。

7) GenerateThumbnailForURL.c , GeneratePreviewForURL.cを編集する。

8) テストツールを設定する。

　メニュー：プロジェクト→新規カスタム実行可能ファイル

　　　/usr/bin/qlmanage 

　　引数を指定する。

　　　-p  documentFile.name       プレビューの場合

　　　-t   documentFile.name　　サムネイルの場合

以上！

あっひーるちゃん

昨日まで、プログラムで図形を描くために、
方眼紙の上で座標を調べつつ、コードを書いたりしていたが
かわいい絵を作ろうと思ったとたんに、面倒になった。

そこで、ソースコードを生成するためのプログラムを
作ってみた。

まず、これはモデルのアヒルちゃんである。

で、作ったアプリケーションで描いてみた。

いい感じじゃありません？

うしの写真

今日、うちの嫁が会社帰りに牛の写真集を買ってきました。
牛ばっかりのほのぼのとした写真集です。
これはいいものです。

へえ、こんなもの出している人がいたんだ〜と
とてもうれしくなりました。

今年、福島のほうでは、原発事故の避難により
取り残された牛達の悲惨なニュースを見かけます。
野良牛となってもなんとか生き残ってきた牛もいるそうです。
その映像をみて涙が出そうになりました。
せめてその牛達が無事に保護されよい牧場へ引き取られる
ことを希望します。

Cocoaでの上下逆さま

Cocoaでプログラミングを始めて惑ったことのひとつに
座標系(Cordinate system)がWindowsなどと違うことだ。
多くの言語では画面上の座標の原点は左上隅にあり、
垂直方向の座標は下に行くほど大きくなる。
Cocoaでは原点は左下にあり、垂直方向に上にいくほど座標が
大きくなる。（これは数学や、日常的な座標系とおなじである。）
とはいえ、このこと自体は慣れると思う。

ただ、左下隅が原点であるということによる不都合もある。
スクロールビュー(NSScrollView)の中に表示するビュー(NSViewなど）
がデフォルトでは左下隅にくっついてしまうのだ。

外側の青い部分がスクロールビュー
内側の白い部分が内容を表示するビュー






この状態では、アプリケーションの使い勝手が悪くなってしまう。
これをこういう状態になおしたい。


この場合、内側のビュー（NSViewなどを継承したビュー）
のクラスにて isFlipped をオーバーライドし、戻り値としてYESを返すようにするだけでよい。
- (void)isFlipped{
    return YES;
}




ビューに直接描画しているのであれば、これでOKなのであるが、
いったんレイヤー（CGLayer)に描画してからビューに投影している
ような場合、不都合が残っている。

左図のように鏡で上下が逆さまになった状態となってしまう。
レイヤーはFlip（上下反転）していないままそこに Hello と描画している。そのレイヤーをFlipされたビューに描画する際にひっくりかえるのだ。


よって、レイヤーもFlipしておく必要がある。
レイヤーに描画する前にそのコンテキストに対して以下を施す。

CGContextTranslateCTM(layerContext, 0, layerHeight );

CGContextScaleCTM(layerContext, 1, -1);

一つ目で、原点を垂直方向に移動させる座標変換がコンテキストに登録され
二つ目で、垂直方向の座標の符号を逆転する座標変換が登録される。
例えば横幅100 x 縦100 のサイズを持つレイヤー上の
座標（10, 20) はFlip（上下反転）すると
一つ目の変換では　座標（0, 100) を原点とした場合の座標に変換されれるので
(10, -80) となる。
二つ目の変換では垂直方向の符号を逆転するので、(10, 80)　となる。

※つまり下から20ポイントの場所は高さ100ポイントの場所からみると
下に向かって80ポイントの場所にあたるということである。

このようにしてFlipされたレイヤーには上下反転して描画される。
そのレイヤーをFlipされたViewに描画すると、さらに上下反転され
正常な状態で表示される。

COCOA備忘

これは自分のための備忘です。すみません。

• Resources フォルダのファイルパスをプログラム実行時に取得するコード
• [[NSBundle mainBundle] pathForResource:@"filename" ofType:@"extension"]

• CGLayer上にテキストを出力する方法。
  NSViewなどに出力する時はNSStringのdrawInRectが使えるが、CGLayerに出力するケースには使えない。この場合CoreTextを使う方法が簡単そうであった。
• NSAttributedStringを生成
  NSAttributedString *attrStr = [[NSAttributedString alloc] initWithString:@"こんにちは" attributes:fontAttributes]; 
• CTLineCreateWithAttributedStringを使って CTLineRefを生成
  CTLineRef line = CTLineCreateWithAttributedString((CFAttributedStringRef)attrStr);
• CGContextSetTextPositionを使って出力位置を指定
  CGContextSetTextPosition(context, pt.x, pt.y);
• CTLineDrawを使って文字を出力
  CTLineDraw(line, context);
• メモリの解放
  CFRelease(line);
  [attrStr release];

• イメージの特定の色を透過させる方法。
  このような処理を Maskingと呼ぶ。
  rect はNSRect型で表示したい場所をさしている。
  ctx はグラフィックコンテキストをさしている。
• 元のイメージが NSImage *nsimg に生成済みだとする。
  これからCGImageRefを取得する。
  CGImageRef cgimg = [nsimg CGImageForProposedRect:&rect context: ctx hints: [[NSDictionary alloc] init]];
• マスキングカラーを設定する
  CGFloat maskingColors[6] = {255,255,255,255,255,255};
  //左から二つずつ組となりそれぞれR,G,Bの範囲を示している。
• マスキングをかけたイメージを生成する
  CGImageRef maskedImage = CGImageCreateWithMaskingColors(cgimg, maskingColors);
• コンテキストに描く
  CGContextDrawImage(ctx, rect, maskedImage);

数学

先日、友人と飲みにいったときに、やっぱり、
数学は大事だよね。ということになった。

プログラムを作る上で、何か変わったことをしたいと
思った時、数学的な知識の不足を感じるのだ。
例えば、画面上に表示する図形を傾けるだけでも
角度を求めるために三角関数を使ったりする。
プログラミング言語には数学関数のライブラリがある訳だから
sin も cos も tan も使えばいいのだが、高校以来
そういうものは忘れてしまっているので、
まずそこから調べねばならなくなる。
先日、QRコードの誤り訂正コードのことを書きましたが、
あれは 有限体とかガロア体というもの性質を応用している訳だが
そういうものは、さっぱりわからぬ。
誤り訂正という技術は、通信データの補正などにも使われている
そうだ。そういうものがあるので、はやぶさのような宇宙探査機と
地球との間で通信ができるのだ。
インターネットで使う暗号技術だって、数学者が生み出した。
数学がないと安心してネットで買い物が出来ないのだ。

そう、実は数学は世の中を支配しているのだ。
という結論で飲み会はお開きになった。

Cocoa

去年の暮れに iMacを買いました。
これまでずっとWindows一辺倒だったのですが、
なんかインターフェースがすっきりしているというか
洗練されているところに惹かれてiMacにしました。
WindowsXP以降インターフェースのデザインが
だんだん野暮ったくなっているような気がします。

まあWindowsはおいといて、今後はMacでアプリを作ってみたいぞ
というわけで、時間を見つけてはAppleのフレームワークである
Cocoaの学習をしています。
年末に「Mac OS X Cocoa プログラミング」という本を買いました。

本当はある程度集中して、読み進めた方がいいのですが、
仕事の合間に、ちまちまと読みすすめてきたので、今週になって
やっとほぼ読み終わったところです。
でも、この本はObjective-Cも初めて、Macも初心者という私にはちょうど
とりかかりやすいものでした。

今週から、自分の作りたいようにいろいろ試しています。
いつもそうですが、教科書のサンプルコードを書いて試しているうちはいいですが
いざ、自分でこれをしようとか思った時には、まごつきます。
教科書に載っていたことも忘れているし、やりたいことがその教科書に
載っているとも限りません。
幸い、XCodeに附属のドキュメントはとてもよく出来ているようです。

これからが本当の始まりです。楽しみがいっぱいです。

パソコンの掃除

パソコンはDELLのDimension 5150C という４、５年前のモデルだ。
先日OSからすべて入れ直したので、電源ONから使えるようになるまでの
時間は１分ちょっとくらいになり、まあ古いパソコンとしては並になった。
しかし、ファンはあいかわらずフル回転し掃除機並みの音を出しているのでとても快適とは言い難かった。

インターネットでくだんのパソコン名と騒音といったキーワードで探してみると、困っている人はたくさんいたようで結構出てきた。
いくつかのページを拝見したところ、どうも、

• 電源ファンは筐体内に暖まった空気を放出し、CPUファンも外気を取り込みCPUの放熱により暖められた空気も筐体内に排出され、ハードディスクのあたりを通ってそとに自然放出するつくりのため、内部の温度が上がりやすい。
• CPUの発熱が最近のものに比べて大きい。
• 吸気ファンの吸い込み口の構造上、掃除しにくい場所にホコリがたまってしまう。

ということらしい。
構造上の問題はどうにもならないので、（改造している人もいたが。。。）
どうも分解掃除がよいということなので、やってみた。

分解方法とか手順については、
http://www.yoshi-systemservice.com/computerservice_dell-dimension-5150c_cleaning.htm
が写真入りで詳しい。

http://buono99tt.blog55.fc2.com/blog-entry-156.html
このサイトもさらに丁寧に手順が書かれていた。
後で見つけたのであるが、これを見ていれば、もっと簡単に分解できた
かもしれない。ただ、フィギュアのブログなのでかわいらしい。

で、分解してみたら、外気吸い込み口の前はこんな状態だった。

びっしりとホコリが固まっていて、これでは空気が通るまい。
また、ファンの状態もひどくホコリがこびりついていた。

で、掃除機でホコリを吸いとり、こびりついた汚れを綿棒で拭き取り、
組み立て直しました。

そして、電源を入れると、おお〜。
ものすごく静かになった。しばらく使っても、大丈夫、それほど回転数は上がらないようで比較的静かだ。

というわけで、分解掃除は効果が多いにあった。
ただ、前面パネルがぴったりとはまらなくなってしまったが、
自分で使う分には、まあ、特に問題ない。

QRコードを作るプログラムを作る（5）

誤り訂正コードの作成です。

ここはもっとも難航したところなので、ブログも書きづらい。
規格書およびネットで検索して参考にさせていただいた情報に
もとにプログラムを書くことはできましたが、なぜそうなのという
ところが完全には理解できていないせいである。

最初に、ネットで検索して、大変参考になったページを

を書き留めておきます。

そもそもQRコード作成の手順としては

http://www.swetake.com/qr/qr1.html

この方の説明は全体的にとてもわかりやすいもので、
おそらくページの説明なしに、私は完成できなかったと思います。
大変感謝です。

それから、ガロア体というのは下記のページを見て参考にしました。

http://chichiue.hahaue.com/gf.html
http://en.wikipedia.org/wiki/Finite_field_arithmetic

結局、数学として理解できないことはいったんさしおいて、プログラム作成にあたって、
理解したことは次のとおりである。

• 誤り訂正コードの生成多項式に登場する係数 αⁿ のところで指数 n に対する整数が一意に存在する。
• 指数 n に対する整数の求め方は ８桁の２進数で指数0のとき "00000001"から初めて、指数が上がるたびに左にシフトしていき、桁があふれたとき "00011101"と排他的論理和をする。
• αの指数n=0 　　"00000001"　（１）10進
• αの指数n=1 　　左シフト ⇒ "00000010"  (2)
• αの指数n=2 　　左シフト ⇒ "00000100" (3)
• αの指数n=7 　　左シフト ⇒ "10000000" (128)
• αの指数n=8 　　左シフト ⇒ "00000000"  XOR "00011101" ⇒　"00011101" (29)
• αの指数n=9 　　左シフト ⇒ "00111010" (58)
• αの指数n=10　　左シフト ⇒ "01110100" (116)
• αの指数n=11　　左シフト ⇒ "11101000" (232)
• αの指数n=12　　左シフト ⇒ "11010000" XOR "00011101" ⇒　"11001101" (205)
• αの指数n=255 のとき "00000001" に戻る
• 生成多項式の係数の演算において掛け算　α^m * αⁿx⁸  ＝　α^(m+n)x⁸  になる。 
• αの指数は255以上にならない。前述の計算で２５５以上になるときは255を減ずる。
• α^{255 =} α⁰  だからだ。 
• 符号化によって生成したデータコード語列をコード語総数-1乗から始まる多項式に当てはめる。これをf(x)としておく。
• たとえば1-H型のデータコード語列  32, 68, 35, 115, 10, 82, 127, 0, 236 があったとすると 1-H型のコード語数総数は 26 なので
• f(x)=32x²⁵ +68x²⁴ + 35x²³ +115x²² +10x²¹ +82x²⁰ +127x¹⁹ +0x¹⁸ +236x¹⁷  
• 誤り訂正コード数に応じて３１の生成多項式が用意されている。これをg(x)とする。
•  1-H型の場合誤り訂正語数は１７である。（総コード数(26)-データコード数(9)=17)
  17語の場合てに生成多項式は
• g(x)=x¹⁷＋α⁴³x¹⁶＋α¹³⁹x¹⁵＋α²⁰⁶x¹⁴＋α⁷⁸x¹³＋α⁴³x¹²＋α²³⁹x¹¹＋α¹²³x¹⁰＋α²⁰⁶x⁹＋α²¹⁴x⁸＋α¹⁴⁷x⁷＋α²⁴x⁶＋α⁹⁹x⁵＋α¹⁵⁰x⁴＋α³⁹x³＋α²⁴³x²＋α¹⁶³x＋α¹³⁶
• f(x)をg(x)で割った余りが誤り訂正コード語列になる。
• でも、多項式同士の割り算の余りの求め方は通常の算術と同様ではなく、以下のようなイメージである。
• 1-H型の場合だとコード語数総数である26個の箱を用意する。箱には番号25番～0番の順にふってある。これらの箱一式を FX と呼ぶことにする。
• 箱の番号はf(x)の多項式のxの指数と同じである。
• 箱の番号25～順にデータコード語を入れていく
• 32, 68, 35, 115, 10, 82, 127, 0, 236 　が25番から17番までに収まる。
• もう一そろい同様に25～0番の番号を振った箱を用意する。これらの箱をGXと呼ぶことにする。
• GX箱には対応するxの指数の場所に生成多項式 g(x)の係数を入れていく。
• 17番～0番まで、1,α⁴³,α¹³⁹,α²⁰⁶,α⁷⁸,α⁴³,α^239,,α¹²³,α²⁰⁶,α²¹⁴,α¹⁴⁷,α²⁴,α⁹⁹,α¹⁵⁰,α³⁹,α²⁴³,α¹⁶³,α¹³⁶
• FX箱の現在値の入っている先頭の箱は25番である。その箱にはいっている値は32でその対応するガロア体の指数は5である。そこでGX箱の先頭の箱番号は１７である。箱の番号を合わせるためにGX箱をそれぞれ６個シフトそれぞれ、αの指数に５を加算する。この箱一式をGX' とする。
• 25番～8番まで、α⁵,α⁴⁸,α¹⁴⁴,α²¹¹,α⁸³,α⁴⁸,α^244,,α¹²⁸,α²¹¹,α²¹⁹,α¹⁵²,α²⁹,α¹⁰⁴,α¹⁵⁵,α⁴⁴,α²⁴⁸,α¹⁶⁸,α¹⁴¹
• これをFX箱と排他論理和をとったものをFX箱に入れる。
• FXの25番の 32 に対し GX' の25番のα⁵は32 だから、その排他的論理和は 0 になる。
• 同様に24番以降の箱も排他的論理和を取る。今FXの24番は68である。GX'の24番はα⁴⁸でこれは70である。これらの排他的論理和は 2 である。 
• 結果FX箱の中は２５番は空となり２４番以降の箱に値が残っている。
• これを繰り返していくとFXの箱は２５番から１７番まで空となる。
• 最後に１６番から０番に残ったものが誤り訂正コード語列である。

やれやれ、これで、誤り訂正コードの算出ができます。
ちなみに、最初ここのプログラミングでちょっとしたミスをしていたのですが、
そうすると、QRイメージをリーダー読み取ると、違う文字に変わってしまったり
しました。結構大変でした。

パソコンの断捨離

最近までメインに使っていたパソコンはたぶん買ってから４年ぐらいになる。
最近は非常に処理が重くなり、立ち上げてから１０分たっても
まともに使えないようになっていた。
ファンも常にフル回転していているようでまるで掃除機のような音がとまらない。

今思えば、何かをインストールするたびに遅くなっていた。
Office をプレインストールの2003から2007に変えたとき、
重くなった。なんか索引キーをひたすら作っているようだった。
とりあえず止めてやった。
VisualStudio。SQLサーバーのサービスが重いのか？。
とりあえず停止した。
SAPの評価版かなにかの無償のベーシス環境。これをインストールすれば
家でもABAPが書ける。（書いてどうする？）
SAPのインストーラーが再びSQLサーバーもインストールしてしまった。
そして、さらに重くなった。
結局重くて何もできぬ。
Norton360。
重かった。しかし止める訳にもいかぬ。
最新版は軽くなったようだが。


それで、すべてを消して、ハードディスクも
パーティションを切り直し、フォーマットし直して

ほぼ買った時の状態、Officeもプレインストール時の2003に戻した。

それからVisualStudioも入れた。SQLサーバーだけはインストールしないことにした。

Nortonは最新版を入れ直した。

電源をいれて１分くらいで普通に使える。

よかった。今後はよけいなものはいれないようにしよう。

というわけで、かなり快適になったはずだった。

しかし、掃除機のような音は止まらない。ファンはあいかわらずフル回転している。

うるさいし、すごく熱いのだ。

そこで、さらに分解掃除に挑むことにした。

QRコードを作るプログラムを作る（4）

QRコードを生成する手順で、

1. 入力テキストの分析と符号化
2. 誤り訂正符号というものを生成する
3. マトリックス（碁盤の目）に符号を並べる
4. マスクなるものをかける
5. 形式と型番を示す情報をつける

「2. 誤り訂正符号というものを生成する」にやってきました。

規格書を読んでみると、

• QRコードには、損傷した場合に復元できる”誤り訂正”能力がある。
• 誤り訂正レベルは以下の４段階から選べる
• レベル L 復元能力７％
• レベル M 復元能力15％
• レベル Q 復元能力25％
• レベル H 復元能力30％

ふむ。そうですか。

そのために、

• データコード後列に付加する一連の誤り訂正コード語を生成するリードソロモン誤り訂正を備えている。

？※△□？　なんだそれ。その後しばらくよく理解できない記述が続いている。

ハクション大魔王じゃないが痒い。

で、結局どうすればいいのさ！というところを読み取っていくと、

まず基本として理解しなければならないのは、こういうことだった。

• 1. 入力テキストの分析と符号化にて符号化された入力テキストを８ビットずつにわけたが、８ビットで１データコード語と呼ぶ。
• QRコードに格納されるデータは、データコード語列とそのデータコードに対して計算された誤り訂正コード語列である。
• 型番と誤り訂正レベルによって、データコード語の数と誤り訂正語の数が決められている。例えば、
• 型番１で誤り訂正レベルLの場合（以下 1 - L のように表記する。）、データコード語は19個で、誤り訂正コード語は７個と規定されている。
• 1- H の場合、データコード語は９個になり、誤り訂正コード語は17個とされている。
• 型番と誤り訂正レベルによって、データコード語列を複数のブロックに分けることになっている。このブロックをRS（リードソロモン）ブロックという。RSブロックごとに、誤り訂正コード語列を算出する。例えば、以下のように決められている。
• １- x であれば、RSブロック数は１である。
• 3 - Q の場合、RSブロック数は２である。３- Qの全ブロックのデータコード語は34個、誤り訂正コード語は36個であるが、各RSブロックのデータコード語は17個、誤り訂正コード語は18個である。
• 5 - H の場合、RSブロック数は４個あり、そのうち２個のRSブロックのデータコード語は11個、誤り訂正コード語は22個、残り２個のRSブロックのデータコード語は12個、誤り訂正コード語は22個。

というわけでプログラムの手順としては

• 使う型番と誤り訂正レベルに応じて、データコード語列をRSブロックに分割する。
• 分割したデータコード語列に対して誤り訂正コード語列を求める。

ということになる。

さて、誤り訂正コード語列を求めるにはどすればいいのか。

規格書にはさらに難解な言葉が、、、

• 規格書より引用
  QRコードの多項式は、２を法とする算術及び100011101を法とする算術（体の原始多項式 x8 + x4 + x3 + x2 + 1の係数を示す100011101を持つ2の8乗のガロア体）を用いて計算する。。。。。。

うーん。高校で数学をちゃんとやっておけば、、、いや、高校でもガロア体なんて言葉聞いたことないとおもうぞ。。。やっぱり理系のひとはこんなのわかるんだろうね。きっと。そもそも私はスペイン文学士だ。ドンキホーテなら全部読んだぞ。えへん。日本語だけど。ぶつぶつ。。。

いや、こんなときはgoogleで検索してみよう。じゃあガロア体とは？

うーん。高校で数学をちゃんとやっておけば、、、いや、高校でもガロア体なんて。。。。

続く。。。

QRコードのデコーダーを買いました。

そうそう、QRコードを作るプログラムはできたので昨日Vectorにて公開しました。

http://www.vector.co.jp/soft/winnt/writing/se492441.html

テストの際に デンソーウェーブさんの iPhone 向けアプリで
 QRdeCODE というのを使わせていただきました。

http://www.denso-wave.com/ja/adcd/QRdeCODE/index.html

AppStore で¥170でした。
私はiPod Touchにて使っています。

たぶん私のだけではないと思いますが、携帯電話のバーコードリーダーは
３型までのQRコードしか読めないようです。
このアプリの場合は、そういう制約はないみたいです。

一番重宝したのは、パソコンの画面上のQRコードも
読めるということです。（携帯もそうだけど）
以前、USB接続のバーコードリーダーを買ったときに、
印刷するのが面倒くさいとおもって、画面から直接読もうとして、
だめでした。
しかし、QRコードのリーダーの場合、全然問題ありません。

あと、このアプリの反応が速いのと、QRの誤り訂正機能の
威力はすごいもんです。
私の手がぷるぷるして、iPodのカメラからQRコードのイメージが
一部はずれていても、もう読み取れてます。
すごい。
一部が欠損していても、復元できるということの
威力を実感しました。
さすが、本家です。

QRコードを作るプログラムを作る（３）

暑い日が続いてますなあ。
あまりに暑いので、半ズボンにTシャツで仕事を
してます。ハワイ気分でプログラミング。
BGMにはハワイのFMをかけたりして。
これこれ
http://www.hawaiian105.com/

さて、QRコードのつづき。
今日は８ビットバイトモードの符号化だ。

これは簡単に言うとASCIIコードというかシフトJISの
文字コードをそのまま使うものである。
いわゆる半角文字などといわれるものです。

よって、単純に　入力データの文字コードを
２進数で表せばよい。

例）　ab12　の場合

1. 文字コードは　61 62 31 32 
2. ２進数では　00111101 00111110 00011111 00100000
3. モード指示子　0100
4. 文字数指示子　00000100 （型番により桁数が違う）
5. 全部つないで
• 0100 00000100 00111101 00111110 00011111 00100000

８ビットバイトモード以上。

次に漢字モードも続けます。
漢字モードの漢字とはシフトJISの２バイト文字コード（１６ビット）を
１３ビットに圧縮するものだ。

文字コードが二つの範囲に分かれる。

• 16進数で　8140〜9FFCまでのグループ
• 8140を引く
• 16進数で　E040〜EBBFまでのグループ
• C140を引く

その後下記のように処理する

• 上記の結果の上位バイトにC０を掛ける
• その結果に下位バイトを足す。
• 13ビットの２進数に変換

規格書の例ですが、　”点”　という文字の場合で要領を示すと

1. 文字コードは　935F
2. 8140 を引く　121F
3. 上位バイト(12)にC0を掛ける　D80
4. 下位バイト(1F)を足す　D9F
5. 13ビットの２進数　0 1101 1001 1111
6. モード指示子は　1000
7. 文字数指示子は8又は10又は12ビットの２進数

というわけで、数字、英数字、８ビットバイトモード、漢字モードと

ここまで順調に符号化すすんだ。

混在モードは以上のモードを切り替えながら符号化するものだ。

モードを切り替えるたびに、モード指示子と文字数指示子が

入るので、やたらめったら、モードを切り替えるべきではない。

その辺の切り替えの指針は規格書にも載っているが、絶対ではない。

私は、だいたい、規格書の指針を参考にやりました。

続く。

くどい

今日も暑い日だった。暑い中、服装はどうあるべきかと考えているときにふと思い出した。

僕は来年で結婚10年になるが、結婚式もちゃんともっともらしくおこなった。
結婚式にむけては特にお嫁さんは衣装合わせがある。何度もある。
そして何度も付き添って通った。衣装に関して、基本的にお嫁さん中心だ。僕の衣装合わせなんか１０分ですんだ。当日の着付けだって１０分ですんだ。
まあ、それでも、それは楽しいことだった。やはりなんでも楽しみなことはわくわくするものだ。
衣装合わせの一環で、カラーコーディネータの方による、似合う色味の診断なるサービスがあり、僕も受けた。僕は、濃い色というかはっきりした色のほうがあうらしいということだった。濃紺とか濃いグレーとか赤とかはっきりしてるのはよくて、黄色とかグレーとか、パステルカラーは似合わないということだった。なんでかというと、顔がくどいからだそうな。
うーん。たしかにそうなんだけど。。。

まあ、いっか。