Doodle Page : 個人的な落書き

お隣ならいつものことですね、という感想しか出てきませんが、昨年夏に引き続き、韓国ではまた大腸菌騒ぎが…。 相変わらず日本の報道機関は無視を決め込んでいる様子ですが、今回は在大韓民国日本国大使館がWebページでの注意を呼びかけています。でもマスメディアで報道されなければ、Webのニュースをチェックしている人でないとなかなか気づかないのでは。実際、在大韓民国日本国大使館の告知は7月24日なのに、私がWebのニュースに気づいたのは7月30日であり、約1週間遅れ（韓国や中国サイトの7月18日、19日の報道からならば、約2週間遅れ）。その間メディアは一切報道していなかったのでは？韓国汚染された日本のメディアは酷いですね。

それ以上に韓国の海産物の輸入禁止をするべきだと思うのですが。各国はちゃんとそうしているのにナゼ日本はしないのか疑問でなりません。不衛生な物を輸入し続けなければならない義理なんてないはずなのに。スーパーで韓国産海苔使用と書かれたおにぎりや、韓国直輸入と書かれたキムチが何事もないかのように販売されているのは異常です。

• 食中毒にご注意ください。 (在大韓民国日本国大使館 公報文化院 2013-07-24；Web Archive)
• http://yukan-news.ameba.jp/20130728-194/ (アメーバニュース 2013-07-28；Web Archive)
• 有名レストランやスーパーの冷麺やのり巻きから大腸菌を検出=韓国 (サーチナ 2013-07-18)
• Bacteria found in popular restaurants (Korea Times 2013-07-19)
• 不衛生 韓国情報 (韓国情報)

以前、Real Player10でWMVファイルを再生すると、タイムスタンプが書き換えられてしまうことを書いたのですが、Windows Media Playerでも類似問題があることを見つけました。Windows Media PlayerでWMAやMP3ファイルを再生した際にもタイムスタンプが書き換えられてしまうことに気づきました。途中で再生を止めてプレーヤーを終了させた場合は変化しませんが、全部再生し終えるとタイムスタンプが変化します（WMAおよびMP3でも、なぜか変化しないファイルもあります）。ちょっと困りモノ。なおWAVやWMVファイルの場合は問題ない様子。

なお、利用している幾つかのプレーヤー（Lilith, GOM Player, Media Player Classic, RealPlayer 14, QuickTime Player 7.7.3）で試した範囲では、取り合えず問題は起こらない様子。

東京電力の電気料金プランが、2013年5月に4つ追加されたとの案内リーフレット※が5月分の領収書とともに届けられました。東京電力管轄の地域の方なら、リーフレットをご覧になっていると思います。

原発事故後の料金値上げだとかいろいろ不満はありますが、今更それを愚痴っていても仕方がないので、新たに提示された料金プラン（朝得プラン／夜得プラン／半日お得プラン／土日お得プラン）が月々の支払いにどの程度影響するのか検討してみました。

私の自宅の場合は、試算によれば、半日お得プランか、土日お得プランあたりを選択すると毎月800〜1600円程度は料金が下げられそうに思えます。そんなわけで、電力メーターを切り替えて貰う手間は掛かりますが、切り替えてみようかなぁ…と思いつつ、日々の雑用にかまけて問合せを保留中。

ちなみに、従来から夜間利用向けのプランとして、おとくなナイト8・10もありましたが、これは夜間蓄熱式機器を使用していない家庭ではむしろ割高になるため、選ぶ家庭は少なかったハズです（少なくとも私は10年位前に試算した場合も割に合わないと判断しましたし、東京電力側もそのような判断をしていました）。今回の4プランの場合は、適切に選べば割と多くの家庭で料金を下げる効果があると思えます。

なお、試算は個人的に作成したExcelシートで実施しました。というのもパンフレットなどで案内されている東京電力のWebページ「でんき家計簿」でも試算ができるのですが、例えば昼間と夜間の電力使用量の比率を設定できないからです。各家庭の時間帯の実情に合わない比率でプラン判定されても意味がありませんよね。

作成したExcelファイルは、Toolsページ：東京電力 電気料金プラン選択試算に置いておきます。

ふと思い立って素数を時計の文字盤の順番に並べてみたら、文字盤の0〜11（または1〜12）に満遍なく並ぶわけではなく、1,5,7,11に集中して並ぶことに気づきました。文字盤上に並べるのは12の剰余（＝12で割った余り）を求めているのと同じことなので、Nの剰余として幾つかのNで試してみました。どうやらNが偶数だと特定の数に集中し、奇数だとバラける様子。ともかく、例えば「ある数の12の剰余が1,5,7,11のいずれかならば素数の可能性がある」と言い換えることができるわけですね。素数には、ウラムの螺旋のようなある種の特徴があるので、この剰余にも何らかの規則性があっても不思議ではないのでしょうけど、今まで考えたこともなかったことなので単純に驚きました。

