[ 掲示板に戻る ]

過去ログ閲覧モード

改行のみの行を伸縮してテキストボックスにフィット / 甚一
続けての質問ですがお願いします。
テキストボックスのサイズが固定で行数はそれぞれ異なります。先頭行を上に、最終行を下にフィットさせるため、改行のみの行を伸縮させることは出来ますか?

―――――――――――――――――――
ああ
ああ
    (改行だけの行でここを伸縮)
いい
うう
    (改行だけの行でここを伸縮)
ええ
―――――――――――――――――――

このようなイメージです。
バージョンは、CS3です。よろしくお願いします。

No.194 2007/11/07(Wed) 16:04:13
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/523.10.3 (KHTML, like Gecko) Version/3.0.4 Safari/523.10

Re: 改行のみの行を伸縮してテキストボックスにフィット / かたやなぎ
当方CS2です。
テキストフレーム設定の段落スペース最大値を大きくする、かな?

No.195 2007/11/07(Wed) 16:57:20
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.9 (KHTML, like Gecko) Safari/312.6

Re: 改行のみの行を伸縮してテキストボックスにフィット / いき URL
かたやなぎさんの提案がベストだと思いつつ、あえて別の方法を提案。

改行だけの行をつくらず、フレームを分割して、
整列 → マージンに揃える → 垂直方向に等間隔に分布
でいかがですか?

フレームの連結が不要ならフレームを内容に合わせれば良いのですが、連結が必要なら各フレームの天地サイズは計算して合わせることになる点が面倒……。

No.197 2007/11/07(Wed) 18:04:02
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: 改行のみの行を伸縮してテキストボックスにフィット / 甚一
> テキストフレーム設定の段落スペース最大値を大きくする、かな?
このような設定があるとは知りませんでした。お聞きしてよかったです。
段落スペース最大値は具体的にどこの値ですか? 適当な数値にしたら希望する形にはなりましたが。

今回は、テキストフレームを分けたくないので、かたやなぎに教えていただいた方法で進めたいと思います。いきさんすいません。

ありがとうございました。

No.204 2007/11/08(Thu) 13:26:48
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: 改行のみの行を伸縮してテキストボックスにフィット / かたやなぎ
>段落スペース最大値は具体的にどこの値ですか?

「段落前(または段落後)のアキ」と考えればよいと思います。

ですので、ひとつのパラグラフ(文段?)内に複数の「改行」が
あるときはこの手は使えません。いきさんのご提案された方法や、
空行を入れ力づくで整える作り方のほうがよいのかもしれません。

No.206 2007/11/08(Thu) 14:25:10
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.9 (KHTML, like Gecko) Safari/312.6

Re: 改行のみの行を伸縮してテキストボックスにフィット / 甚一
>「段落前(または段落後)のアキ」と考えればよいと思います。
なるほど! 

>ひとつのパラグラフ(文段?)内に複数の「改行」があるときはこの手は使えません。
添付画像のイメージですので、段落は均等配置でなく、強制改行できますので大丈夫です。
今までは、いきさんのご提案にご提案していただいたフレームをそれぞれ分けて、フレームを垂直方向等間隔に配置していました。表題・氏名・所属が1〜3行で増減しますので各フレームのフレームを垂直方向等間隔に配置ではかなりの手間でした。

かたやなぎさん、いきさんありがとうございました。

No.212 2007/11/09(Fri) 09:59:58
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3
CS3のInDesignファイルの配置 / 甚一
どうも、お世話になります。
CS3からInDesignファイルの配置が出来るようになりましたが、マスターページを配置することは出来ないのでしょうか?
よろしくお願いします。

No.193 2007/11/07(Wed) 15:11:00
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/523.10.3 (KHTML, like Gecko) Version/3.0.4 Safari/523.10

Re: CS3のInDesignファイルの配置 / YUJI Email URL
配置ではなく、コピー&ペーストするのではダメですか?
No.196 2007/11/07(Wed) 17:05:58
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/522.11.1 (KHTML, like Gecko) Version/3.0.3 Safari/522.12.1

Re: CS3のInDesignファイルの配置 / 甚一
> 配置ではなく、コピー&ペーストするのではダメですか?
演題集録の仕事で1演題3〜5頁で50演題程度になる予定です。すべての演題が著者校了後、頁順が決まりますので1演題づつのファイルにしてブック機能で通しノンブルを振っています。ヘッダー・フッター部分に発行月の英語表記(November等)や発行ID(?)が入りますが、毎回著者校正が遅れるため、発行予定より2ヶ月ほど遅れます。最終的にヘッダー・フッター部分が変わります。ですので、今まで(CSでした)は、ヘッダー・フッター部分をイラストレーターファイルで作り配置しておりました。今回はCS3で進めるつもりです。ですのでInDesignファイルの配置が出来るでのマスターページを配置できればと考えました。
しかし、CS3には、ブックの同期オプションにマスターページがあり、試してみたところ変更していないファイルも変更されたので、ブックのマスターページ同期で進めようと思います。
いまいち自信がないのですが、この方法でよいでしょうか?
YUJIさんのせっかくのご提案すいませんでした。

No.205 2007/11/08(Thu) 13:44:33
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: CS3のInDesignファイルの配置 / KOUJI
> ヘッダー・フッター部分に発行月の英語表記(November等)や発行ID(?)が入りますが、

CS3をお使いであれば、このあたりはオリジナルのテキスト変数を使うとかなり楽ができそうですよ。
例えば、「発行月・発行ID」というヘッダーないしフッターが入るのであれば、オリジナルの変数を出力日あたりで作成して、日付形式を「MMMM」、発行IDは後続テキストで設定すれば「November・発行ID」を自動入力できそうです。このとき、日付の表記部分は文字パレットにある言語で設定されている表記になるようなので「発行日」の文字部分は言語属性を英語にする必要があるみたいです。
あと、下版前に日付変数をテキストに変換しておかないと事故の元になりそうなので要注意ですが、出力する月が変われば表記も勝手に変わるので修正の手間ははぶけると思います。

No.207 2007/11/08(Thu) 14:37:57
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: CS3のInDesignファイルの配置 / 甚一
>テキスト変数を使うとかなり楽ができそうですよ。
>下版前に日付変数をテキストに変換しておかないと事故の元になりそうなので要注意ですが、出力する月が変われば表記も勝手に変わるので修正の手間ははぶけると思います。


製版出力が月末や印刷・製本の都合で発行月と製版出力日が同じにはならないときもありますので、折角ご提案いただきましたが、この仕事については、ブックのマスターページ同期で進めます。1ファイルの変更ですべて更新できますのでこれで十分です。いままでは、手間を省くため、わざわざ文字のみのイラストレーターファイルを配置していましたので。

KOUJIさんにご提案いただいた「テキスト変数」については、もう少し勉強して活用しよう(できるな!)と思っています。ありがとうございました。

No.211 2007/11/09(Fri) 09:26:57
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3
(No Subject) / あぁ
まる さんは "TES" のベースラインがズレてしまっている事を言ってるのでしょ?
No.150 2007/11/05(Mon) 23:22:34
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: / まる
なんだか上の書き込みが、私が書き込んだように思われては不本意なので、
画像を貼り込みます。
・(一)の組を(二)の組にしたい。
・段落設定の「縦組み中の欧文回転」は使用しない(横のままの欧文があるので)。
・文字設定の「文字回転」はそのままでは、(二)の組版を実現できない。
・縦中横はタテにする欧文が一つだけの場合はいいが、二つ以上あると、
当然「縦中横」になってしまうので、(極細スペースを入れたり)面倒。

