訂正です。

2009年7月14日火曜日　引っかかっているネタに

InDesign：テキストボックスをぴったりさせる
こいつの記事と連動させて考えたいのが
フォントのバウンディングボックスサイズ_Memo
Proが8.472、Pro5が9.008、Pro6が9.432。
Pro5や6で作成されたデータを「フォントがない！」という理由で裏技で偽のPro5や6に置き換えた後、ボックスをフィットさせると、、、正規環境で開いた場合、BOXからフローして大泣きを見ることになる。モリパスに入っていればフォント使いたい放題なのだが、年貢を納めたくない所はPro5や6をProに置換する。実際、仕事でPro5や6の文字が使用されることは極めて稀なのでこれはこれでアリだと思うが。んで、想定される裏技使用のトラブルとしてOTFの「Pr5」を「Pro」で認識させる（まだ試してない、というか自宅あるのはフリーのものばかり）やり方でピッタリのデータを作成した場合、正規の環境で開いた場合、結果が違ってくる。(；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

なんて推測を堂々とUPしましたが、引用先の「なんでやねんDTP」の大石様からご指摘がありました。

拙ブログ「フォントのバウンディングボックスサイズ_Memo」（http://d.hatena.ne.jp/works014/20090707）
を取り上げていただきありがとうございます。

少々説明不足だったかと反省していますが、あの件は
「イラストレーターにおける整列の基準がバウンディングボックスサイズになっていること」
の一点のみで問題になるものと思っています（テキストエリア内文字ではありません）。
※それも「下」あるいは「全体」を基準にする場合のみかと……

実際にInDesign上で文字列「あいうえお」などを入力したPro書体やPr5書体のテキストフレームと
CID20343（ユニコード0145）を含んだPr6書体テキストフレームそれぞれをフィットさせても20Qなら天地5mmとなります。
※イラストレーターでフィットさせる機能は知りませんが、
　天地5mmのテキストエリアを作成して同様の文字を入力してもオーバーフローとはなりませんでした。

ヾ(_ _*)ﾊﾝｾｲ･･
Quark生活が長かったためか、脊髄反射的に中ゴシック体ピッタリのBOXデータをMゴシックBBBにfont置換したことをイメージしてカキコしました。検証してから書き込まなければアカンのですが、自宅にその環境がないためどうしても仮説の積み重ねになってしました。
にしても、、、InDesignの大御所大石様やあかつき様にこのblogを読まれるとは畏れ多いことです。

で、bloggerのプレビュー画面で校正しようと見てみると

推測が推!に基準が基口になっている。なんでやねん文字化け。

もじもじカフェに参加申し込み

もじもじカフェの第19回「どうする常用漢字」に参加申し込みしました。今度は参加できるでしょう（^^;
2006年の第4回「コンピュータの文字はなぜ化ける？―“ゆるい”技術としての文字コードを考える」に参加したかったのですが、教会スケジュール優先のため涙を飲んで断念した思いがあります。

で、何で今回これに参加しようと思ったのか？　ある意味、教会絡みでもあります。自分の所属している教団は「日本同盟基督教団」。使用している聖書は「日本聖書刊行会」の新改訳です。あとがきにはこう記されています。

原語にあくまでも忠実であり、最もよみやすく、しかも聖書としての品位を失わない訳文を得ることであった。

この聖書を読んでみれば分かると思いますが、原語に忠実にあろうとして日本語がこなれてません。意訳としての口語訳の方がはるかに日本語にこなれています。まぁ、それはいいとしましょう。読んでいてどうしても我慢ならないのは漢字の問題です。

主を恐れることは知恵の初め、聖なる方を知ることは悟りである。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（箴言9章10節）

ここで使用されるべき漢字は「恐れ」でなく「畏れ」です。「恐れ」と「畏れ」では全く意味合いが違ってきます。この箇所だけでなく聖書には「畏れ」という字は使われていません。この件に関して以前、牧師に質問したことがあります。牧師から「当用漢字にこの字がないため」という答えをいただいた記憶があります。

当用漢字になければ使用できないのか？　ちとググってみたところ使用制限の強制力はないようです。実際、「畏れ」という字は多くの人が目にしていると思います。音が同じでも意味が違えば、その字は使うべきではないと思うのです。
Yahoo!辞書でも恐れは「こわがる気持ち。恐怖。不安。」であり、畏れは「敬い、かしこまる気持ち。畏怖(いふ)・畏敬(いけい)の念」です。あと虞という「よくないことが起こるかもしれないという心配。懸念。」がありました。

当日は常用漢字がメインテーマになりますので、「畏れ」の話は出てこないと思いますが、

今回は，常用漢字表見直しの審議を当初からウォッチしてこられたフリーライターの小形克宏さんに，新しい常用漢字表の基本的な考え方や，現在どんな議論が行われているのか，何が問題となっているのかをお伺いし，参加者の皆さんとともに新しい常用漢字表について考えていきたいと思います。

太字部分に大いに期待してます。んで、新名刺を配ってくる予定（もらった人はいらん！と思うけど）。

おもしろいblogを見つけました^^
amiza_retのブログ
カタログe　開発日記　－カタログ制作用DBの開発日記－
Wordでチラシを自動組版は興味深い。DTP業界の選択肢はAdobe以外にもいくらでもあるという強気なユーザー姿勢が必要なのかも知れないと思ったり。

ブラウザによるblog内検索の違い

ちと調べ物があってblog内をCtl+Fで検索してみた（ちなみにブラウザはChrome）。

検索ワードは「パス」。

引っかかったのは「パス」「はず」「はす」。。。
んっ？　これは、、、「ユニコードの正規化」絡みなのか？？？
半角カナの「ﾊﾟｽ」で入力しても同様だ。

で、ブラウザを替えてみる。

Firefoxでは「パス」のみにhitし、半角カナの「ﾊﾟｽ」は見つかりませんでしたと表示される。
SafariはChromeと同じ結果。
で、IE8は「パス」のみにhitするが、半角カナの「ﾊﾟｽ」は中途半端に2箇所hitする。
Googleの検索エンジンは「イラレ」で入力しても「Illustrator」が引っかかるが、Chromeでblog内を検索してもそれはない。

タイミングよくものかのさんがあげていた。

2009/08/14

前回「Googleが検索文字をNFCに正規化している」と書きましたが、これは間違いだと教えてもらいました。

正規化しているのはGoogleではなく、Safariでした。検索フォームに入力すると、いつの間にか正規化するようになっていたんですねえ。一方、ツールバーのGoogle検索に入力すると正規化されずそのままです。

Safariはおそらく、Google検索だけでなく、入力フォームに入力された文字はすべてNFCに正規化して送信しているんだろうなあ〜と思います。（確認できる場所が思いつかないので未確認）

関係がありそうでなさそうで、まだまだ勉強不足。

ちなみに調べ物はアウトライン化してしまったパスを線幅を持ったパスに置き換えるスクリプト。
知っている人がいましたら教えてください<(__)>

気になった文字絡みのネタ

横組み用仮名（hkna）と縦組み用仮名（vkna）は使うべきか

OpenTypeのProフォントには、横組み用仮名（hkna）、縦組み用仮名（vkna）というフィーチャがあり、InDesignでは文字パネルのメニューで「OpenType機能＞横または縦組み用かな」にチェックを入れて利用する。
このフィーチャは、実装にバラツキがある。モリサワ・フォントでは、デフォルト、横組み用、縦組み用の仮名を区別していない。ヒラギノでは、横組み用とデフォルトを区別し、縦組み用とデフォルトの区別はない。小塚書体は三者を区別している。

デフォルト、横組み用、縦組み用の仮名が区別されてると形から書体を判別することが難しくなるなぁ～（Twitter風のつぶやき）

ビットマップ画像を外字登録する方法

なお、このページには記載がありませんが、ビットマップファイルとして作成された画像を外字として登録する方法もあります。外字エディタで外字を登録するコードを指定したあと、

　１　ビットマップの画像編集ソフトを起動
　　　　画像編集ソフトの例としては「ペイント」が便利です。
　　　　「すべてのプログラム」～「アクセサリ」～「ペイント」で起動できます。
　２　画像編集ソフトで登録したいビットマップファイルを開く
　３　画像編集ソフトで「編集」～「すべてを選択」～「コピー」
　４　外字エディタに戻って「編集」～「貼り付け」

の手順により、ビットマップファイルとして作成された画像を、外字として登録することが可能となります。

このデータで入稿はしてほしくないなぁ～

Variable Byte Code と UTF-8、またはUTF-24が存在しないわけ
読んでもよく分かんない。。。

Unicode - JISマークは一文字!
終了したJISマークが出てくると事故の元になるよなぁ～
新JISマークはコチラ

どちらが、正しいローマ字表記？

（平仮名）　→　（訓令式）　→　（ヘボン式）
　きょうと　→　Kyôto　→　Kyoto
　ふじ　　→　Huzi　→　Fuji
　ちしき　→　Tisiki　→　Chishiki
　ほし　　→　Hosi　→　Hoshi
　ほんま　→　Honma　→　Homma
　まっち　→　Matti　→　Matchi

ヘボン（ヘップバーン）式が一般的だが「ほんま」「まっち」は微妙に訓令式を多く見かける希ガス。

モリサワセミナーは濃い

8/7のモリサワセミナーに行ってきました。

■Adobe CS4 便利機能抜粋紹介
■CS4/Acrobat を使った新しいワークフローのご紹介　
アドビシステムズ株式会社　岩本　崇
【InDesign】
・CS3から表スタイル、セルスタイルが使えてる
・信号機でライヴプリフライト
・SWF、XFL書き出しができる
・環境設定で「テキストおよびスプレッドシート～」にチェックを入れると自動更新
・AdobeConnectNowを使った校正の提案
【Acrobat】
・PDFポートフォリオ
　ネイティブファイル、フォルダを登録でき、なおかつ容量が圧縮できる。
　zip、exeはメールサーバのフィルタではじかれる所が多いが、pdfならOK
　（PDFポートフォリオは拡張子がpdfになる）
・アドバンスト→webキャプチャー→PDF作成でFlash再生PDFができる
・オブジェクトインスペクタで画像解像度確認、色情報確認ができる
【Illustrator,Photoshop】
・P型、D型のソフトプルーフにおける色を比較

もう使ってる人、意識を持って調べている人にはどうってことない内容ですが、意識の低い自分にはそれなりに勉強になりました。


で、特筆すべきはモリサワテクニカルカスタマー課の大澤叙夫さんのセミナー内容！

最初にこの方にお会いしたのはCS4が出る前に毎コミでやってたセミナー（今回と同じくAdobe+モリサワ）。
すっげぇー分かりやすくまとめられてました。特にInDesignの単数行コンポーザーと段落コンポーザー。当時アチキは大手印刷会社の下請けの製版会社で責了赤字修正をメインにやっていたこともあり、非常～に勉強になりやした。校正の手間を軽減するために単数行コンポーザーが絶対！のルール下で段落コンポーザーで組んだ赤字修正をする時には、単数行に変えて、送りが変わった所に改行を入れて強制ジャスティファイ。

単数行で組んで入稿してくれよ～！！！

と心の中で叫んでました。しかし、美しい文字組版にこだわれば段落コンポーザーが正解なんやね。そうでなければ「美しい文字組版」とブランド化されたInDesignで組む理由は見つからない（Wordで十分）。

おっと脱線した。
大澤さんのつかみはコイツから
DRYのダブルコーテーションに注目！

続いてNHKのテロップ

この表記についてモリサワさんがNHKに何故文末のダブルコーテーションが下なのかを質問したそうな。。。

NHKさんの

ダブルコーテーションが上だと濁点と誤読される恐れを避けるため

というメール回答を見せてくれた。う～ん、深い。

昔、n-yujiさんが[dtp]ちょんちょんの使い方（使われ方）まとめ。でこの件に触れていたが、UDの見地からNHKはあえて常識を覆したのだな（やるなぁ～NHK）。
で、モリサワさんの見解は

赤丸部分はOKになるようだ。

セミナー内容は「Illustrator vs InDesign文字組版比較」だったが、こいつも面白かった。もっともイラレで文字組みをしようとは思わないが。。。
あと一の字点でひらがなとカタカナの形状の違いを知った。

平仮名を 2 字重ねるとき「ゝ・ゞ」を、片仮名を 2 字重ねるとき「ヽ・ヾ」を使用する。昨今の文章ではあまり用いられない。ただし固有名詞では使われることがある。
学問のすすめ → 学問のすゝめ
いすず → いすゞ

UDを意識した場合

文字は12pt（18Q）以上、行間は本文と同じかそれ以上。

と薦めてました。
ちと級数が大きいかなとも思ったが、なるほどと思ったのが行間。
本文と同じかそれ以上であれば、行を飛ばして読み間違えることはない（実際、自分はこれをよくやる）。

とにかく
モリサワセミナーは騙されたと思っても行く価値あり
です。


※あさうすさんに代わって宣伝しておきます。

メール本文をpdfにする

プリンタが故障のためメールがプリントできない（受信はhotmail）。
で、受信メールをpdfにする方法を調べたら

Gmailのメール本文を１クリックでドキュメントへ変換！

Labs機能を利用するには、表示言語をEnglish(US)にします。普段日本語環境で利用している人は、一度表示言語をEnglish(US)にして、Labs機能をonにしてから、もう一度表示言語を日本語へ戻すと、Labs機能はonのまま利用できます。

表示言語はどこなんだべ？と探したら「設定」にあったのね（^^;
で、hotmailからGmailに転送して1クリックでpdf作成。すっげぇー便利^^

余計な広告がないのが嬉しのココロ^^
あとはいつものように徒歩30秒のセブンイレブンに行きネットプリント。
印刷物もこんな感じの入稿になるのは時間の問題。中小の印刷会社がこのようなシステムを構築できるかだろうな（現実的なのはレンタル）。
で、&#9642;（中黒）は転送による文字化けではなく、hotmail受信時からこの状態。どうして中黒がこうなるのかは勉強不足で分からん。

ついでに
HTMLからPDFに変換するWebサービス
があったのでメモ。でも、ちと重いんだよね。。。

追記：Tumblrまとめ（5月）に
HTML to PDF
URLとメールアドレス入力すればメールにPDFが送られる。
Firefox、IE7,8、Chrome、Safari の拡張機能もあるみたいで、見ているサイトをそのままPDFに変換可能みたい。
があった。読み直してないから忘れてる。。。

やはり13日の金曜日だった

以前の派遣先でもそうだったが、13日の金曜日にでかいミスが発生した。
まして9日は満月。

毎日、出社の際に祈っていたが、やはり起きてしまった。
9日に入稿した物件はインデ2でヒラギノが使用されていた。
ATM Deluxでアクティブにした後、入稿会社のフォントセットが登録されていることに気づき、それに切り替える。通常ならこれで問題は発生しないが、システムが不安定な時もしくはメモリが不足している時は、フォント管理ツールの設定が反映されないことがまれにある。最初にアクティブにしたヒラギノver6.2のままだったのだろう。入稿先のフォントセットはver7.1。

ヒラギノver6.2は今まで仕事で一度たりとも使ったことがない。
ver7.1のデータを6.2で開くとどうなるか・・・アポストロフィーが全て「四角の中の×」に替わってしまった。OS-Xバンドル版はATM Delux登録から外すべきだな。レアなフォントを登録してあるのが事故のもと。

そのショックが尾を引いてか、120線に送るべきものを133線に送ってしまい、
44版再出力。←こっちの方が被害が大きい。

で、今日は今日でEdicolor5の入稿があったのだが、RIPでエラーになる。
原因はダウンロードの設定をしていなかったから。
http://ps.canon-its.jp/ec/support/document.htmlに簡単な出力設定が載っているが不十分。
隣の席の人に聞くとAFMの関係でツメが変わってしまうようだ。怖くて触れんなぁ～。
そんなこともありEdicolor6の体験版とマニュアルをダウンロードしました。

ついでにPDFがフルスクリーンモードになり焦った（^^;A
PDF の表示に関する環境設定を読むとEscキーを押すか、Ctrl+Lなのね。
んっ？　彼が押したショートカットキーをメモったけどCtrl+Fとなってる。。。月曜日に確認しよう。

あとコンストの変更による混乱もあった。なんかもう頭の中ぐちゃぐちゃ。
古い環境からいきなりX環境に入って、毎日ドタバタ。事故起こしては元も子もないと分かりつつもパニックってしまう。もうじき派遣打ち切りになってしまいそう。どうすんべ。

文字化け

マイミクやもさんの日記に

不思議な化け方でリンク切れ。

オホーツク外観.eps　→　オホーツク外冠.eps
なんとかごん.eps　→　なんとかぇん.eps
（化け部分以外は適当です）

孫請けのため先方環境は推測。
Indesign2でパッケージ化、OSX、StuffItでZIP化（BomArchiveHelperかも）
まず解凍方法で化け具合が変わる。WindowsでZIP解凍すると全面的に文字化けファイル名になるためWinじゃない。一番まともな解凍はClassicでStuffIt6.5使った方法だったけど、それが上記化けに。

があがってた。ちとググってみるとCLさんの
StuffItで解凍すると文字化けするzipファイルはBOMArchiveHelperを使ってみろりんにヒットしました。でも3年半前の情報だし、今はどうなっているのか（変化早いからね、この業界）。
BomArchiveHelperを改めて知りました。読み流してたんだなぁCLさんの日記。
おいろんさんが「StuffIt Expander 10」で試します。とコメつけしてたけど、アチキの派遣先に10はなかったような希ガス。。。というか、まだこの手の文字化けには遭遇してないのです。

今日のつぶやき
イラ8にダブルトーン画像をリンクして入稿してこないでね。
RIPするとグレー画像になるんですよ。
ダブルトーンに完全対応しているイラレバージョンはCS3からですから～～。

MacZip4Winで決まり。

「やっぱAppleScriptか」でCleanArchiverよりAppleScriptと書きましたが、Macの手書き説明書に「MacZip4Win」が紹介されていました。
これで決まりですね。年初にでも派遣先にてダウンロードしようと思います。
何よりCleanArchiverにはInDesignパッケージを圧縮するとフォントが0KBにという報告があがってます（コヮ～）

で、どうしても自宅がwin-xpのためかOS-X⇔windows間の文字化けの問題はOS-X⇔windows XPと脊髄反射的に考えてしまうのですが、現状最適な圧縮・解凍ソフトと文字コードにありますようにwindowsでunicodeが採用されたのはNT&2000以降のことです。文字化けが発生するのは98以前のOSです（そんな古いOSいつまでも使わないでくれよ～）。

むしろOS-X⇔xp間ではunicodeの正規化が問題です。
インフォルムさんのOSとファイル名の関係に気をつけように詳しく書かれています。
OS-XはUTF-8(mac)、xpはUTF-16LEです。

UTF-8は8bitの文字列を複数使って文字を表す方式、UTF-16は、16bitの文字列を1個ないし2個使って表す方式です。ちなみに16bitを2個使って表すことをサロゲートペアと言います。

たとえば、「が」という文字を表現することを考えてみましょう。ユニコードでは「が」という文字に「U+304C」という番号が割り当てられています。これはシフトJISなど他の文字コードと同じですが、そのほかに「か」（U+304B）と「゛」（U+3099）を合成することでも「が」を表現できるようになっているのです。この場合、「か」を基底文字、「゛」を結合文字と言います。
ユニコードの正規化形式は4種類あります。1つに合成されている「が」は正規化形式C（NFC）、「か」＋「゛」のように分解されているものを正規化形式D（NFD）と呼んでいます。

Windowsをはじめとする多くのOSでは、ファイル名にNFCが採用されており、濁音や半濁音は1つの合成済みの文字で表されます。ところがMac OS XではNFDが使われているのです。もちろん、このままではファイルのやり取りなどファイル名を他のシステムに受け渡すような場合に困るので、Mac OS XにはNFCに変換する仕組みも用意されていて、問題が起きないように配慮されています。
ところが、それでもアプリケーションによっては問題が発生するのです。たとえば、Mac OS X上でInDesignに画像を貼り込む作業を考えてみましょう。MacOS XはNFDを使うため、画像のファイル名に濁音や半濁音が使われていた場合、基底文字＋濁音や半濁音という形で記述されています。InDesignはリンクとして画像を取り込む際にファイル名を記録しますが、それはこのNFDの形で記録されるわけです。

次に、InDesignファイルと画像ファイルをWindowsに持ってきて開いてみます。WindowsではNFCを使うため、ファイルを移動する際にファイル名の濁音や半濁音は自動的に1文字の形に変換されます。

ところが、InDesignの内部に保持されているファイル名はNFDのままです。そのため、このままだと、濁音や半濁音付きの文字が基底文字＋結合文字の2文字として認識されてしまうのです。しかも、NFDはWindowsでサポートされていないので結合文字の部分は文字化けしてしまいます。

実際、Mac OS X上で画像を貼り込んだInDesignデータをWindowsで開くと、画像のファイル名によっては文字化けし、リンクが切れてしまうというトラブルが起きます。そうなると、あらためてリンクし直すしかありません（ファイル名だけが問題なので再リンクで正しくリンクし直せば大丈夫）。

この問題を解決するには、クロスプラットフォームで作業する場合はファイル名に濁音や半濁音を使わないというルールを守るしかないでしょう。

閑話休題。イヴの日に流星さん、クリスマスの日にキアロさんの足跡がmixiについていた。
どちらもDTP業界では有名な方だけに光栄です。でも、どこから来られたんでしょう？？？

ダブルコーテーションとダブルミニュート

11月18日の日記の下の方に書いたのだが、その後いろいろいじってみるとInDesignの縦組みではダブルコーテーションを入力すると自動的にダブルミニュートに替わる。11/18は入力段階で異体字を指定してしまったため、おかしくなってしまった。派遣の実技テストでテキストを配置した時にダブルコーテーションのままだったので、自動的に替わるとは思わなんだ。あと異体字で切り替えなくても約物の中にあったのね。
縦組みでダブルコーテーションを使用する場合は[6963]縦組みのダブルコーテーションにあるようにCIDコード8277と8278の字形を使用するしかないようだ。
こだわって調べてみると[3509]和文ダブルクオーテーションが引っかかった。

和文の「“」と「”」がおかしくないですか？（ほかにも同じようなのがあるかもしれませんが）キーボードから普通に「“」を打っても、情報パレットをみると半角文字扱いです。なので、デフォルト状態でも「“」の前後に４分アキが入ってしまってなんとも不格好なのですが・・・。
書体はヒラギノ明朝ProW3、OSX10.3.2です。

ちなみに↑は横組みで「行末約物半角」設定なのだろう。「行末約物半角」は和欧間がデフォルトで4分アキに設定されている。Shift-JISの8167、8168はエディタ側で全角でもInDesignではCID108、122の半角のようになる。

注：情報パレットを見ると（OTF:liga）なのだが異体字で選ぶと（OTF:空白）なので「半角のよう」という表現にした。
CID672、673なら全角扱いになるのだが、文字コードを見るとどちらもShift-JIS、UniCode番号が同じ。情報パレットを見るとCID672、673は（OTF:fwid）。fwidは字形パレットでは等幅全角字形とされているが、パレットでは半角になっている。

Study Roomの1.0を終えて2.0にようやく入ったところ。つくづく勉強不足を痛感する。

勉強部屋のStudy Room

口癖になってしまったが、、、今更なのだが「InDesignの勉強部屋のStudy Room」は非常に勉強になる。今まで何やってたんだ、オレ。。。orz
これを熟読すれば書籍を買う必要がないくらい。。。以前の派遣先のようにネットに繋がっていない環境で仕事をしなければならない時には、どうしても書籍を手許において置かざるを得ない。

あともうひとつ感じたのは、InDesignに触っている時間が多ければ多いほど身につく。
以前の派遣先に行く前に体験版を使用したのだが、本を片手にやったもののいまひとつだった（購入した本が良くなかったというのもある）。

もう1台のPCに体験版を入れて2度目の体験版使用しているのだが、前回とは桁違いに身に付いた錯覚に陥っている。赤字修正がメインだったとはいえ、InDesign使用に苦手意識がなくなったといったところだろう。今となっては先週1週間、年齢で案件お断りショックのため立ち直れず、触れなかったのが悔やまれる。CS3をもう少し勉強する上でも、もう1台PCが欲しいくらいだ。できればMacが欲しい。

今度は小竹向原にある印刷会社に決まりそうだ。いや、そこに決まって欲しい。

【今日の学び】
背面オブジェクトの選択
選択ツールを選び【command＋クリック】で背面オブジェクトを選択
エンコーディングはJPEG
InDesignでは、エンコーディング「JPEG」に対応していないRIPでもInDesign側で内部処理するため出力可能

あとダブルミニュート（ちょんちょん）の禁則処理設定に四苦八苦中。
「＂」はCID＝12169、「＂」はCID12170なのだが、Unicode番号がともに「FF02」のため「。」のあと行末にきた始めちょんちょんが、行末・行頭禁止文字になってしまうため、「。」と「。」の前の一文字が次の行に送られてしまう。かといって、Unicode番号（301D）（301F）を使用すると-90度回転をかけなくてはならない。Shift-JISのEE80とEE81がなく、同じUnicode番号（301D、301F）のShift-JISの8780、8781に置き換えられている。現状ではめんどくさいが分離禁止文字としてひとつひとつ設定するしかないのか。。。

半角数字を半角等幅数字に変換

InDesignの仕事でこれが必要になったのでメモ。

せうぞーさんの
二桁数字を半角字形にする

▼正規表現ダイアログはこんな感じ

検索フィールド：(？＜![¥.,])¥b¥d¥d¥b(？![¥.,])

置換フィールド：

置換形式：+字形：等幅半角字形

CS2に対応してたかな？　派遣先にて要確認。

異体字(等幅半角字形)に切り替えるスクリプト

//
// 選択されたテキストフレームや選択されているテキストの英数字等を
// 異体字(等幅半角字形)に切り替えるスクリプト
//
var docObj = app.activeDocument;
var selObj = docObj.selection;

var i, j;

// オブジェクトが選択されている場合
if(selObj.length != 0) {
for(j = 0; j ＜ selObj.length; j++) {
// 属性がテキストのテキストフレームオブジェクト、または任意のオブジェクトの中のテキストを選択している場合
if( (selObj[j] == "[object TextFrame]") ＆＆ (selObj[j].contentType == ContentType.textType) ||
(selObj[j] == "[object Text]") ) {
for(i = 0; i ＜ selObj[j].contents.length; i++) {
// 対象文字が英数字等の場合
if(selObj[j].characters[i].contents.match(/[0-9０-９a-zA-Zａ-ｚＡ-Ｚ¥-¥:]/) != null)
// 対象文字を等幅半角字形に切り替える
selObj[j].characters[i].opentypeFeatures = [["hwid", 1]];
}
}
}
} else alert("テキスト又はテキストフレームを選択して下さい");

注：和文全角の＆？＜＞に置き換えて記述してます。

ダブルミニュート

縦組みのチョンチョン記号のことである（こんなやつ→「〝」「〟」）。
外字のため違う文字コードで表示している。。。

で、こいつを今までShift-JISコード「EE80」「EE81」で入力してきた。
で、下のチョンチョンが行末に来た時、どうしても半角空いて下ツラに揃わない。
（仕方ないなぁ～）でやり過ごしてきた。

先週のこと、「EE81」の下チョンチョンが下ツラに揃っているデータの赤字修正をした。

どうやって揃えていたのだろうか？
暇な時にアレコレいじりながら考えていた。

今日になって昔、読んだBBSをふと思い出した。
Shift-JISの「8780」「8781」は横組みのチョンチョンなのだが、縦組みにすると縦組み用に替わるとあったな。。。Quark4からの仕様らしい。

ビンゴ！

で、ついでにイラ8でもやってみた。同じように替わる！

Quark3.3までは「EE80」「EE81」やけど4からは「8780」「8781」の方が使い勝手が格段にいい^^

文字（番外編）

機種依存文字というものがある。丸数字を使うとwinでは正常に見えてもMacでは文字化けするという類のものである。その中にアラビア数字がある。機種依存文字なのだからwinで見ている限りは同じように表示されるのかと思っていたら、どうもそうでもないらしい。

マイミクさんに機種依存文字をHNを使っている人がいる。win版IE7proでは正常に表示されるのだがwin版Safariでは表示されない。使用されている文字はアラビア数字のIIである。IIが「*」で表示される。
Macの機種依存文字が使われているのかとも思ったがMacがないので確認しようがないが、どうもバグらしい。実際、win版Safariで表示されないページもかなりある。

で、調べているうちに興味を引いたのがこいつ。

文字化け？

「シリーズ名から探す」を見たら、機種のローマ数字が文字化けしてるんですが・・・。（OS X 10.3.9。FireFox）
#いろんなユーザーが見に来るんだから、変な機種依存文字なんて使うなよー。
あ。Safariで見たら、ちゃんと表示された。
なんか納得。(*¨)(*..)(*¨)(*..)うんうん

どうやら、スタイルシートの問題のようです。
font-family: "Lucida Grande";
と指定されているので、Gecko エンジンはうまくフォント置換できずに、ローマ数字のグリフのない書体が選ばれているんでしょう。
Safari は Cocoa なのでちゃんとフォント置換されて、ローマ数字の字形が出るようです。

知恵袋独特の機種依存文字

MacOS9.2.2でIE5.1.7とiCabでは全部正常に表示されています。
知恵袋では以前はこの手の機種依存文字はIE5.1.7でも文字化けしていましたが、昨年秋ごろからだったと思いますが正常に表示されるようになりました。
ただし、これを一般的なホームページで使うとMacOS9.2.2でIE5.1.7では文字化けします。
どうも知恵袋独特の機種依存文字の扱いがあるようですので、知恵袋で表示されてもあなたのホームページでMacで見て正常に表示されるかどうかは別の話になります。

他にもこれ（機種依存文字？）をマックで見るとどう見えますか？

このYahoo!知恵袋では「Unicode」という、比較的新しい文字体系を使用しています。そのため、今まで機種依存文字として扱われていた多くの文字を正しく処理することができます。

機種依存文字をユニコード一覧サイトがありやした。数値文字参照


大文字小文字で思い出したのが、MacのHFSフォーマットで「メロン」と「レモン」が区別されないなんて問題がありやした（懐かしィ～）　で、どんなんだっけ？
葉子と裕子は仲が悪い。
同様に「裕子」と「葉子」

Macのファインダではファイルやフォルダの名前は大文字と小文字を区別をしない仕様になっています。たとえば「aaa」というフォルダと「AAA」というフォルダはおなじ「aaa」と認識されてしまいます。
次に、日本語の場合ですが、漢字は2バイト文字といって二つのアルファベットの組み合わせで表現されています。S‐JISコードでは「裕」は9774、「葉」は9754で、この下半分のASCIIコードではそれぞれT、tに当たります。違いはTの大文字と小文字だけですから、Macのファインダーでは同じ文字と認識されてしまうわけです。日本語の文章をを英語フォントに変換してみると何やら意味のない文字の羅列に見えますが、これが実際にコンピュータが認識している文字で、大文字小文字の違いだけになっていることを確認することができます。

「aaa」フォルダと「AAA」フォルダはwin-XPでも同様に区別されません。裕子と葉子は区別されます。Mac独自のバグ（仕様）だったようです。第8回　HFS、HFS Plusの基本的概念【中編】より

最後にフォントキャッシュを削除するまでがフォントの削除です！

先日、とあるフォントをFont Book.appからインストールしました。少し利用した後、もう必要がなくなったので、Font Book.appから「取り除く」を実行しました。
これで完了だと思っていたのですが、どうも様子が変なのです。OSを起動する度に、ゴミ箱に「Recovered File」（詳しくはコチラ）というフォルダと、その中に消したはずのフォントが復活してきます。「Recovered File」を削除しても全く効果がなく、再度フォントをインストール→「取り除く」を実行してもダメでした。
少々気味が悪かったので調べてみると、消したつもりのフォントは、まだ「フォントキャッシュ」に残っている事が原因のようでした。という訳で、Mac定番のメンテナンスツール「Onyx」の出番です。
Onyxでは、「クリーニング」→「フォント」からフォントキャッシュを削除する事が出来ます。

↑削除したい項目を選択して「実行」すれば、フォントキャッシュが削除される。

この操作後、「Recovered File」に悩む事がなくなりました。という訳で、フォントを完全に削除したい場合は、フォントキャッシュも削除した方が良さそうです。

ファイル名が大文字になる（結末）

ファイル名が大文字になる、ファイル名が大文字になる（つづき）

ファイル名が変わるより、大文字のほうがいいと思って
再度フォーマットしたら、なんかファイル名変わらなくなりました。
FAT３２ってのでフォーマットしたのですが。。。
というわけで、一件落着。ありがとうございました。。。
（というか、お騒がせしました。。。）

んっ？　これって調べたことと矛盾するのでは？と思い、再度、調べました。一覧表がありやした^^
http://www2s.biglobe.ne.jp/~ragnarok/note/pc/win2k/ntfs.htm
ファイル名に利用できる文字はFAT16は英字（大文字）と数字、FAT32は英字（大文字・小文字）と数字みたいです。
USBフラッシュメモリの大半はFAT16でフォーマットされているんですね（^^;A

ファイル名が大文字になる（つづき）

NTFSでUSBメモリをフォーマットすれば、多分OKだと思います。とレスをつけたのだが

ありがとうございます。さっそくフォーマットしてみました。

そしたら半角のままでOKだったのですが、今度は和文名ファイルの和文のところだけ_____と表示されるようになりました。orz

原因はUTF-16LEとUTF-8によるものなのか？？？　いや待てWinの場合、98以前やmeはShift-JISだったはず。ましてFAT32なら和文の文字化けが起きないというのも解せない。
ちと調べたところNTFSフォーマットは読み出しオンリーなのだった。
参照：http://okwave.jp/qa2373654.html
使えないジャン。。。

MAC OSXとwin2000・XPでファイル共有はFAT32（DOSフォーマット）でやるのが今現在ベストみたい。
参照：http://q.hatena.ne.jp/1110261745

大文字に化けたとしてもフリーのRenameソフトで大文字/小文字一括変換をするのが最善の方法なのかな。

調べているうちにOS X の Windows (SMB) 共有でドットファイルを作らせない方法にたどりついた。

pipi さんからのコメント
( Wednesday, September 15, 2004 09:17:39 )

下記の内容をメモ帳で開いて、
ファイル名を付けて、拡張子.batで保存
WINにそのファイルを置く
Wクリックで実行すれば、DOSプロンプトが開いて
ファイルを置いてある階層とその下の、
ドットアンダーバー始まりのファイルと.DS_Storeを削除します。
WINに詳しい人に聞いたところ、
WINではドットアンダーバー始まりのファイルは無いと、
ということで、
全部削除してしまいます(私は使っていますが・・・気持ち不安)。
MACからファイルを持っていく度にWIN側でしないといけませんが・・・
WINのバージョン(NT4.0?)によっては、
-h当たりが通らなかったかと?
プロンプトのヘルプでattribの所、見て下さい。
その際はその部分を削除だったか???

-----------------------------------------------------ここから
@echo off
cls
echo.
echo.中止するときは、CTRL+C
echo.
pause
echo.
echo.アセラズ、まちましょう...
echo.
attrib -r -h ._* /s /d
del ._* /s
echo.
attrib -r -h .DS_Store /s /d
del .DS_Store /s
echo.
echo.終了しました。
echo.
pause
-----------------------------------------------------ここまで

で、Mac OS X（Server）10.3 Panther以降から「HFSX」がサポートされているのを知った。
Mac OS X時代のもう一つのファイルシステム「HFSX」

「HFS Plus」が両者（英大文字／小文字）の違いを識別しつつ、ファイルシステム上ではそれらの違いを吸収し、同一の文字として扱う仕様（case-insensitive）となっているのに対し、「HFSX」ではファイル名における英大文字／小文字を別の文字として認識させる事（case-sensitive）を可能

ここがどうも理解できない。

ファイル名が大文字になる

「印刷製本SNS」でフレンズさんが、

［今さらシリーズ］ファイル名が大文字に。。。

Winで作業したイラレデータをUSBでmacに持っていったら、ファイル名が大文字になるんですけど、どうやったら小文字のままにできるのでしょうか？
たとえば、ファイル名「zu01.ai」が、「ZU01.AI」になってしまうのです。。。
どなたかご存じの方いらっしゃいましたら、教えてください。。。

興味ある事例だったのでググってみたらosXでファイル名が大文字になる

フラッシュメモリはDos形式でフォーマットしてあるんですよね？
この場合大文字になるのは「仕様」です。
HFS拡張でフォーマットしてやって「TransMac」、「Macopener（2007/3発売終了）」などを使ってWindows側で書き込めばいいかと思います。

ほかにもUSB メモリを用いてウインドウズからLinuxにファイルを移動するとファイル名が大文字になる

Windowsとしか書いてないのですが、Window95/98/meなどは、ファイル名の大文字/小文字を区別しておらずいつも大文字で記録されています。ですので、大文字になってもLinuxのせいではありません。NT系(WindowsNT/2000/XP)は確か区別して記録しています。

これってフラッシュメモリをFAT32でフォーマットしたら小文字のままMacで読めるかな？（←無知！）と思ってググったらFAT32ディスクをファイル名が大文字にならないように共有に

共有はできましたが、Win側（XP）につないでディスク内にファイルを保存すると、前期の共有環境で接続して見るとファイル名の英語小文字がなぜか大文字に!!!
なんとなく嫌なので色々やってみました。
Win側（XP）につなぎ、「ポータブルメディアデバイスとして開く」で開いて小文字のファイルをコピー -- ×（共有環境から見るとファイル名が大文字に）
Win側（XP）につなぎ、外部ディスクのファイル共有をオンにしてネットワーク経由でファイルを保存 -- ○（共有環境から見てもOK）

USBフラッシュメモリをNTFSでフォーマットなら別途ソフトを購入しなくてもWin XP⇔Mac OS-Xのスムーズなファイルの受け渡しができるのではと調べてみました^^

USBフラッシュメモリをUSBポートに挿す

マイコンピュータをダブルクリックして、表示されたドライブの中からリムーバブルディスクを右クリックしてプロパティを開く
続いてリムーバブルディスクのプロパティウィンドウが表示されたら、USB FLASH DISK DRIVE を選択する
プロパティをクリックする
 
ポリシータブをクリックして「パフォーマンスのために最適化する」を選択する
 
この時、再起動が必要となる場合もあるので、その場合は再起動する

ふたたびマイコンピュータをダブルクリックして開き、リムーバブルディスクを右クリックしてプロパティを開き、フォーマットを選ぶとフォーマット形式にNTFSを選択できるようになるので、フォーマットを進める

Tumblrまとめ（4/1-10）でNTFS、FAT、および FAT32 をメモっていたが、ファイルシステムについての突っ込んだ解説はやはりwikiになってしまう。
ファイルシステムの下の方の「機能」の表の中に「大文字/小文字区別」と「大文字/小文字保護」があるがMacのHFS+との互換は問題なくできそうだ。

現状最適な圧縮・解凍ソフトと文字コード

Stuffit のトラブルの最後にCLさんのレポートを紹介していたのですが、
コメント欄に

実はStuffItも万能ではありませんです。
アーカイブ内にUnicode合成文字を使用したファイルが含まれているとWin版StuffItで解凍しても化けます。
MacOS「がぎぐげご.rtf」（アーカイブ内）
↓
WinXP「か・き・く・け・こ・.rtf」（濁点部分が文字化け）
このままですと不正なファイル名になってしまいアプリケーションで開くこともできません。

だったら何が一番データの受け渡しがスムーズなのか？　気になったのが

id:FeZn インストールが許されるならExpLZHでいいと思います。

それとZIPファイルをFinderで解凍すると文字化けしてしまう。の追記で紹介されていたDropLHaがベターな解かな（まだ使ってないから）。
過去ログ：ツール紹介 でCleanArchiverを紹介したけどMacならこれがベストな選択かも（同様にまだ使ってない）。
WindowsDTPレポートも再度、目を通しておきたい。

Windowsで文字化けしないzipを作るAppleScriptがあります（過去ログ：2007年9月12日）が、まずは上記3点を試してからでしょう。


文字コード絡みで不具合の原因は「カタカナでなく漢字だったから」――三菱東京UFJのシステム障害の件を詳しく解説しているblogがありました。

コンピューターで文字を扱うことについて(１）

　例を出すと、１0進数での「25」が2進数では「11001」と表現されるのですが、2進数では5桁になってますね。
　電球のたとえ出すと、電球が5個ある状態で、この状態は左から2番目までが点灯してて、3番目、4番目は消灯してて、5番目は点灯してる状態です。
　この場合、一番左の電球は「１６」を示してます。その次の電球は「８」を示してまして、3番目と4番目は０を示してて、5番目は「１」を示してます。それを足し算すると、１６＋８＋０＋０＋１＝２５となるわけです。
　じゃあ、「11111」はいくらかというと、16+8+4+2+1=31となります。要するに1桁目に１がつけば「1」で、次の桁に１がつけば「2」で･･･というように、桁が進むごとに２が掛けられる形になります。コンピューターはこうやって数を判断するわけです。

コンピューターで文字を扱うことについて(２）

　この、JIS X　0201は俗にANKコードと呼ばれてました。アルファベット、文字、カナが使えるということで。
　ここで使うカナは俗に「半角カナ」と呼ばれます。

（中略）

　メインフレームはEBCDICの各社拡張文字コードという状態ですが、一方、UnixはUnixで、独自の文字コードを持ってました。それはEUCコードというものです。

　EUCコードは当然日本語対応版もあり、それはEUC-JPというものです。この文字コードの特徴は、ASCII、ANKコード、JISコードを包括した作りで、それぞれの互換性が比較的高いというものでした。

コンピューターで文字を扱うことについて(3）

　で、このUnicodeは、NT系のWindows(WinNT、Win2000、WinXP、Vista)、Linux、Mac OS Xの内部コードで使われ、そして、Javaの内部コードとしても使われてます。

　Unicode2.0以降は、文字コードを今度は21ビットで対応するようになりました。そうすると･･･2,097,152パターンの文字に対応できるようになります。さらに、Unicodeは21ビットですが、既存のOSは16ビットだったり32ビットだったりするわけです。Vistaは64ビット版もあるわけですが。そこで、Unicodeをそれらに対応して変換する処理が必要になります。その処理を「エンコード」といいますが、エンコードにしても色んな種類が出てきてます。UTF-８とかUTF-16とかUTF-32とか。
　で、使い勝手がいいと言われるUnicodeも、それなりに問題が出てきます。

　まずは、バージョンごとに互換性がないということ。

Shift-JISコードの調べ方

以前、おまけのPerl Script　2点 でShift-JISコードを調べるScriptを作成したのですが、別な方法を見つけたのでメモというかこっちが簡単（^^;

漢字Shift-JIS Code Tableにアクセス。

Ctrl+Fで検索ウインドウに調べたい文字を入力。
 
最後の数値は左から順に0～9、A-Fになります。
ですから「結」のShift-JISコードは「8Ｃ8Ｂ」ですね。

5/25追記：http://tagnoheya.com/charlist/index.htmlの検索機能の方がGood!

Stuffit のトラブル

STUFFIT DELUXE 12のレポートを読んで思い出したのが、マイミクあかねさんのレポート。まだmixiに入ってない人は入ってチョ^^

要約するとStuffIt Expanderのver8でzipファイルを解凍すると、Macのリソースがすべて落っこちてしまう。しかし、最新のバージョンv12ではこの現象はおきない。v10でも起きなかったという。

なんでこのレポートがあがったのかというとIllustratorでプレビューのない（Macのリソースが落ちた）画像に「効果」メニューから「スタイライズ　ぼかし」の処理をした時、出力した画像が抜けてしまう現象が起きたという。多分、ほかの効果メニューを適用しても落ちると思う。（正確にいうと、出力されないというよりは、何もない画像に効果を適用したものが出力されるので見えない、のだと思う）と分析されている。

StuffIt の人気URLはCLさんのレポートばかり

2005.12.09
StuffItバージョン間差異
StuffIt 5.5J のアーカイブや StuffIt 9.01J のアーカイブが StuffIt 7.03J で解凍できなかったりできても壊れていたりするのですが

2006.02.20
旧sitをOSXネイティブのStuffItで解凍すると時刻が+9される件
表題の件は、
あかつき@PocketDTP 【StuffIt Expander】一部バージョンで解凍時にタイムスタンプが変更される にて（元ネタ書いたの僕なんで）。

2005.04.28
だれだMacのZip圧縮でMacZipすすめているのは
Windows でダウンロードできないのはやめて欲しいとおもいました。
ワンポイント：他の ZIP 解凍ソフトで解凍すると、リソースフォークを「XtraStuf.mac」に吐き出すものがそいつです。

2005.04.12
StuffItで解凍すると文字化けするzipファイルはBOMArchiveHelperを使ってみろりん
僕は StuffIt はあまり信用していません。

7.0J の時の日本語ファイル名処理のエンバグとか、それを直した 7.03J でも自己解凍形式に関しては直っていなかったりしていますし、バージョンアップのたびに日本語処理まわりで必ず問題を起こしてくれています。結果、印刷屋さん側では様々な StuffIt のバージョンを用意しています。これはものずごくあほくさい。上位互換でない場合もあります（7Jだと解凍できないけど5.5Jだと解凍可とか）。

印刷屋さんとして通信入稿の比率が高くなってくるといろんな形式が対応できる解凍ソフトが便利なわけで、必然 StuffIt が選ばれるわけですが、たまに、Mac OS X の「アーカイブの作成」で作った zip ファイルを解凍すると、文字化けするものがあります。この解凍ソフト、ダメだ。

で、よく調べると、どうも zip ファイルの方に原因があるらしいです、Windows で解凍しても同じ化け方なので。

9時間ズレる原因は5/7の記事のアレね。


・・・っと、夜になってRSSにCLさんの
Linuxで作ったtgzをWindowsの+Lhaca、StuffItで解凍してみるが上がっていた。
要約するとLinux側でtgz圧縮、そいつを+Lhacaデラックス版で解凍するとファイル名が化け化けになるというもの。原因はLinux側がファイルシステムがUTF-8なのにWin側のファイルシステムはUTF-8でないからだという。WinはUTF-16LEだしね（2007.07.16日記関連：シフトJIS と unicode ）
Windows版StuffItで解凍すると文字化けしないそうです。
OS-Xならばイケッチさんの名解で解決できます。