以下に示す図は順番に、(0) 時計ならびに並べた例、(1) 1〜999の範囲にある素数に対する4の剰余、(2) 12の剰余、(3) 20の剰余を順番に並べてプロットしたもの、(4) 12の剰余を円形に並べてプロットしたもの；(2)を円状に並べたことに相当、(5) 剰余1,2,3,5,7,11の順番に素数を昇順で並べたものを円形に並べてプロットしたもの、(6) 剰余13のプロット、(7) 剰余23のプロットです。クリックで元のサイズが表示されます。

先日、近所のドラッグストアで天然酵母を謳うパンを購入したら、天然酵母を使っていて（かつ独自の製法で焼き上げたため）ロングライフである風なことが書いてありました（例：ぐるぐるデニッシュの写真を参照のこと）。今思い出してみれば20年近く前にもパネトーネ種を使っていてロングライフ的なことが書かれた別業者のパンを買ったこともあります（その製品は「天然酵母」とは書かず「パネトーネ種」を前面に出していたと記憶していますが）。

「天然酵母」だと、どうしてロングライフなの？と疑問に思って検索してみると、ほとんど業者の宣伝文句か、クチコミレベルで「確固たる根拠なくイーストでないからロングライフ」風なことしか見つかりません。

1つだけ見つけた、天然酵母表示問題に関する見解（PDF；社団法人 日本パン技術研究所　平成19年1月9日）によれば、いわゆる「天然酵母」がロングライフをもたらす根拠はない、油脂が多いことがロングライフの理由、一般のパン製造に使われるパン種＝イーストも「天然の酵母｣であることには間違いなく（海外では普通にNatural Yeastと表記）、イースト以外を「天然酵母」と表記するのは不適切、イーストという表記自体が人造的な印象を与えているというようなことが記されていました。

改めて購入したパンを見たら、上記文書では最もイーストと差が見られないと指摘されている発芽玄米酵母が使われ、且つ袋にはアルコール系品質保持剤が封入され、且つ油脂も多めという状況でした。また「デイプラスの天然酵母パン」という用語が商標登録済みだということ。「天然酵母」がロングライフの理由ではなく、例えばアルコール系品質保持剤を封入した、（天然酵母などを謳わない普通の）油脂たっぷりのバームクーヘンやケーキ類には賞味期限が長いものが多いのと同じ理屈で、長期保存たらしめている要因は製造時の衛生管理と品質保持剤と包装と油脂だと思います。単なるセールストークですよね、コレ。

天然酵母をセールス文句に使うパン業者が多々あり、その表示が消費者を惑わす、ある意味騙しに近いという指摘がありながら正常化されていないのはいかがなものかとふと思いましたが、「天然酵母」を含む用語を商標にしてしまっている例まであって、改善されることはなさそう。マイナスイオンなどと同様にエセ科学が蔓延しているのはどうにかならないものかと思います。

大手パンメーカーのような販路・売上げが期待できないため、廃棄を減らすために品質保持剤などで長期保存できるようにする必要があり、且つそれだけではキャッチフレーズがないから「天然酵母」でロングライフという根拠に乏しい宣伝下文句をでっち上げているのでは？と邪推してしまいます。ロングライフと謳う文面も曖昧さがあるので、消費者には都合の良い方向で誤解をもたらしつつ、「嘘は書いてない」と言い逃れできるようにしている気がします。

『定刻発車 〜日本の鉄道はなぜ世界で最も正確なのか？』三戸祐子著を数日前から読み始めましたが、なかなか面白いです。ほとんど遅れなく正確に運行される日本の鉄道が、良い意味でも悪い意味でも海外から驚かれる理由の背景を、さまざまな切り口から解き明かしていく本です。その中で時鐘の歴史、宿場の距離といった歴史的背景、地理的条件・制約などの事例が語られ、本題に留まらない事実を知る上でとても参考になると思います。お薦め！

FAXに関して。受信したFAXを直接印刷するだけのFAX機の場合、用紙サイズの異なる用紙を混在して送信してきた場合を別にすれば、あまりトラブルを聞きません。でも、受信内容を画像に変換する場合には、時々問題が起こる様子。FAX受信ソフトウェアや、受信FAXデータをメールや画像として出力するFAX機や複合機にて、送信元のFAXの送信の仕方（送信フォーマットや、紙原稿を読み取らせたものか、PCデータを直接FAX送信したものかなど）によって、受信側FAXで画像化すると、稀に縦横比のおかしなデータが生成される場合があります。私の経験では、本来A4縦の原稿なのに縦方向の情報が半分欠落した横長画像になる例があります。また、Web掲示板でFAX機やFAX複合機で画像生成する場合に、特定の送信元からの（特定の操作による）FAXで類似現象が発生するようです。

その場合でも画像をデータにせず印刷する場合は縦横比の狂いなく印刷される様子です。しかし画像データにした際に比率がおかしくなるFAXの場合には、印刷における縦横比は正しくとも、文字や線がギザギザしていたりして汚い結果となります。