ということなんです。

No.151 2007/11/06(Tue) 01:04:26
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.9 (KHTML, like Gecko) Safari/312.6

Re: / taopichi
> 文字設定の「文字回転」はそのままでは、(二)の組版を実現できない。

むむむ、自宅のMac版CS1では小塚明朝StdRで「縦組み中の欧文回転」は使用しないの状態で、単純に「文字回転」90度でできているような気がしますが(半分寝ぼけてるので違いがわからないだけかも)。
まるさんのところでは、「文字回転」はそのまま、の状態はどうなっているんでしょうか?

No.152 2007/11/06(Tue) 01:23:40
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

こんなことをお書きになる前にすべきことを。 / 篠原酒店
> なんだか上の書き込みが、私が書き込んだように思われては不本意なので、
> 画像を貼り込みます。


こんな前置きを書くに私の質問にご回答いただく責任を果たしてください。
一方的に「悪意」と中傷されたのでは、こちらこそ「不本意」ですし、そういった表現はあぁ様にも大変失礼です。

それに、
>できれば合成フォントで進行したいところなのです。
と書いていらっしゃるのですから、実務にそったサンプルをお創りいただきたいものです。
あなたの言葉をお借りすれば、
「どういう悪意をもって解釈すると、上記のようなサンプルを作れるのでしょうか。」

なお、「悪意」と言葉をお使いになった理由について、明確なご回答が得られない限り言及を続けさせていただきますのでその点は覚悟の程を。

他人に迷惑をかけた自覚をお持ちですか?
もっとも「自分は一方的な被害者」とお感じであればそういった気持ちはないと思いますが。

