InDesign居残り補習室 ルビ＋ここまでインデント＝バグ
Windows XP sp2／InDesign CS3で確認 １ 行頭にスペース文字を含む際、 ここまでインデントに続く文字とその行の行末にルビがあると…… 1行目の行末位置および2行目以降の行頭位置がおかしくなる。 ２ 最初のルビを外してみると、ここまでインデント文字による字下げは正常になるが、行末は直らない。 ３ 行末の一文字だけルビを外すと……なんじゃこりゃ。 ４ 行末の複数文字のルビを外すと正常に。 MAC OSX 10.5.8／InDesign CS4で確認 ５ 行頭は正常、行末は異常に。 ６ ここまでインデント文字に続く一文字だけルビ解除すると……なんじゃこりゃ。 ７ 複数文字を解除すると正常に。ちなみに上図６においても、行末だけは正常になった。 まあ、バグ……ですよね。 2010年4月1日追記： s/行頭にスペース文字を含む際、// 念のために付記しておきます。 WIN版 I
「検索と置換」の「字形」_何か変？ - なんでやねんDTP・新館
漢字＝筑紫明朝Pr5 Lと仮名＝イワタのオールド明朝Pro Rで合成フォントを組んであるのだが、必要があってCID3049の「塚」をCID8422の「塚」に「検索と置換」の「字形」を利用して、確認しながら置換しようとしたが……。 ※すぐに原因判明……もしかしてバグ？……末尾に…… 何故かCID4230となってしまう。フォントもイワタのオールド明朝Pro Rに……。 試しに別のテキストフレームを作成し、ほぼ同じことを小塚明朝Pro Rでやってみると…… 今度はイワタのオールド明朝Pro RのCID7746となってしまった。 何かの設定と絡みあっているのか……とりあえずワケが判らないので、今回は別の方法でやるしかない。 ご報告まで（環境は Mac OSX10.4.11/InDesign CS3_v.5.0.4）。 ※申し訳ない。別の検索/置換を実行しようとして原因が判明した。 「検索と置換/テ
ルビ_「自動行頭/行末揃え」のバグ? - なんでやねんDTP・新館
今作業中の案件で気付いたのだが、ルビの挙動がオカシイ。 明らかに「バグ」だと思われるが、時間がないのでとりあえずご報告だけ……。 （環境は Mac OSX10.4.11/InDesign CS3_v.5.0.4） 最初は以下のように「自動行頭/行末揃え」をチェックしていた （この時点で既にオカシイのだが……） この時点では気付かなかったが、 行頭を下げても可となったのでチェックを外した 「女」も「水」も動いていないが判るだろうか？ 横に並べてみると…… 見ての通り「自動行頭/行末揃え」にチェックを入れた方の「処/女」間が全角＋1/3位はあるのに「女/水」間はほぼ全角と均等にはなっていない（外した方は均等に見える）。 この場合、「0-2-2-1」で割るべきところを「0-3-2-1」と割っているように見える（外した方は「1-2-2-1」だろう）。 親文字3文字以上のグループルビで、なおかつルビ
あかつき＠おばなのDTP稼業録 【InDesign】「結合なし」で段落スタイルを割り当てるトキは…
ダミーのテキストを検索対象、置換文字列に「その他」→「結合なし」、置換形式に任意の段落スタイルを指定して「検索と置換」を実行すると段落スタイルを割り当てることができます。 ※この方法は「InDesignの勉強部屋」のYUJIさんに教えていただきました。 このとき実行後の行頭に約物などあると、文字ツメがおかしくなるようです。 どういうことかと言うと… 【 】の部分が段落スタイル割り当て用のダミーテキスト。 こんな設定で検索＆置換を実行していきます。すると… 2行目はきちんと変換されているのに、1行目は行頭の文字ツメがおかしくなっています。 これを回避するには、 1.段落スタイル割り当て後、「検索と置換」を使って「結合なし」のメタ文字を削除する。文中に「結合なし」を使用している場合は、GREPで「段落の始まり＋結合なし」と指定する 2.段落スタイル割り当て用のダミーテキストを削除しないでスタイ
Grepのバグ？
久々にIndesignネタを。 簡易タグから段落スタイルの割り当てというスクリプトを作っていて、例えば <ex> 文字列文字列文字列文字列文字列文字列文字列文字列文字列文字列文字列 </ex> とタグがあってスクリプトを走らせると、現ドキュメントで使用している段落スタイルを選びそのタグで囲まれた文字列に割り当てられる、というもの。 上記の例でいえば app.findGrepPreferences.findWhat = "(?s)^<ex>\r(.+?)<\/ex>\r"; app.changeGrepPreferences.changeTo = "$1"; としておいて、findGrep()の戻り値に段落スタイルを適用して、changeGrep()でタグを取り除く、という仕組みにした。一段落ずつ見ていってタグを取り除くより正規表現で置換した方が楽に思えたので。 何回か検証して問題がなかった
InDesignの米印問題は環境依存性が恐い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CS4における米印などの属性をめぐる問題については以前のエントリ（InDesign CS4で「※」や「×」が恐い）で触れたが、実はそのエントリで報告した検証結果だけでは、うちの会社が実際に遭遇したトラブル（出力センターで校正を出したらレイアウトがズレていた）を説明できていなかった。 そこですでに検証したCS3/CS4 Intel（Mac）に加え、CS3/CS4 PowerPCで実験してみた。結果は下図のとおり。PowerPC環境では、CS3でもCS4でも「CIDベースの文字組みを使用」がオフだと、米印などは欧文属性となる。CS4 Intelのような不安定さはないが、安定して間違っている。 下図は、InDesign CS4 Intelで作成したドキュメント（字間をカーニングで調整）をCS4 PowerPCで開いた場合のレイアウトのズレを再現したもの。「うちの会社が実際に遭遇
InDesign CS4で異体字のあとにテキストをペーストしたときの文字化け - Mac OS Xの文字コード問題に関するメモ
InDesign CS4では、「aaltフィーチャによってグリフを置換されている文字」の直後にプレーン・テキストをペーストした場合（あるいはテキストを「フォーマットなしでペースト」した場合）、ペーストした文字にaalt属性が伝染してしまう*1。 たとえば、小塚ゴシックProで字形パネルからCID+12123の小鍵（U+FE41の4番目の異体字）を入力し、その直後に「二」（U+4E8C）を「フォーマットなしでペースト」すると、「貮」（U+4E8Cの4番目の異体字）に化ける。 これはInDesign CS2に見られた問題で、CS3では直っていたが、CS4で再発している。この問題は、InDesign CS2、CS3でも見られる。（twitterでの@akatsuki_pocketさん、@monokanoさんのご教示により訂正。ご指摘ありがとうございました） *1:「aaltフィーチャによってグリ
InDesign CS4で「※」や「×」が恐い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CS4で「※」や「×」などの文字が、「和字」であるように振る舞ったり、「欧文用文字」であるように振る舞ったりする。Adobeに問い合わせ中の事例で、再現性が環境に依存する可能性があるのだけれど、とりあえず、わたしの環境における挙動をメモ。 InDesign CS4で「環境設定＞組版＞CIDベースの文字組みを使用」をオフ、「段落＞文字組み」は「行末約物半角」とし、テキストフレームに以下のようなテキストを入力する。 あ±1 あ×1 あ÷1 あ§1 あ※1 あÅ1 あ†1 あ‡1 あ¶1 これを一度保存して開き直したものが下図。「あ」の後ろに和欧間のアキが入っており、「※」などの記号類は欧文用文字として扱われている。 これだけでもCS3との非互換性が問題なのだが、さらに面倒なことに、テキストを編集することによって記号類の属性が変化することがある。下図は、1行目の「±」の前の「あ
ルビの中黒_とりあえずの解決策 - なんでやねんDTP・新館
現在進行中の案件で「専門用語」に「テクニカル・ターム」とルビを振る部分があった。 ルビ用の中黒が大きく表示されてしまうバグは既報の通り（下の画像中）。 よってこういう場合、普段は「Open Type Proのルビ用字形を使用」のチェックを外し、ウエイトをひとつ太くして対処していた（下の画像右）。 ※前後ともカナのために見た目では判別し難いが中黒は半角扱いとなっている しかし、流石にプロの校正の方の眼は鋭い、「ルビの大きさを他と揃える」とチェックが入った（これまではこういう処理で誤魔化して来たのだが……恐れ入る）。 しかし、ルビのサイズを大きくすると……結果は想像できる。 色々試行錯誤しているうちに、ダメで元々と 特例文字で「中黒」を、唯一正常なサイズで表示してくれる「モリサワ_リュウミン系」に設定した合成フォントを組み、ルビのフォントとして指定してみたところ、すんなり解決できてしまった（上
InDesignにおけるJIS04基準フォントのウマヤ化け問題 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CS4で「厩」を入力・選択し、字形パネルをダブルクリックしてCID+13647に置換。フォントは（たとえば）小塚明朝Pr6N。そのウェイトを変更してみる。と、CID+13412に化ける（下図）。 このグリフ化けのおもしろい点は、cmapテーブルもaaltテーブルも共通だと思われるフォント間で（ウェイトの違いのみで）化けていること。以下、化ける理屈（推測）について、大雑把に述べる。 InDesignにおけるaalt（すべての異体字）タグを利用したグリフ置換のメカニズムは、cmapテーブルまたはaaltテーブルが異なるフォント間では、基本的にうまく機能しない。実際、InDesign 2では、いろいろ化けていた。 CS以降のInDesignでは、Adobe-Japan1-4とAdobe-Japan1-5のcmapテーブルの違いおよび2系統存在するaaltテーブルの違いへの対策が
InDesign単体でも白オーバープリント - chalcedony_htnの日記
もしかして常識だったらどうしよう。まあ、自分メモとして書いておくことにしよう。 Windows版しかわからないのだけど、Macだとどうなんだろう？ InDesign単体なら大丈夫のはず InDesignは白や紙色のオブジェクトにオーバープリント属性を設定できません。プリント属性パネルのチェックが触れなくなるし、もともと別の色でオーバープリントが設定されているのを白に変えると自動でチェックが外れます。CS2までは線と塗りの入れ替えによってオーバープリント属性が残ってしまう問題（参考：DTP-Sブログ-ひねもすデジタルビヘイビア: InDesignでも発生する白のオーバープリント）があったのですが、CS3からはその点も修正されています。 と思ったら、段落境界線に罠が 以下、Windows XP SP2、InDesign CS4（6.0.3）でやってます（CS1でも同様になります）。 私はこんな
InDesignCS2～CS4での合成フォントの問題｜出力の手引きWeb｜株式会社SCREENグラフィックソリューションズ
2009年04月23日 ｜ InDesignCS2～CS4での合成フォントの問題 ＜2010年7月27日追記＞ この問題はTrueflow側での対策が完了しています。 詳細は記事「2010年07月27日｜7つの問題の対策、完了しました」を参照してください。 ■問題の概要 合成フォントが使用されたInDesignCS2～CS4のドキュメントからダイレクトにPDF/X-1aを出力し、Acrobat 7とAcrobat 9(やAcrobat 8)で表示させると、表示上の差違が発生する場合があります。Trueflowでも従来の演算系で同様の問題が発生することがあります。症状から見るとAcrobat 8以降で問題が修正された様に見えますが、この問題の本来の原因はInDesignが出力するPDFの記述にあり、PDFの規格としてはAcrobat 7やTrueflowでの出力結果の方が正しい（がInDes
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Blog | Welcome to Adobe Blog
Nope
InDesign居残り補習室 合成フォントの不具合
Nasty CS4 Bug: Missing Master Items in Placed .INDD | CreativePro Network
Two more CS4 Bugs: The Reluctant Book Panel & Swatches By Name | CreativePro Network
サービス終了のお知らせ