InDesignのドキュメントを保存しようとして、エラーメッセージに阻まれていらっとした経験はありませんか？　私はあります。
最近のものでは、

「新しい名前で“ファイル名.indd”を保存することができません。
　ファイル“ファイル名.indd”には障害があります（エラーコード：1）。」

というメッセージが出て、目的のフォルダへの別名保存ができませんでした。

これ、まるでInDesignのドキュメントか、そうでなければInDesign自体が壊れたんじゃないか、と思ってしまいますよね。
でも、そうでない可能性も否定できないんです。

InDesignを保存するフォルダの名前に、日本語を使っていませんか？
私の環境では、使っています。
このとき、ある漢字と文字との組み合わせが問題となり、InDesignがファイルパスを見失うのではないかと思っております。
たとえば、私の環境では「隆」の文字。この文字単独でフォルダ名を付けた場合、特に不具合は再現しませんでした。しかし、複数の文字の中に「隆」が含まれていると……。
稀に、上記のエラーコード（必ず1だとは限らず、数字が違えば当然ながらエラーメッセージも違う）が出て、やはりInDesignの保存ができないという事態が発生することがありました。

しかし、フォルダ名を1バイト文字に限定することで……、もっと言えば、他の日本語の文字列はそのまま、「隆」の文字を削除するだけでも、あっさりと保存できるようになったのです。
サーバーではありません。ローカルフォルダへの保存の際に起きた現象です。

過去、ＤＴＰ掲示板には一定の頻度で、ファイルが壊れた旨の書き込みが見られました。
それらの問題のうちいくつかも、もしかしたらフォルダ名に原因があったのかもしれません。

ファイル管理をするのに、日本語ファイル名・フォルダ名を使わずに済ますのはなかなか難しいでしょう。
伝統的に日本語ファイル名を使ってきている方は少なくないでしょうから。
しかし、不具合が起きた際には、手間のかかる作り直しや再インストールを試す前に、まずファイル名・フォルダ名をチェックしてみてはいかがでしょうか。
そしてできれば、なるべく1バイト文字でファイル名・フォルダ名を管理する方向にシフトしていければ、無用なトラブルが減るんじゃないかな、などと思っています。

Edicolor10をさわる機会に恵まれたのでちょっと実験してみました。
環境：MacOSX 10.6.8／Edicolor 10.0.0
環境：Windows7／Edicolor 10.0.0

Edicolorといえば強力なタグテキスト機能！
私はEdicolorのVer.6しか知らないのですが、Ver.10のマニュアルを読むと従来のEdicolorタグの他にXMLタグでの入出力にも対応したようです。
しかもそれぞれ、SJISとUTF-8の選択が対応。

Edicolorのドキュメント上で入力した文字列を選択オブジェクトのみタグテキスト書き出しし、エディタ上で特に編集することなく再配置してみました。
結果としては全滅。
EdicolorタグのSJIS・UTF-8
XMLタグのSJIS・UTF-8

いずれも、ただ書き出しただけのタグを再配置するわけで、Edigaijiを使ってはいるものの特に複雑なことをしていないので、書き出す前の選択オブジェクトと全く同じものが再配置されるであろうことを期待したわけです。
ですが、いずれを配置しようとしても強制終了となってしまいました。

ところが、同じことをWindows7マシンで試したら、期待通りすべて選択オブジェクトと同じものが配置される結果となりました。
Mac／Win各1台ずつにおける実験なので、マシン固有の不具合の可能性は否定できません。

おいおい、もっと詳しく検証していこうと思います。

CS4での話題です。
Mac OSX 10.6.8 / InDesign CS4 ver.6.0.6

異体字入力には複数の方法がありますが、今回は「最近使用した字形」に残っていた、という前提で、図中の青丸に示す部分をダブルクリックして入力したものとします。


いま入力した文字を選択し、字形パネルのパネルメニューを開いてみました。
おや？　標準字形ですと？　……まさかね（笑）


いま入力した文字を選択し、新規に段落スタイルを作ってみました。
ありゃ。やっぱり標準字形になってる。これでは、このスタイルを利用して新たにドキュメント上にテキストを配置しても標準字形になってしまいますね。実際にそうなりました。
……せっかく手軽にスタイルを作ったというのに、スタイル編集の手間が減らないじゃないですか。Oh, なんてこったい。


ちなみに、同じ事をCS5.5で試してみました。
CS5.5においては、履歴入力したものもきちんと等幅半角として認識してくれましたので、手軽にスタイル登録できました（笑）

これはCS4のバグ……というか、想定外の使い方だったということで機能の実装不足だった、ということになるのでしょうか。
いずれにせよ、CS4でこのような形でスタイル登録する場合には要注意、ということで。

---