No.154 2007/11/06(Tue) 06:18:46
Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: / いき URL
ええと(^^;
お気持ちはわかりますが篠原酒店さんもどうか冷静さを失わないようにお願いします...

> 単純に「文字回転」90度でできている
私もtaopichiさんのレスを支持しますが、それではダメなのですか?

No.155 2007/11/06(Tue) 08:36:31
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: / YUJI Email URL
なんかやり取りがヒートアップしてますね(^^;;

> まるさん
せっかくレスしていただいた方に「悪意」とか「不本意」とかの返答はちょっとどうかと。
篠原酒店さんのレスからは「悪意」は感じられませんでしたよ。

> 篠原酒店さん
冷静にいきましょう。

本題に戻りますが、私もサンプルを作ってみました。
「縦組み中の欧文回転がオン、USAを90度回転したもの」と
「縦組み中の欧文回転がオフ、目的の欧文を−90度回転したもの」です。

左の結果がまるさんの求める結果のような気がしますが、
No.111でまるさんが上げた画像とは結果が異なり、ベースラインはずれませんでした。
1つ質問ですが、No.111の真ん中の画像ですが、これはスモールキャップを適用しているのですか?

No.157 2007/11/06(Tue) 09:15:36
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/523.10.3 (KHTML, like Gecko) Version/3.0.4 Safari/523.10

意図的な文面です / 篠原酒店
「ヒートアップしている」と「感じさせた」のは意図的なものです。

さてサンプルを作っていて気が付いたのですが、YUJIさんの場合も私の場合も、「文字数の多い単語を文字回転機能で回転させる:と、和欧文間のアキが取れてしまい組版結果が違ってしっまっているのですが、この原因はおわかりでしょうか。

先日の私のサンプル提示時も、いろいろご指示を仰げるかと思い「皆様からのご指摘をお待ちしたい」と書きました。
言い換えれば「ツッコミどころ満載」でしたが、それはみなさんとのやり取りで解決したいと思ったところです。

No.160 2007/11/06(Tue) 10:23:22
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: / works014 Email URL
眺めていましたが、面白いのでちょっとやってみました。
するとマイナス90度回転させた文字列に明らかなベースラインのズレが発生しました。(真ん中)
(フォントはGaramond Premier Pro、合成フォントは組んでいませんが)
まるさんの欲しいのは右端でしょうか?
作例はデフォルトの行末約物全角/半角を使用していますので、
和欧文間のスペースを削除してあげればいいのでは? と思った次第です。
追伸:この例では和欧文間のスペースは残っていますね。

No.161 2007/11/06(Tue) 10:28:49
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: / works014 Email URL
失礼、真ん中は「縦組み中の欧文回転」オンです。
しっかり校正せんとアキマセンね。

No.162 2007/11/06(Tue) 10:31:06
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: / いき URL
篠原酒店さーん(^^; >>
> 「ヒートアップしている」と「感じさせた」のは意図的なものです。
他の掲示板閲覧者の方々にとって、気分のよいことではありませんので……。
ここは大人の忍耐力を発揮してぐっとこらえましょうよ(^^;

No.163 2007/11/06(Tue) 10:44:42
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: / 篠原酒店
発言の撤回はしませんが、この組版作業自体については面白いトピックだと思うので話題を進めましょう。

さて、検証されているデータでの「ベースラインのズレ」は何がきっかけで起きるのか、改めて把握したいと感じました。
works014さんのサンプルでもなぜかズレるのが一部の文字というのが気になります。

No.167 2007/11/06(Tue) 13:00:40
Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: / taopichi
> 検証されているデータでの「ベースラインのズレ」
カーニングで「和文等幅」以外にするとズレが直るのだけ,確認しました.
昼休みにできるのはこれだけで・・・.

No.169 2007/11/06(Tue) 13:34:43
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: / works014 Email URL
> カーニングで「和文等幅」以外にするとズレが直るのだけ,確認しました.
確かに、当方でも確認できました。

No.170 2007/11/06(Tue) 13:53:04
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: / あぁ
返信ボタンを押したつもりでしたが、新たなスレッドになってしまった事を、管理人様及び各位にお詫びいたします。
また、まるさんに問いかけたつもりでしたが、「あぁ」などと、その場限りの様な名前で投稿したせいだと思いますが。。。
しかし、内容を否定されたのでしょうか? ちょっとびっくりです。

私もこの文字がズレる件に興味がありCS3で試してみましたが、
ズレる現象を再現できませんでした。
しかし、欧文テキストを和文と同じフォント(小塚明朝Std)を使用し、
縦組み中の欧文回転をオンにして、United--Americaをスモールキャップスに変更後、文字を-90度回転させた場合、悲惨な結果になりました。
スモールキャップスになった部分の全てがズレてしまいました。

IntelMac osX10.4.10 CS3 5.0.1

No.172 2007/11/06(Tue) 19:01:16
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

新しいトピックとしましょうか / 篠原酒店
> また、まるさんに問いかけたつもりでしたが、「あぁ」などと、その場限りの様な名前で投稿したせいだと思いますが。。。
> しかし、内容を否定されたのでしょうか? ちょっとびっくりです。


これを機に新しいトピックとして情報交換するというのがよいかと思いますが如何でしょうか。

> スモールキャップスになった部分の全てがズレてしまいました。
文字回転の基準位置をどこに設定して動作するアプリケーションなのかますますわかりませんね…。
ちなみに、スモールキャピタルでなく小文字の場合も同じですか?

No.173 2007/11/06(Tue) 19:09:06
Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: / あぁ
初めまして、篠原酒店さん。

>ちなみに、スモールキャピタルでなく小文字の場合も同じですか?
小文字であれば全く正常にみえます。

>これを機に新しいトピックとして情報交換するというのがよいかと思いますが如何でしょうか。
そうですね^^;

あと、CSなどのバージョンとか環境を書いておいて頂けると非常に参考になると思うのですが。

No.174 2007/11/06(Tue) 19:22:56
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: / まる
YUJIさま
>左の結果がまるさんの求める結果のような気がしますが、
>No.111でまるさんが上げた画像とは結果が異なり、ベースラインはずれませんでした。

すみません、よくわからないのですが、投稿された文章には間違いがないでしょうか。
「縦組み中の欧文回転がオン、USAを90度回転したもの」というのが、よくわかりませんでした。
欧文が「オン」=タテだったら、90度回転させるのはUnited...のほうですよね?
オン/オフが逆なのか、それとも左右の組版自体が逆なのでしょうか。
上げていただいた画像は、微妙に、意図した組版とは違います。
USAがきちんとグリッドに揃っておらず、「USAは」の「は」がずれてしまっています。
(スモールキャップについては、もともとそういう書体というだけです。)

works014さん、まさに右端の組版が意図したものです。
なるほど、前後の文字間をベタにするといいのですね。
アタマがすっきりしました。
しかし、一箇所ならともかく、これを初校の赤字などの後進行を考え合わせながら、
文字スタイルとして設定しようとすると、非常に難しいものがあるような気がするのです。
文字組アキ量設定で和欧文間をベタにすると、
当然、ヨコのままの和欧文間にも影響が出てしまうような……。

あぁ さん
>内容を否定されたのでしょうか?
新しいトピックを建てるために、別の名前を騙ったと思われたら「不本意」という意味で、
私の書き込みではないと「否定」しただけです。
結果的にこうして議論を続けられることができたのですから、
むしろ感謝しております。

No.178 2007/11/07(Wed) 02:35:40
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.9 (KHTML, like Gecko) Safari/312.6

Re: / まる
連投失礼します。
taopichiさん
>カーニングで「和文等幅」以外にするとズレが直るのだけ,確認しました.
ということは、「縦組み中の欧文回転」を「オン」にし、
ヨコにする欧文に、-90度+「和文等幅」以外を指定した文字スタイルを作れば、
1アクションで実現できるということですね。
もうちょっといろいろな書体で私も試してみたいです。
ありがとうございました。

No.179 2007/11/07(Wed) 02:53:20
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.9 (KHTML, like Gecko) Safari/312.6

Re: / YUJI Email URL
> すみません、よくわからないのですが、投稿された文章には間違いがないでしょうか。

まるさん、大変失礼いたしました。
「縦組み中の欧文回転」のオンとオフが2つの画像で逆になっていました(^^;;
すいませんでした。

No.180 2007/11/07(Wed) 07:56:18
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/522.11.1 (KHTML, like Gecko) Version/3.0.3 Safari/522.12.1

Re: / いき URL
>文字組アキ量設定で和欧文間をベタにすると、
>当然、ヨコのままの和欧文間にも影響が出てしまうような……。


私は和欧間ベタがよいかな、と思います。
欧文回転オフ、縦にしたい欧文の文字スタイルは文字回転90度です。
元のテキストに一括でタグを与えて配置するのが楽だと思いますが、特殊文字で四分スペースなどいくつかのバリエーションがありますので、それをヨコにしたい欧文と和文との間に挟む方法を提案しておきます。

No.182 2007/11/07(Wed) 09:51:02
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: / works014 Email URL
和欧文間スペースが気になったので、
合成フォントを組んで同じものに適用してみました。
合成フォントの場合には「縦組み中の欧文回転をオン」にすると
和欧文間スペースは無視されるようですね。
なお真ん中のUNITE〜AMERICAはメトリクスを適用しています。
この部分の字送りはペアカーニングが効いていないようで、
オフの場合と微妙に違いますね。

No.184 2007/11/07(Wed) 10:09:35
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: / works014 Email URL
準備をしている間に.........
いきさんのご提案に私も一票。
先の投稿は和欧文間スペースの挙動を確認したまで。
ちなみに環境はMac版CS2_v.4.0.5です。

No.185 2007/11/07(Wed) 10:18:29
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: / 篠原酒店
おはようございます。私の文章には知らぬ間に悪意がこもるようなのですが、自分ではなんともしようがなく非常に悩んでいます。
とはいえ、「悪意のない悪意」というのは無自覚のうちに存在するものですから、まるさんはそれを敏感にお感じになったのだろうと解釈しています。
最初は「どういった点が悪意にあたるか教えていただきたい」という「甘え」もあったのですが、それ以前に皆さんが私の存在で気分を害されていると判断せざるを得ず、これでは私に参加資格や発言権はないだろうという結論に達したので、この掲示板への書き込みはこれを最後にさせていただきます。
(勉強のために閲覧だけはさせていただきたいのですが、なにとぞお許しください)

> 元のテキストに一括でタグを与えて配置するのが楽だと思いますが、特殊文字で四分スペースなどいくつかのバリエーションがありますので、それをヨコにしたい欧文と和文との間に挟む方法を提案しておきます。

「文字組アキ量」を増やして適用してみるのはどうかな…と書いている間にまたご提案がありましたね。

知識が不十分にも関わらず発言を繰り返し申し訳ございませんでした。
これからのますますのご発展をお祈りして最後の発言とさせていただきます。

No.186 2007/11/07(Wed) 10:23:55
Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: / いき URL
篠原酒店さん>>
ご自身の判断で書き込まないのであれば、翻意を促すつもりはありませんが……。
せっかく有益な情報を交換できるスキルをお持ちなのに、勿体ないです、とだけ申し上げておきます。

No.188 2007/11/07(Wed) 10:46:10
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: / あぁ
私は篠原酒店さんには悪意を感じませんし、気分を害する事もないと思います。

なぜ私がこのスレッドのNo.150に投稿したかというと、
まるさんの仰りたかった事を確認するためでした。
それは、No.111の画像で「ベースラインがズレる」事の意味がはっきりしなかったからです。
たぶんその時点で篠原酒店さん他、明確に理解されていなかったのではないでしょうか。
そして「USA」の上下間の文字ズレ?の事と話がごっちゃになって。。。
まるさんは、フラストレーション溜まりますよね。回答している皆さんにもですね。。。
ようは、まるさんがもう少し皆さんに言葉多く図を交えて、言いたい事を伝えるべきだったのでしょう。
などと考えますので、穏便に穏便に。。。

No.191 2007/11/07(Wed) 12:21:31
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: / まる
>なぜ私がこのスレッドのNo.150に投稿したかというと、〔……〕
>それは、No.111の画像で「ベースラインがズレる」事の意味がはっきりしなかったからです。


う〜ん、ベースラインが揃っていない箇所に、
わざわざ矢印+「ベースラインが揃わない」と書いているのに、
その意味がわからないというのは、どういうわけでしょう。

ベースラインのこの程度のズレは誤差の範囲だから、問題になるはずがない、
したがって誰も気づいていないかもしれない、と、
あぁさんが先回りして想像された(わかりにくくてすみません)ということでしょうか。

いや、じつは上の157投稿でYUJIさんの画像を拝見して、
(こちらはベースラインではなく、和欧文間のアキ量のズレですが)
「もしかして、この程度の差異にこだわること自体、理解を得られないのかな」とチラリと思いました。
根本で理解を得られないのですから、親切にご回答をいろいろ寄せていただいても、
うまくコミュニケーションが成立するはずがない、と。
これは「私だけがこだわりの強いプロだ」なんていうことではないです。逆です。

たとえて言えば、前回のトピックでは、
書体は何か、頻度はどのくらいか、といったことの確認が私に促されましたが、
これは、「そのときの文字の色は何色か」と聞かれているような違和感がありました。
もちろん文字の色によって、この場合の組版の結果が異なるものになる、
という可能性は、私が知らないだけで、まったく排除できるわけではないですよね。
でも、やっぱり違和感が残ります。
違和感を感じるポイントは人によって様々でしょうが、まぁ、そういうことです。

そうした場合に、たしかにおっしゃるように、
>まるさんがもう少し皆さんに言葉多く図を交えて、言いたい事を伝えるべきだった
のだとしても、言葉を費やせば費やすほど、
うまくコミュニケートできる可能性はよりいっそう少なくなるなと思うのです。
質問文の日本語が潜在的に孕むあらゆる読解可能性を事前に想定し、
回答者や閲覧者にとって唯一の解釈だけが選択できるように、
質問者はあらゆる誤解を避けるための努力をしなければいけない、としたら、
質問掲示板は、たぶん成立しないですよね。
逆に言うと、だいじな時間を削って回答して下さるのだから、
回答者に誤解される曖昧な文章を書く質問者が悪いからといって、
回答者も、あいまいな質問から、あらゆる解釈を引きだしてよい、
ということにはならないはずです。

それに、これは「質問」というものの常ですが、
「やりかたがわからない」ということを、「言葉多く図を交えて〔……〕伝える」ことができるなら、
それはもうほとんど解決できたも同然ですから、そもそも質問はしないですし(笑)、
そういう離れ業ができるのでしたら、夜中に掲示板の書き込みなどせず、
もっと要領の良い別の人生をおくっているのではないかと思います。

以上、寝言でした。ぐー。Zzz...

No.200 2007/11/08(Thu) 01:40:54
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.9 (KHTML, like Gecko) Safari/312.6

Re: / KOUJI
> わざわざ矢印+「ベースラインが揃わない」と書いているのに、
> その意味がわからないというのは、どういうわけでしょう。


ボクも画像を見ただけではどの部分を気にされているのかわかりませんでしたし、流れをじっくり読みつつ画像を見比べていってようやく理解できました。
「文字で揃わない」と書くよりも、違いが分かる状態を並べて異なる部分を色で示すなり、線を引いてズレを明示化しないと第三者にはわかりにくいと思いますよ。

> 書体は何か、頻度はどのくらいか、といったことの確認が私に促されましたが、
> これは、「そのときの文字の色は何色か」と聞かれているような違和感がありました。


使用している書体固有の現象なのか、ほかの書体でも再現されるのかを試して、フォントとInDesignのどちらに問題があるのかを切り分けることは、問題解決のために必要なプロセスなのでは?

> 質問者はあらゆる誤解を避けるための努力をしなければいけない、としたら、
> 質問掲示板は、たぶん成立しないですよね。


原因を追及して回避策を考えるうえで、どこを問題としているのか明確ではなく人によって注視する点が変わってしまってしまうようだと論点がずれても仕方のないことだと思います。書き込まれていたレスを見る限り、どこを問題点としているかの確認レスが多かったのでは?
それだけ、どこを問題としているのか理解しきれなかったことと、文字回転をすると起きる現象の認知度が低かったことに起因してのことです。そのうえで、このような書き込みがあれば、感情を前面に出したレスがついても不思議ではないですよね…。

No.201 2007/11/08(Thu) 03:57:32
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: / taopichi
> 検証されているデータでの「ベースラインのズレ」はカーニングで「和文等幅」以外にするとズレが直る。
のついでに、ズレた箇所の前の文字にトラッキングを掛けるとズレが直るのを確認しました。トラッキングの場合はトラッキングの数値を元に戻してもズレが再発生しないことから、座標軸の設定がうんぬんではなくて、単なるInDesignのバグのような気がしてきましたが。
・・・と書いてももう遅いですかね。

> 質問者はあらゆる誤解を避けるための努力をしなければいけない、としたら、
> 質問掲示板は、たぶん成立しないですよね。

すべてのコミュニケーションが発達してきたのも、すべてが自己の意識意図を他者に明確に伝えようとする努力があったからこそではないかと。
老婆心ながら言わせていただくと、仕事として使っているツールの使い方などに疑問を持って、それを努力してなんとか解決しようとしないのは、プロ意識が足りないのでは?と疑われても仕方がないと思いますよ。皆さんと職種が違う(たぶん)のであえて言いますが、組版屋さんにゲラを出してもらって数回のやり取りの後に、私の求める組版が出てこないときは平気で「このオペレーターさんにもうやらせないで」と指示を出します。
仕事でツールを使うならそんなこともあるということを理解して、努力を・・・ってことで。と、書くと皆さんから反発をくらいそうですが、まるさんの書き込みにはそう思わざるを得ませんでした。KOUJIさんがうまくまとめてくださったのに失礼しました。

No.202 2007/11/08(Thu) 08:43:31
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: / あぁ
まるさんへ
私の先の投稿で まるさんを責めているのではありません。
その様に受け取られたら謝ります。

私の投稿内容の訂正をさせてもらっていいですか。

>たぶんその時点で篠原酒店さん他、明確に理解されていなかったのではないでしょうか。
この一行削除させてください。皆さんに失礼でした。

>ようは、まるさんがもう少し皆さんに言葉多く図を交えて、言いたい事を伝えるべきだったのでしょう。
「質問者は、子供に説明する様に、解り易い言葉とできれば図を交えて、問題箇所を伝えるといいのでしょう。」に書き換えたいと思います。

お互い、顔を突き合わせていれば、
「ベースラインがズレているでしょ」
「下の和文と合っていない事?」(私は最初そう思いました)
「違うよ、この"TES"がズレてるじゃん」
ってな事になるんでしょうけど ^^
伝える努力は必要よ。

>「やりかたがわからない」ということを、「言葉多く図を交えて〔……〕伝える」ことができるなら、
>それはもうほとんど解決できたも同然ですから、そもそも質問はしないですし(笑)

そうかなぁ。。。

つまらない投稿ごめんなさい。

No.203 2007/11/08(Thu) 10:16:33
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: / まる
KOUJIさま
>使用している書体固有の現象なのか、ほかの書体でも再現されるのかを試して、フォントとInDesignのどちらに問題があるのかを切り分けることは、問題解決のために必要なプロセスなのでは?

最初の質問でフォント名を書かなかったのは、
問題の切り分けをした後だったからなのですが。
じっさい、フォントの種類は関係ないと思います。

ただ、たしかに「フォントとInDesignのどちらに問題があるのか」を
まず確認すべきと考える人には、必要なプロセスです。
同様に、「フォントの色とInDesignのどちらに問題があるのか」、
「カーニングの種類と文字ツメのどちらに問題があるのか」、
「マウスの接続状態とInDesignのどちらに問題があるのか」等々、
ある質問が提出された場合、問題の切り分けのために最初に確認すべきと回答者が考える事項は、
回答者が百人いれば、原理的には百通りありますよね。

今回の場合であれば、問題の切り分けのために必要な情報というのは、
161、169投稿に代表される、「カーニングや、文字前/後のアキ量がどうなっているか」
だったと思いますが、その情報はそのまま解決策となりますので
(その節は本当にありがとうございます)、
問題の切り分けのために真に必要な情報は、回答者から与えられたものなわけです。
問題の切り分けのために必要な情報の見当がつかないので質問するのですから、
それは当然のことです。

でも、じっさいは、多くの場合、案外うまく質問/回答のやりとりができています。
それはなぜかというと、
回答者が「この質問は、自分を回答者として想定している質問だな」と思える質問に、
指向的に回答しているからだと思います。

なので、「InDesignの組版の○○で困ってます!」という質問に対して、
「マウスの接続状態はどうですか?」と書き込む回答者は、
ぜったいピントがずれているとは断言できないとしても、少し困る。
でもそれが困るのは、回答が間違っているからではなくて
(たいてい語っていること自体には間違いがないのですから)、
その回答者自らが「この質問は、自分を回答者として想定している質問だな」とは、
ぜんぜん思っていないことが如実にわかるからですね。
だからお互いに言葉を重ねれば重ねるほど、当初の質問から離れてゆくわけです。

taopichiさま
>すべてのコミュニケーションが発達してきたのも、すべてが自己の意識意図を他者に明確に伝えようとする努力があったからこそではないかと。

そうでしょうか。
有史以来「自己の意識意図を他者に明確に伝えようとする努力」が
営々と続けられてきたことをよしんば認めるとしても、
それによって「すべてのコミュニケーションが発達してきた」とはとても言えず、
むしろ逆にどんどん退化しているのでは、と思います。
「tao」さんのお名前にちなんで言えば、太古の人間が行なっていた大地や海、空や植物との交感が、
現代では壊滅的になっているとも言えるのではないでしょうか。

>組版屋さんにゲラを出してもらって数回のやり取りの後に、私の求める組版が出てこないときは平気で「このオペレーターさんにもうやらせないで」と指示を出します。

「このオペレーターさんにもうやらせないで」と指示を出す前に、
「私の求める組版」のための指定はきちんとしていたんでしょうか。
指定がきちんとしていたのに、「私の求める組版」が出てこないなら、
それはオペレータ個人の責任というより、「品質管理体制」などもう少し大きな問題では。
たぶん、そういう印刷所(?)は、オペレータを替えても同じ結果か、今後より悪い結果を招くと思います。

No.210 2007/11/09(Fri) 02:04:17
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.9 (KHTML, like Gecko) Safari/312.6
「プロポーショナルメトリクス」とカーニングの「メトリクス」 / satoshi
OpenTypeのヒラギノ、小塚、フォントワークスでは、「プロポーショナルメトリクス」とカーニングの「メトリクス」は同じなのでしょうか? 違うのであればどういう意味で違うのですか? 見た感じ同じように詰まりますよね。
また、和文を詰めるのは「文字ツメ」でと、確かここのサイトでもかかれていたように思いますが、なぜ「プロポーショナルメトリクス」、「メトリクス」や「オプティカル」ではなく「文字ツメ」を使うのか? そして「文字ツメ」を使うのであれば、「プロポーショナルメトリクス」、「メトリクス」や「オプティカル」は何のために(用途に)存在する機能ですか?

No.92 2007/11/01(Thu) 12:01:41
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / いき URL
> 何のために(用途に)存在する機能ですか?
一応開発者が意図した用途はあることでしょう。
ですがそれはユーザーが決めればよいことだと思いませんか?
あとは、こちらのStudy Roomをご一読いただければよろしいかと。
http://study-room.info/id/study/main/study10.html
http://study-room.info/id/study/main2/study18.html
http://study-room.info/id/study/main2/study87.html
http://study-room.info/id/study/cs3/study24.html

No.94 2007/11/01(Thu) 12:33:51
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / YUJI Email URL
> 「プロポーショナルメトリクス」とカーニングの「メトリクス」は同じなのでしょうか?

「メトリクス」は「プロポーショナルメトリクス」を適用したものに、
さらにペアカーニング情報をもとに文字を詰めます。
詳細は、Study Room CS3 No.24を参照して下さい。

> なぜ「プロポーショナルメトリクス」、「メトリクス」や「オプティカル」ではなく「文字ツメ」を使うのか?

「メトリクス」や「オプティカル」はもともと欧文用に付いていた機能で、
「文字ツメ」は和文用に搭載された機能です。
必ずしも「文字ツメ」を使わなければならないということではないですが、
和文には「文字ツメ」が推奨されていたかと思います。

> そして「文字ツメ」を使うのであれば、「プロポーショナルメトリクス」、「メトリクス」や「オプティカル」は何のために(用途に)存在する機能ですか?

ひとくちに文字を詰めるといっても、言語(国)やフォントによって、詰め方やルールはさまざまです。
また、フォント内に持つ情報もフォントによって異なります。
#例えば、「プロポーショナルメトリクス」はOpenTypeフォント以外では使用できないし、
 ペアカーニング情報の有無もフォントによって異なります。

InDesignの持つさまざまな文字を詰める機能を、用途や目的によって使い分けられるという意味でも、
選択肢が多いのは良いことではないかと思います。

No.95 2007/11/01(Thu) 12:34:12
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/522.11.1 (KHTML, like Gecko) Version/3.0.3 Safari/522.12.1

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / YUJI Email URL
すいません。追記です。

「メトリクス」は和文のペアカーニング情報も参照します。
「プロポーショナルメトリクス」も、和文フォントの場合には
仮名や約物のデザインを考えて付けられた機能だそうです。
ちなみに「オプティカル」のみ欧文専用の機能となるそうです。

No.96 2007/11/01(Thu) 13:19:52
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/523.10.3 (KHTML, like Gecko) Version/3.0.4 Safari/523.10

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / (-_-メ)
> InDesignの持つさまざまな文字を詰める機能を、用途や目的によって使い分けられるという意味でも、
> 選択肢が多いのは良いことではないかと思います。


選択肢が多いってことは、結局迷う要素も多いということで、必ずしもそれがプラスに働くというわけではないので、一概には喜べないですねぇ。

YUJIさんのように、積極的に情報収集・公開してくれる方がいるので非常に助かりますが、本来こういうことはアドビ自身が、専用のページを作ってでももっと詳細に説明すべきと思います。セミナーでだけでしかこういった情報が得られないのはとても残念なことです。

こういうややこしい機能については、積極的に情報収集している人たちだけが分かっていて、その他のほとんど人たちはあまり理解しないまま使っているので、もうなんだかわけのわからないぐちゃぐちゃな文字詰めの組版をしてしまっている人のデータをよく見ますよ。

アドビには、もう少しうまくスマートにまとめてもらえないかなぁと思っています。

No.98 2007/11/01(Thu) 14:14:00
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / 篠原酒店
(-_-メ)さん

確かに「調整できるパラメータの種類や範囲が多い」と戸惑うのは間違いないですね。
コンピュータの性能が上がったからといって、「できるからあらゆることをする」というより「むやみに何でもできるようにするのはやめる」ことも、OSやアプリケーションの設計方針としては必要じゃないかと思います。

No.101 2007/11/01(Thu) 16:01:34
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / いき URL
> OSやアプリケーションの設計方針
そう単純な話ではないのでは。
OSは1種類ではありません。
アプリのメーカーとある程度連携をとることができるとしても、同じ会社が開発しているわけでもありません。
フォントもしかり。プロポーショナルメトリクスをはじめとする組版支援機能は、あくまでOTFの機能であり、InDesignの機能ではありません。

なお、一方の機能があるから一方を削るという取捨選択は、ユーザー側に委ねられた方が都合が良い場合が多いのではないかと思います。
ああ、もちろん私見に過ぎませんけれどもね。

No.102 2007/11/01(Thu) 16:20:33
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / KOUJI
ヘルプの「カーニングと字送りについて」にカーニングは欧文の文字間を調整するための機能と書かれてはいますよ。それとは別に「日本語組版で文字ツメを調整するには」という項目もありますし。

解説原稿なんかを書くときはマニュアルなりヘルプを頼りにして、あとは実際に検証して理解を深める。ということの繰り返しだったりします。このヘルプなりの手元にある情報から検証を数多くやる人が自然と詳しくなっていくのだと思いますよ。

No.103 2007/11/01(Thu) 16:30:23
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / (-_-メ)
> フォントもしかり。プロポーショナルメトリクスをはじめとする組版支援機能は、あくまでOTFの機能であり、InDesignの機能ではありません。
OTFが持っている機能ではありますけれども、それを使えるようにするかどうかはInDesignの設計にかかるわけですよね。

> ユーザー側に委ねられた方が都合が良い場合が多いのではないかと思います。
それは使い方を理解している・する気のある人なら、という前提だと思っています。先の投稿にも書いたとおり、よく理解しないまま触っている人が多いので、下流でデータを受け取る者(私)としては、「もはやどうにもならない」状態のデータを見るのに耐えられません(^^;)

InDesignユーザーとなったからには、せめてこのサイトを隅から隅まで読んでおけ!と、言いたい(誰にだよ(笑))

No.104 2007/11/01(Thu) 17:01:07
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / いき URL
篠原酒店さん>>
すみません、いつもの悪いクセで、文章の一部分だけを読んで脊椎反射してしまいました。
論点がズレちゃってますね。

あと、OTFの件に関する私の書き方は正しくないですね。
組版支援機能はOTFの仕様であり、InDesign側からそれらの機能にアクセスできるように設計されているわけなので、やはりInDesignの機能の一部ですね。

No.105 2007/11/01(Thu) 18:15:17
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / 篠原酒店
私は今のところ、(-_-メ)さんと同じ見解を持っています。
同じInDesignユーザーでも、YUJIさんやKOUJIさんのようにアプリケーションの機能解説をエンドユーザーの立場で率先して行い、他のユーザーの方に情報を伝えたいと考える方と、そういった解釈情報を受け取ってアプリケーションを操作するユーザーの方とでは、アプリケーションへ向き合う自主性が違うと思います。
自主性の違いは自ずとスキルの違いに結びついていくと考えています。
だからこそ、(-_-メ)さんが書いていらっしゃる、
「もうなんだかわけのわからないぐちゃぐちゃな文字詰めの組版をしてしまっている」(文字詰め機能に限りませんが)データが「出来上がって」しまい、他のユーザーの方が混乱してしまう状況を避けるためにも、アプリケーションの機能を限定的にする設計をしてもいいのではないかと思うのです。

また、KOUJIさんが
>手元にある情報から検証を数多くやる人が自然と詳しくなっていく
と書いていらっしゃいますが、私はそうとも限らないと思います。
検証作業と情報解析のレベルの掘り下げが浅い場合は、どれだけ場数を重ねても操作回数を増やすだけでスキル向上にはつながらないと思いますが、いかがでしょうか。

No.106 2007/11/01(Thu) 19:56:59
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / pi&pu
僕は基本的にはYUJIさんやいきさんの意見に賛成です。

日本語という世界に類を見ない文字種を使用する言語では、求められるカーニング機能も当然多くなるし、アプリケーション側だけでカーニング値を決定するにも限界があるでしょう。どこまでが必要最低限かを線引きするのは非常に難しいと思います。。。

ページレイアウトソフトって、やはり「プロフェッショナル」が使うアプリケーションだと思います。プロフェッショナル用である以上、ありとあらゆる要求に答えることを求められるのは、必然だと思います。当然、使いこなすにはユーザ側にもそれなりのスキルが求められる。。。将来的にInDesignの簡易版「InDesign Elements」なるものが登場して、「あなたはスキルがないのでElementsで作成して納品してください」…なんてことになるとは、ちょっと考えにくいです。。。

ともあれ、Adobeはもうちょっとユーザーフレンドリであってもいいとは思います
(^^;

No.107 2007/11/01(Thu) 23:08:14
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / 篠原酒店
ちょっと脱線ですが、複雑な機能を使いこなせる「プロフェッショナル」を育てる時間がなく、技術が未熟なオペレータに仕事を流さざるを得ないという現状も改善していかなければいけないと思います。
「プロフェッショナルでなくとも実務にあたれる環境にしたほうがいい」と提案して矛盾するようですが、「InDesignはプロが使うべきアプリケーション」というお考えは私も同感で、機能をきちんと把握したレベルに達してから実作業に当たるという環境を各企業で整えてほしい。
ただ、教えるほうも何を基準に「プロフェッショナル」と線引きが出来るかどうかは難しいですが。

もうひとつアプリケーションメーカーに考えてほしいのは、コンピュータについての専門用語を当てはめた「機能名」「コマンド名」を工夫してもらえないだろうかということです。
この辺にはプログラム言語や開発の現場で使う単語などが顔を出すことがありまして、知識のない一般ユーザーに戸惑いを与える元凶になっていないかと思います。多分英単語のコマンドを和訳しきれずに、開発側が日常的に使っている「オーバーライド」などといったコマンド名をつけてしまっているのではないかと。
「マスターページをオーバーライド」では分かりにくいですが、
「マスターページを上書き」なら分かりやすいと思います。

No.110 2007/11/02(Fri) 00:36:35
Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / satoshi
皆さんの貴重な意見ありがとうございます。大変勉強になりました。
個人的には、Illustrator10までの「詰め」機能(程度の物)でいいんだけどと思ってます。

>和文には「文字ツメ」が推奨されていたかと思います。
「プロポーショナルメトリクス」や「メトリクス」では約物類の詰めがおかしくなることがあるのですか? 「オプティカル」でおかしくなったことはありますが。
個人的には、かなだけ詰まって約物類の位置がおかしくならないのがあれば言うこと無いんだけどな

>「機能名」「コマンド名」を工夫してもらえないだろうか・・・・・「マスターページをオーバーライド」では分かりにくい・・・・・
自分は、段落揃えの「ノド元に向かって整列」と「ノド元から整列」。日本語なのにすごくわかりにくいですね。「ノド元」ってノド側? それとも小口側? どっちなんでしょ?
左揃え、中央揃え、右揃えなんだし
「ノド元に向かって整列」は「ノド側揃え」
「ノド元から整列」は「小口側揃え」のほうがわかりやすくないですか?

No.115 2007/11/02(Fri) 11:26:00
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: 「プロポーショナルメトリクス」とカーニングの「メトリクス」 / n-yuji URL
文字詰め機能について、当方の見解をここ↓に書いておきました。
http://d.hatena.ne.jp/n-yuji/20071103#p1
上の回答者さんたちの意見とは異なっているところがありますが、
質問者のsatoshiさんには、こちらの方が納得がいくのではないかと思います。

No.199 2007/11/07(Wed) 22:03:56
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
特定の文字から始まる段落の一括置き換え / 山ちゃん
お世話になります。
都合の良い考え方で恐縮なのですが、以下2点につきまして、どなたかお教えいただければ幸いに存じます。InDesign CS2(Win)を使用しております。


1. 特定の文字から始まる段落の一括置き換えについて

      一章-abc
      本日は晴天なり。
      2007.11.1
      一章-def
      民主党が混沌としています。
      2007.11.2
      一章-ghi
      我が輩は猫である。
      2007.11.3


上のようなテキストが延々と(数千本程度)続くのですが、「一章」から始まる段落を、一括して改行マークに置き換えることはできるのでしょうか?


2. 段落スタイルの一括指定について

上のようなテキストにおいて、日付(2007.11.1 など)の段落のみを、一括して、ある共通の段落スタイルに指定することはできますでしょうか?



本来であればテキストエディタでやってこなければならない作業もあると思いますが、「一太郎で全漢字にルビふり」→「Wordファイル変換」→「InDesignへのコンバート」の行程に法外な時間を要しますので、InDesign上で行えたらと思っております。
宜しくお願いいたします。

No.181 2007/11/07(Wed) 09:17:51
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)

Re: 特定の文字から始まる段落の一括置き換え / KOUJI
正規表現を使った検索/置換をおこなうスクリプトがあるので、それを使うと楽に変換できると思います。

いんでさいんnoすくりぷとさん
http://www2s.biglobe.ne.jp/〜jxli/script/searchrepln.html

No.183 2007/11/07(Wed) 09:57:12
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Re: 特定の文字から始まる段落の一括置き換え / 山ちゃん
KOUJIさん、ありがとうございます。
早速、試してみます。
またレポートさせていただきます。

No.187 2007/11/07(Wed) 10:36:01
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)

Re: 特定の文字から始まる段落の一括置き換え / お〜まち URL
まずはスクリプトで試していただくとして。
ひとつ疑問なのですが、
>「一章」から始まる段落を、一括して改行マークに置き換える
必要があるのでしょうか。単に印刷したくないだけなら、文字の塗りを「なし」にしても問題がないケースもあります。

その場合さらに、「一章」から始まる段落と日付の間の段落数が固定であれば、Study room CS2のNo.11
次のスタイルを適用
http://study-room.info/id/study/main4/study11.html
が使えるんですがね。
場合によっては全て段落スタイルで片付くこともありえますね。

No.192 2007/11/07(Wed) 14:38:26
Opera/9.24 (Windows NT 5.0; U; ja)

Re: 特定の文字から始まる段落の一括置き換え / 山ちゃん
お〜まちさん、ありがとうございます。
私も一丁前に、アプリケーションのグレードだけ上げても、その付加された機能を知ることもなく使用する傾向がありますので、反省しております。
確かに構成する段落数は固定ですので、おそらくこの方法のほうが、私にとってはやりやすいと思いますので、試みてみます。しかしながら、今後のための勉強として、スクリプトも試してみます。
それにしましても、この掲示板は本づくりが楽しくなりますね。

No.198 2007/11/07(Wed) 18:23:35
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / タケシ
既知の問題であれば申し訳ありません。

AI8で保存したEPSデータをInDesignCS3に貼り付けてPDF/X1aを書き出すと、画像にかけてあったマスクが無くなってしまうという現象が起きています。

ちなみに同じEPSをInDesignCS2に貼り付けると、問題なくPDF作成できます。

Adobeのサポートデータベースではそれらしい記事を発見できませんでした。

何か手がかりになるようなことをご存じの方はいらっしゃいますか?

No.72 2007/10/30(Tue) 21:22:37
Mozilla/4.0 (compatible; MSIE 5.17; Mac_PowerPC)

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / いき URL
手がかり程度ということであれば。

InDesign CS2のPDF書き出しエンジンはAcrobat7.0です。
一方、CS3はAcrobat8.0です。
したがって、同じデータが配置されているからと言っても、同じように書き出せるとは限らないだろうという想像はできます。

当方、Illustrator8.0も保有しているものの、すぐに実験できる状態ではないので想像に頼ったレスになることをお許しください。

CS3から、PSファイルを書き出してDistillerで変換したらどうなりますか?

No.77 2007/10/31(Wed) 16:19:46
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / タケシ
いきさん

情報ありがとうございます。

CS3からのPS書き出し→distillerの結果です。

PPD:AdobePDF7.0 distiller7で変換 成功
PPD:AdobePDF8.0 distiller7で変換 成功
PPD:デバイスに依存しない distiller7で変換 成功

PPD:AdobePDF7.0 distiller8で変換 成功
PPD:AdobePDF8.0 distiller8で変換 成功
PPD:デバイスに依存しない distiller8で変換 成功

ということで全て不具合無くいきました。

InDisignCS3からの書き出しについては、貼り込みデータの保存形式を変えていろいろ試してみました。以下その結果です。

  AI10でEPS保存 ×
  AICS1でEPS保存 ×
  AICS2でEPS保存 ×
  AICS3でEPS保存 ×

  AI8で保存(画像含む) ×
  AI10で保存(PDF互換) ○
  AICS1で保存(PDF互換) ×
  AICS2で保存(PDF互換) ×
  AICS3で保存(PDF互換) ○

ということで、AI10とAICS3のPDF互換ネイティブを貼り付けた場合のみ正しい状態のPDFが書き出せました。

他にも、画像の埋め込みをしたり下位保存を試したりも織り交ぜましたが、煩雑なので省略します(ことごとくダメでした)。

とりあえずInDesignCS3は使用禁止令が発令されそうです。

No.78 2007/10/31(Wed) 20:35:09
Mozilla/4.0 (compatible; MSIE 5.17; Mac_PowerPC)

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / 篠原酒店
InDesignCS3のEPSデータをDistillerにかけてPDFに変換した場合はどうなるでしょうか?
No.79 2007/10/31(Wed) 22:30:36
Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / pi&pu
確認なのですが、AI8でクリッピングマスクをかけている画像はグレースケール画像ですか?

こちらでもグレースケールeps画像で同様の現象がありました。
これをすべての画像で、というわけではありませんでした。。。。

No.82 2007/10/31(Wed) 23:28:55
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / タケシ
pi&pさん

CMYK画像です。

篠原酒店さん

試してみたところうまくいきました。

やはりアプリからの直接書き出しなぞ信用するなという、昔ながらの原則が生きているのでしょうか?

No.83 2007/11/01(Thu) 09:48:38
Mozilla/4.0 (compatible; MSIE 5.17; Mac_PowerPC)

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / あさうす Email URL
すべてWindows版ですが、
Photoshop CS3(10.0.0J)、Illustrator 8.0.1J、
InDesign CS3(5.0.1J)で各々データを作ってみましたが
直接出力時でも現象確認できませんでした。

今回の場合、配置画像の作成アプリ・バージョンなども絡んでいると
思われますので、そちらの確認も必要かもしれません。

ただ、Distiller経由であれば回避できる、ということが判明しているので
そちらの運用で良いのではないでしょうか。
直接出力は過去バージョンでもトラブルが発生するケースがあるため、
問題ないことを確認できない限りは利用しないほうがベターだと
個人的には考えています。

No.91 2007/11/01(Thu) 11:30:27
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / 篠原酒店
> 試してみたところうまくいきました。
>
> やはりアプリからの直接書き出しなぞ信用するなという、昔ながらの原則が生きているのでしょうか?


詳しいことはなんともいえませんが、結果からするとそうかんぐりたくもなりますね。
余所でPDF出力依頼をする場所があるので、この方法を打診してみます。

No.93 2007/11/01(Thu) 12:33:06
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / どん
ウチでも同じ現象が頻発して困ってます

現在確認できてる事は

1 win mac共に起こる
2 モノクロ・カラー共に起こる
3 マスクのかかっている画像が2枚重なると、
 かなりの確立で起こる



Distiller経由で回避してますが、書き出したPDF
をacrobat8から印刷すると、縦組みOTFの部分が
ずれたり(7からだとずれない)と不安定な為、
職場ではCS3は様子見の雰囲気が漂っていますね

No.123 2007/11/03(Sat) 22:10:58
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / タケシ
皆様情報ありがとうございます。

どんさんのところでも発生しているのですね。

私、DTP系の掲示板にはなるべく頻繁に目を通すよう心がけているつもりですが、あまり当該現象に関して言及されたトピックを見かけません。本スレッドを立てたのもそのせいですが(自社環境、または特定ファイルに特化した現象なのか?)よそでも発生しているという情報を得て一つ認識が前進しました。

あさうすさん仰るとおり、回避方法が見えている以上は現状下で確実なフローを採用するのがよいのでしょうが、個人的にはかなり釈然としないものを感じています。

PDF/x1aを基盤としたワークフローでは、データの素性を問う必要がないというのが利点だと思うのですが、書き出し方にコツが要るというのでは規定の意味がないと思います。

大きな騒ぎにならないのが不思議ですが、そのこと自体がPDF/x1aの普及具合を物語っているのかなとも思います。

No.175 2007/11/06(Tue) 20:27:00
Mozilla/4.0 (compatible; MSIE 5.17; Mac_PowerPC)

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / いき URL
> PDF/x1aの普及具合を物語っているのかなとも思います。

どの程度普及している(いない)のか、よく知らないのですが。。。
出力環境に左右されることは間違いありません、今のところ。
基本的には出力の際に古くから踏襲してきた、フォントの埋め込みやら透明の分割などを確実に行い、互換性の高い古いPDF形式で保存することを規定したのがPDF/X-1aなんです。
ところが今は過渡期。
PDFワークフローと言いながら、PDFを正しく処理できる出力システムはまだ少ないんです。
どこかの工程で1回はPSファイルへの変換を行っているので、その時におかしくなる可能性がある。

出たばかりのTrueFlow SEとか発表されたばかりのApogeeX 4.0あたりからAPPEを積み、PSファイルを介さず出力できるようになるんです。で、PDF/X-4にも対応、と。
http://www.jagat.or.jp/story_memo_view.asp?StoryID=10792

で、CS3からの直接書き出しに期待していたところに、今回の不具合。
今後のバグフィックスで正しく書き出せるようになることを祈るばかりです。
それまでは、distillerで……。

No.176 2007/11/06(Tue) 21:14:25
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / MM岩手
> いきさん

・書き出せない
・出力できない

それぞれは別の問題ですよね ^^;


> PDFワークフローと言いながら、PDFを正しく処理できる出力システムはまだ少ないんです。

「PDFを正しく処理できる出力システム」とは何を指すのか疑問です。
# 以下、話の流れからPDF/X-1aの「出力」に限定します。

現状では、
・オーバープリント指定を正しく再現できない。
・Separation(やDeviceN)記述のオブジェクトに対して、正しいカラーマネジメントが働かない。
・演算精度が最終出力RIPと異なるために微妙に出力結果が異なる(マイター角の形状が変化する)。
といった、問題をクリアできないPostScript「プリンタ」が大半を占めます。
# というか、すべてクリアしたPostScriptプリンタはおそらく存在しない。もし、完全に正しいPDF/X-1aの分版出力結果をプリントするためには、最終出力RIP機でTIFFに分版して、合成した画像をプリンタ出力しないと無理みたいです。

幸か不幸か、私はAcrobatのオーバープリントプレビュー表示(できれば分版プレビューON)と、最終出力RIPで分版出力した結果が異なるPDF/X-1aを見たことがありません。
# 古いAD-810MXでも、設定さえ正しく行えば(RIP固有の補助を全てOFF=Adobe純正RIPモード)、Acrobatのオーバープリントプレビュー表示と出力結果は常に一致してます。
なので、現状ではほとんどの「出力システム」が、PDF/X-1aを正しく分版出力できると私は思っています。

現状、PostScriptプリンタで正しいPDF/X-1aの出力見本を作ることは困難です。しかし、そもそもPDF/X-1aはPDFデータが出力見本を兼ねるために必要な要素(出力インテント)を含んでいます。PDFの他に、別途出力見本を付けないよう運用する(Acrobatのオーバープリントプレビュー表示を出力見本とする)なら、実際、PDF/X-1aは問題なく運用できる段階にあると思っています。

p.s.
PDF/X-1a:2001(PDF1.3)って、もう6年も前の規格ですね。いつのまにか、InDesignから直接PDF/X-1aを書き出せる(ときもある)ようになってしまった。最近は情報が入り乱れて、PDF/X-1aの本質を見抜くのは難しくなってきてるのかもと思ったり。

No.189 2007/11/07(Wed) 10:58:18
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP-mac; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Re: InDesignCS3とAI8のEPSの組み合わせでマスクが飛ぶ / いき URL
MM岩手さん>>
お久しぶりです(^^;
ご指摘ありがとうございます。
大変勉強になりました。

私は、自社での少ないエラーの事例を念頭に置いてレスを書いてしまいました。
考えてみればRIP固有の設定の問題や、PDF/X-1aの規格には本来含めてはならない部分の混じったデータの問題などが含まれるため、決して一般論ではありません。
失礼しました。

No.190 2007/11/07(Wed) 11:08:41
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
InDesignCSで合成フォントのTimes数字が2つ繰り越される。 / オジャパメン Email
同じような経験をされた方はいませんでしょうか?

InDesignCSの合成フォントが使用されたファイルで半角数字に割当てた数字が、PS書き出しを行なうと2つ繰り越されてしまう。
PSをディスティラーとRIPでPDFに変換して確認しています。

つまり「2」が「4」、「1」が「3」というように丁度2つ上の数字に置き換わる現象です。

ページもののデータなのですが、数ページに渡って同じ現象が起きています。
PS書き出し後のInDesignファイルの数値には異常は有りません。

環境はMacOS10.3.9のG4です。


フォント自体を元のシステムフォントに有った「Times.dfont」から、作成環境で使用していたものに入れ替えたのも原因の一つかもしれないのですが。

どなたか、同じ現象に遭遇して原因が解った方がいたら教えて下さい。

No.177 2007/11/06(Tue) 21:59:08
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP-mac; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
全1904件 [ ページ : << 1 ... 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 >> ]