これはFAX規格の仕様上の問題なのか、はたまた仕様の解釈に曖昧な点があって製品として実装された際にブレが出てしまうのか、よく分かりませんが、複数のソフトウェア、ハードウェア（複合機としてはhp、EPSON、RICOHなどの製品）で実際に起こっている現象です。またインターネットでのFAXサービスでも同様の問題が発生するようで、サービス提供者のFAQに記されていたり（例：Faximo：FAX受信について）、不具合の発生するFAXがある旨の利用者によるblog（例：D-FAXで表示の縦横比がおかしい事例＝Windows Vistaでファックス受信tif画像を印刷する）が散見されたりします。

なお、画像として出力されたFAXデータの比率がおかしく表示される場合は、表示するソフトウェアを変更することにより、比率だけは正しくできる可能性があります。FAX画像を生成した過程にもよるので、「常に何某のソフトウェアで表示すれば縦横比が正しくなる」と指南することはできないのですが。

以下は、間違った比率になる再現性のある送信元のFAX（中解像度：100×200dpi）を利用して調べた状況です。今回はCITI BANKのFAXサービスデータを利用（以前もメンテ中(?)などの際に稀に比率がおかしいことがあったものの通常は正常比率。しかし2012年12月上旬からシステム変更がされた結果、常におかしな比率となってしまっています）。

A) EasyFax

AI SOFTの「EasyFax 2000」（既に販売終了）にて、受信されたFAX画像のプレビュー画面では正常に表示されますし、EasyFaxから直接印刷した場合は正しい比率で印刷されます。しかし、プレビュー画像上で範囲選択して他のソフトウェアに貼り付けると縦の縮んだ画像となります。また、連携ソフトウェアである「読んde!!ココ ver.9」へ転送する場合も、縦が縮んだ画像として表示されてしまいます。読んde!!ココ ver.9でその画像を保存すると縦が縮んだ画像のまま出力され、（「IrfanView」や「GV」や「PhotoImpact」やWindowsの「ペイント」など）いずれの画像ビューワーで表示しても縦横比は正しくなりません。

B) Officejet Pro 8500 wireless

hp Officejet Pro 8500 wirelessで受信した場合、印刷すると正しい比率となりますが、SEND To フォルダやSEND To メールによってTIFF画像とした場合には、表示するソフトウェアによって縦横比がおかしかったり正しかったりします。

B-1) PhotoImpact 5, Photoimpact 8, ペイント

Ulead（現Corel）「PhotoImpact 5」、「同8」やWindowsの「ペイント（= Paint）」では正常比率で見られません。それらで縦だけ2倍に拡大すれば正常比率になります。

B-2) Microsoft Office Document Imaging

「Microsoft Office Document Imaging」では正常比率で表示できますが、それをTIFFで保存し直すと元ファイルとは異なるデータ内容となるものの、先の正しく表示できないソフトウェアでは同じくダメな結果となります。

B-3) Windows画像とFAXビューア

Windows画像とFAXビューア（= Windows Picture and FAX Viewer）では正しい比率で表示できますが、それをTIFF／BMP／JPGのいずれの形式で保存しても読んde!!ココ ver.9で開くと縦横比の間違った状態となります（IrfanViewでもダメ）。

B-4) IrfanView

「IrfanView」では正しい比率で表示されますが、それをTIFFのまま保存すると、読んde!!ココ ver.9で開いた場合、比率は正しいのに真っ白画像となります。BMP保存の場合は正常表示。

調査状況を簡単にまとめると、FAX機（またはFAXモデム類）が中解像度（100×200dpi）で送信してくる場合、受信側FAX機（またはFAXソフトウェア）はその解像度を正しく認識しており、印刷操作では正常な比率で出力をする。しかし、その送信データになにか特有の「癖」がある場合には、縦横比の間違った比率で画像化してしまう（おそらく100×200dpiの正方でない解像度を補正しないまま画像化してしまう）ということ。

もしかしたら、TIFF-F（資料：TIFF-F(Tagged Image File Format-Class F) および The TIFF-F File Format）の仕様の何処かに混乱を招く要素があったり、実装者（特に画像を表示する側の実装者；上記例では「読んde!!ココ ver.9」や「PhotoImpact 5」「同8」）が正しく理解していなかったりするのか、それら製品の発売後にTIFF-Fの仕様が確定したなどの理由があったのかもしれません（ちなみに、EasyFax 2000はその名の通り1999年発売、読んde!!ココ ver.9は2003年発売、PhotoImpact 8は2002年発売、TIFF-Fに関与しているAldusは2005年にAdobeに吸収されて消滅。しかし、TIFF Class F Specificationを読む限り1990年には既にTIFF-Fが決定ではないものの議論されていた様子）。

対処法としては、画像ファイルとして得られたFAXデータが正しくない比率で表示された場合は、「IrfanView」や「Microsoft Office Document Imaging」や「Windows画像とFAXビューア」などで表示してみる。更に、どのソフトウェアでも正しい比率にしたい場合は、IrfanViewでBMP保存したり、画像レタッチソフトウェア（ペイント、Photoshop、Paintshop、PhotoImpact、GIMPなど）で縦方向を2倍に拡大してBMPやJPEGなどで保存し直す、ことになります。