【追記１】（2012/06/08）
コメント欄でご報告をいただきました。
どうやら、環境による不具合（？）のようですね。
Mac OSX 10.5.8 / InDesign CS4 ver.6.0.6
の環境では無事とのことでした。

---

【追記２】（2012/06/08）
新情報いただきました。
「OSX 10.7.3上では同様の症状を確認…というかパネルの等幅半角字形をダブルクリックしてもサブメニューにチェックはつかない=スタイルを生成してもダメ…サブメニューから等幅半角字形を適用したモノはOK=スタイルを生成してもOK…10.5.8ではダブルクリックでもチェックONになるのでOK」
やっぱりCS4（以下？）使用時は要注意、ということで。

---

【追記３】（2012/06/09）
履歴入力に限らず、異体字パネル上での字形変更においても現象は再現します。
OSXの特定のバージョン下において、CS4の場合は異体字パネルで明示的に異体字のチェックを（サブメニューから等幅半角字形を適用するなどの方法で）してやらないとスタイル属性として記録されないということになりますね。
なお、CS5.5ではどの環境でもバグ報告がないとのことです。
CS4使用時の消極的な対症療法としては、キーボードショートカットに登録し、入力した文字をキーボードショートカットで変更するなどの方法が有効かと思います。

職場の共有パソコンで、最新のInDesign CS6に触る機会を得ました。
共有パソコン：Windows7 sp1
　　　　　　　Adobe InDesign CS6 ver.8.0

キャプチャ画像は昼休みに自宅にメールしました（笑）
何か変わってるかなーと思ってよく見たところ、私にとって見慣れたOSでないためにダイアログの外観がちょっと違うだけのことに過ぎませんでした……



検証記事を書こうと思って触ったわけですが、ほとんど触るだけで終わってしまいました。
手持ちのスクリプトのうち、動く物・動かない物を少しだけ選別。
やっぱり、オブジェクトモデル細かいところが変わってるっぽい。
今度時間ができたらESTKも触ってみます。

Mac OS X v10.6.8／Illustrator CS4 にて。

全行同じタブ設定なのですが、2行目のタブの後の文字「国」が少し下がっているのがおわかりでしょうか。

---

実はタブの直前の文字列について、他の行と字割を揃えるためにトラッキングが設定してありました。
（ちなみに、トラッキングはタブ以降の文字列にはかかっていません）

---

タブ直前の文字だけを選択してトラッキングを解除すると、上図の通り。

---

InDesignであればタブ直前の文字にトラッキングがかかっていてもタブ直後の揃え位置に影響が出ることはありません。
これはIllustrator固有の仕様（不具合？）のようです。

こんばんは。
ご無沙汰しております。
環境が大きく変わりまして、会社ではすっかりMacと戯れて格闘しております。

右クリックのできるマウスを使っていることもあり、InDesignを使う分には何の違和感もありません。
さしあたっての懸念は、テキスト処理をどうしようかという点でした。

が、そちらも問題なし。
OSXには最初からRubyが入っている。
というわけで、コンソールでこちょこちょやってみたけどうまくいかない。

……ったり前ですね。
このブログで私が書いてきたスクリプトの多くは、冒頭でSJISを指定している。

スクリプトファイル・処理対象テキストファイル双方とも、文字コードをutf-8・改行コードをLF（UNIX）にそろえることできちんと変換処理できました。
本格的にMacを使い出してから今までのところ、上記以外の文字コード・改行コードでの変換処理はうまくできていません。多分、いずれかのファイルのコードが違っていたんだろうと思うのですが。
これって、各ファイルの文字コード・改行コードをそろえた上で適切なコード指定をしてやればどのコードでも動くんだろうか。
おいおい実験していこう……。

InDesignCS5.5 ver.7.5.2／WindowsXP sp3

ID CS5.5検証 その1の続き。

上記エントリにおいて、「ここまでインデント文字」直前の文字が「文字組アキ量設定」によってアキが生じるように設定された文字だった場合、折り返した次行以降の行頭が意図した位置に揃わなくなるという不具合を紹介しました。
同エントリ内において私は下記のような回避策を書いています。

回避策としては、ここまでインデント文字直前のピリオド（全角です）について、明示的に文字後のアキ量を二分に設定してやることで２行目以降の行頭位置をきちんと揃えてやることができます。
もちろん、素直にマイナスインデントを設定すれば済むことですが。

随分前になりますが、Twitterでも話題になりました。
InDesignの「ここまでインデント」はDKIか - Togetter
ものかのさんが素晴らしい解決策をご提示なさっていますので紹介しておきます。

「ここまでインデント文字」の直前に「結合なし」を入れてやることにより、次行以降の行頭がきちんと揃う。

ドキュメント上の「ここまでインデント文字」を一括置換してやればよさそうですね。
すでに「結合なし」＋「ここまでインデント文字」になっている箇所を二重に置換しないためには正規表現で。



こんな感じですっきり解決！
ものかのさん、いつも大変ありがとうございます。

（追記）博士が文句言うから（笑）Macのスクリーンショットも載せておいた。

InDesign CS5.5 ver7.5.2／WindowsXP sp3

2012/02/28現在、日本語入力ソフトとしてATOK2011をメインで使っています。
不満はないどころか、むしろ満足しています。
エディタ上で入力する時など、MS-IMEと比べて充実した漢字検索機能がある点で非常に重宝しているのです。

しかし、InDesign上で文字入力をした際の動作が少し残念なことに。
私は変換時の操作として文節区切りの伸張・収縮を頻繁に行いますが、Shift＋→で伸張、Shift＋←で収縮というのが他の日本語入力ソフトにおいても一般的な動作ではないでしょうか。
実際、2011にバージョンアップする前に使っていたATOK2005とInDesignの組み合わせにおいては上記の通りに動作していました。
ATOKのキーカスタマイズにおいて上記の設定になっていることを確認した上で、InDesign上で変換操作を行うと……。



いくらShiftと矢印を同時に押しても文節区切りの伸張・収縮が効かないのです。
あきらめて日本語入力ソフトをGoogle日本語入力に切り替えてためしてみました。



デフォルトのまま使ってみたところ、Shift＋矢印キーにより文節区切りの伸張と収縮が期待通りに動作しました。

詳しくはわかりませんが、どうやらInDesignCS5.5とATOK2011の組み合わせに難があるのか、キーの組み合わせによる操作においてコンフリクトが起きているような気がします。
実際、EmEditorとATOK2011の組み合わせであれば問題なく文節区切りの伸張と収縮ができることを確認しました。

残念ながら現在のところこれ以上の検証ができません。

仕方がないので本エントリにおいては、InDesign上で長めの日本語入力を行いたい場合はGoogle日本語入力など別のソフトに切り替えることを提案しつつ、未消化のまま不具合報告のみで筆を置くことといたします。


【追記】
同僚によると、どうやらInDesignCS3＋ATOK2005の組み合わせにおいても、長めの複合語変換の動作が怪しかった模様です。
私は業務上、原稿の 誤字 送り仮名の不統一等 も極力正確に再現するため、ごく短めの文節ごとに変換していく癖がついているので気付かなかっただけのようです。
やはり、少しでも長めの文章であればエディタ上で入力した上でInDesignに配置なりコピペなりするのがベターだと言えるかもしれません。

自宅PC用のウイルス対策ソフトは、これまで無料版を使ってきた私ですが、製品版の方がなにかと安心なのではないかと思う今日この頃です。
ESETにはWin版・Mac版があり、会社用のウィルス対策ソフトとしてESETを使っているところは多いようです。
そんな中、更新料ゼロを売りにした標題のソフト、スーパーセキュリティZEROの噂を耳にした次第。
Windows版ですが。

同じソースネクストのウィルスセキュリティZEROも更新料ゼロで、名前も似ているからソフト名を聞いた当初は混乱したけど、「スーパー……」の方はどうやらベッキーがCMしている方みたい。
これからウィルスソフトを比較しているサイトを見て回って、よさそうなら自宅への導入を考えてみようと思う。

ご無沙汰しております（苦笑）
CS6の発売日も迫ってきたと思いますが、この年末、ようやくCS5.5にバージョンアップしました。
そこで、とりあえず、ID CS5検証 その7について、CS5.5ではどのようになるか試しました。

ご覧の通り。
すみません説明します。

まず右上の赤丸部分から。
リンク先の過去記事を読んでいただくとわかりますが、CS5においては行頭に文字組アキ量設定によるアキを設定された文字を置いた場合であっても「ここまでインデント文字」による２行目以降の行頭位置がずれることはなくなりました。
しかし。
ここまでインデント文字の直後の文字にルビが設定されていると、行末にかかる文字がフレーム末尾からはみ出すという不具合がありました。
それは解消されたのですが。

左下の赤丸部分をご覧ください。
今回新たに気付いたのですが、ここまでインデント文字の直前に文字組アキ量設定によるアキを設定された文字があると、やはり不具合が発生します。
この現象はCS5／CS5.5両バージョンで発生することを確認しました。
どうやら、このような段落設定は今までは慣例的にマイナスインデントで設定していたため気付けずにいたようです。
回避策としては、ここまでインデント文字直前のピリオド（全角です）について、明示的に文字後のアキ量を二分に設定してやることで２行目以降の行頭位置をきちんと揃えてやることができます。
もちろん、素直にマイナスインデントを設定すれば済むことですが。

短いですが、今回は、というかおそらく、今年はここまで。
来年はもっとマメに更新したい……なぁ（＾＾；