[ 掲示板に戻る ]

過去ログ閲覧モード

InDesignのCS5.5アップデートファイル / taizou
Adobeによる過去バージョンの切り捨て問題もあり、
当面InDesign CS5.5を使い続けたいと思っています。
パッケージ版で所有していて、
幸いなことにMacではなくWindows10で使っていますので、
CS6のように突然インストールができなくなる、
といった事態はないかと思います。

ただ、ここで問題なのがパッケージだと
CS5.5初期のバージョンしか入らないということです。

初期CS5.5のバグはかなり多いので、7.5.3に上げるのは必須なのですが、これってもうオフラインアップデートファイルとしての配布はしていないんでしょうか?

アップデート時代はCS5.5アプリケーションのAAMからなら
出来るのですが、これもいつ打ち切られるのか…。
Adobeサイトからはオフライン用アップデータがDLでき
なくても、AAMのテンポラリフォルダからでも引っこ抜ければいいのですが、そんなことってできるものでしょうか?
(ぱっと見たところではPlugin関連のファイル追加以外は
更新していないようにも見えるのですが…)

No.9673 2019/10/03(Thu) 12:35:25
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Re: InDesignのCS5.5アップデートファイル / あさうす
残念ながらアップデータページ、ftpサイト等など、単体アップデータの配布はすでに終了しています。
Adobe Application Managerもいつまで更新できるかは不透明です。

OSサポート外もあるわけですから、いつまでも利用できる、というわけではありません。
(Windows 10も毎回の機能アップデートで互換性も徐々に失われてるところもあります)
個人利用で不具合があっても対応できるものであったり、業務利用でも完全クローズ運用で、問題も理解しながら対応ならいいのですけど、そうでない限りは今後の運用は難しいと考えるしかないでしょう。

No.9675 2019/10/03(Thu) 20:21:42
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
表のセル幅 / カオリ
いつもお世話になっています。

InDesign CC2019を使用しています。
表のセルの幅を、入っている文字の一番長いものにピッタリ合わせたいのですが可能でしょうか。
セルとセルの間の空きを統一するために必要としています。

検索もしてみたのですが、探し方が悪いのか見当たらず。

よろしくお願いいたします。

No.9662 2019/09/19(Thu) 14:43:12
Mozilla/5.0 (iPhone; CPU iPhone OS 12_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.2 Mobile/15E148 Safari/604.1

Re: 表のセル幅 / お〜まち URL
機能としてはありません。
表でなければならないのなら、自分で行長を計算してセル幅を変更する以外ないと思います。
もし、テキストフレームの集合でもよいなら、列ごとにテキストフレームを作成すれば可能です。

No.9663 2019/09/20(Fri) 07:41:25
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.110 Safari/537.36 Vivaldi/2.7.1628.30

Re: 表のセル幅 / カオリ
お〜まち様

遅くなって申し訳ありません。
お〜まち様にない、と教えていただき諦めがつきました。

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

No.9674 2019/10/03(Thu) 16:58:21
Mozilla/5.0 (iPhone; CPU iPhone OS 12_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.2 Mobile/15E148 Safari/604.1
「また使うかもしれない部品」のPB保管 / たらこ
インデザインのPBに部品を置くことついて、皆さんどのように管理されてますか?
特に実務でトラブルがあったわけではないですが、もっといい管理法がないかなあ、と考えています。

私は「今回は修正したけど、やはりもとに戻して」といわれることへの対応として、よくページ外に部品やら文字やら置いています。
ただ、ページの増減をする際に、妙な位置に移動したり、画面外に飛んでいってしまうこともあって、邪魔だなあ、と思うことが多々あります。

ページ左右じゃなく上下に置けば、増減しても付いてきますが、領域が狭すぎるし…。

スニペットにすると、中身をいちいちドラッグするなりブリッジなりで見ないと行けないのが面倒、ということで、大抵は存在自体を忘れて、数年前のスニペットがデスクトップの謎フォルダに転がっていたりします。

やはりPBが一番楽ではあります。

かつて、ダミーのマスターを作り、そこを部品用として使っていましたが(誤って使わないよう背景に変な色を引いていました)、それもまたスニペット同様、存在を忘れてしまうんですよねえ。

No.9667 2019/09/23(Mon) 09:01:24
Mozilla/5.0 (Linux; Android 9; ANE-LX2J) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Mobile Safari/537.36

Re: 「また使うかもしれない部品」のPB保管 / (z-) URL
>ページ左右じゃなく上下に置けば、増減しても付いてきますが、領域が狭すぎる

ものすごく古いバージョンでなければ、
環境設定 > ガイドとペーストボード > 垂直マージン
で天地のペーストボード領域を広げられます。

うちも左右のペーストボードに捨てる派ですが、台割確定後に開始ページが奇遇入れ替わると、どさっと邪魔されますね確かに…

No.9668 2019/09/24(Tue) 12:25:17
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8

Re: 「また使うかもしれない部品」のPB保管 / お〜まち URL
ペーストボードは使わない派です。
多分、視界に余計なものが入るのが嫌なんでしょうね。

どのページに置くか決まらないものについては、本文で使わないマスターページ(Z-マスターにしてる)に、
特定のページに結びつくものは非表示・非印刷レイヤー(部品レイヤーとか予備レイヤーとか)に置いてます。

No.9669 2019/09/24(Tue) 14:55:34
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.78 Safari/537.36 Vivaldi/2.8.1664.35

Re: 「また使うかもしれない部品」のPB保管 / Uske_S URL
僕もPBは全く使いません.
部品などを取っておく場合は部品のテキスト部分などを〓にした流し込み用のものを,あえて別のドキュメントに取っておくようにしています.
部品だけを見たい・確認したいというケースが僕にはあまりないので,特別に不自由は感じていません….

脱線しますが,「もとに戻して」という指示を許容しないほうが僕はいいと思っています.
もちろん対応せざるを得ないこともありますが,そういう場合は「バックアップからわざわざデータを復元させたりして対応するので,基本的にはもとには戻せません」ということをお客さん・営業含めて話をしていったほうが生産的かなーと.
仕事にもワークフローにもよるので一概には言えませんけど.

No.9670 2019/09/25(Wed) 15:30:56
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36

Re: 「また使うかもしれない部品」のPB保管 / ジーコ
私もPBは使いませんね。というか、そのようなデータを受け取ったらまずはPBのそういったものを削除するところから作業開始します。無駄にデータを喰っているわけですし(ガイドラインもスクリプトでいったん全削除します)。

多数のパーツが必要なライブラリを使います。ちゃんと位置情報も記憶しているので配置も簡単ですし。数が少ない場合は、同種のパーツをコピーしてきて同位置にペーストして書き換えたりしています。

ただまあ、InDesignをデザインメインの業務で使うのか、組版メインの業務で使うのかによって、対応はだいぶ違うと思いますね。私は組版メインの業務なので、そもそもそういった面での試行錯誤はほとんど発生しません。

No.9671 2019/09/25(Wed) 17:14:00
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Safari/605.1.15

Re: 「また使うかもしれない部品」のPB保管 / たらこ
みなさんありがとうございました。

意外にもPBを使ってない方が多くてびっくりしました。
私はいろいろな人と共同で仕事することが多いのですが、
全員、普通にPBをかなり駆使していますね。

ただ、やはり出力(印刷)や、あとあとを考えると、
PBを使わないに越したことはないというのもわかります。
何がトラブルのもとになるかわからないですし、
何より、PDFではなくInDesign形式でデータ入稿の場合は、
致命的な結果につながるかもしれませんね・・・。

InDesignのPBは、初期からもともとそういう仮保持用途の
領域だったと記憶しているのですが、
イラレのアートボード外に本体そのものの古いバージョンを
いくつも置いてある方もいたりして、それは正直とまどった記憶があります。
(もちろんデータが異常なサイズになっています)

まあ、何より過去バージョンに書き戻しする作業が
発生しない(営業に厳しく進言する)のが一番ですよね…。

No.9672 2019/09/27(Fri) 08:05:22
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
もしかしてitemByNameの使い方間違ってます? / Subi
Windows10, InDesign CC2018です。

マスターページのテキストフレームにレイヤーパネルで「ボックス」とオブジェクト名をつけ、流し込みを行いました。
その後各ページの「ボックス」を移動・変形しようと以下のスクリプトを書きましたが、先頭のスプレッドしか反映されません。
ご助言をお願いします。

app.activeDocument.viewPreferences.rulerOrigin = RulerOrigin.SPREAD_ORIGIN;

var doc = app.activeDocument;
var txtB=doc.textFrames.itemByName("ボックス")

for (i=0;i<doc.spreads.length;i++){
try{
txtB.visibleBounds = [7, 7, 12.5, 24];
}catch(e){
}
}

No.9664 2019/09/21(Sat) 11:38:57
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Re: もしかしてitemByNameの使い方間違ってます? / お〜まち URL
Subiさんならこれを実行すればでわかるでしょ
var doc = app.activeDocument;
var txtB=doc.textFrames.itemByName("ボックス");
for (i=0;i<doc.spreads.length;i++){
$.writeln(txtB.contents.slice(0, 9));
}

No.9665 2019/09/21(Sat) 14:40:39
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.110 Safari/537.36 Vivaldi/2.7.1628.30

Re: もしかしてitemByNameの使い方間違ってます? / Subi
うわー。直しました。これじゃ一つしかヒットしないですよね。

app.activeDocument.viewPreferences.rulerOrigin = RulerOrigin.SPREAD_ORIGIN;
var doc = app.activeDocument;
for (i=0;i<doc.spreads.length;i++){
var txtB=doc.spreads[i].textFrames.itemByName("ボックス");
try{
txtB.visibleBounds = [7, 7, 12.5, 24];
}catch(e){
}
}



名前に頼らず今の座標で判断するスクリプトも書いたので置いておきます。

app.activeDocument.viewPreferences.rulerOrigin = RulerOrigin.SPREAD_ORIGIN;
//ドキュメントのテキストフレームを対象に
var txtFrame=app.activeDocument.textFrames;
var count=txtFrame.length;
for (var i =count-1; i > -1; i--) {
var y = txtFrame[i].visibleBounds[0];
var x = txtFrame[i].visibleBounds[1];
//座標に±0.1mmの誤差を許容
if((Math.abs(y-7) < 0.1) && (Math.abs(x-7) < 0.1))
{
//テキストフレームを移動
txtFrame[i].visibleBounds = [7, 7, 12.5, 24];
}
}

No.9666 2019/09/21(Sat) 15:28:09
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Indesignから印刷用PDF書き出したところスミが全て4色なってしまった / loopa Email
初めまして。
IndesignでPDFを作り印刷所に入稿したところ、全てスミ班が
4色スミに変わってしまいました。
今までこんなことになったことがなく、入稿の仕様に合わせて作ったPDFの色分解も、いじってないです。

環境は
Macです。OSは10.14.6です
Indesignは2019です。

カラー設定は
Japan Color coarted

PDFの色分かの設定は添付です。

こうなってしまった原因が知りたいです。
よろしくお願いいたします。

No.9659 2019/09/10(Tue) 13:26:28
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

Re: Indesignから印刷用PDF書き出したところスミが全て4色なってしまった / Uske_S URL
loopaさん、こんばんは。

データがどういうものかわからないので、なんとも申し上げにくいです。

4C掛け合わせの黒になったということは、RGBで書き出してしまったとかかなとか、X1aで出力していらっしゃるようなので透明が関係するのかなとか、さまざまな理由が考えられそうです。

ただ、カラー変換を「出力先の設定に変換」とされているのがよくわからなくて、データが適切にカラーマネジメントされていればそこは「カラー変換なし」のほうがトラブルがないように思います。
これを「カラー変換なし」にしても同じように黒が4Cで出力されるでしょうか。

あとこんなことを僕が言うのも差し出がましい話なのですが、印刷用のPDFは最後Acrobatなどで版の確認をしないといけないのではと思います。
特にAcrobatにはプリフライトという強力なツールがありますので、データの品質を確保する意味でも導入をおすすめします。

No.9660 2019/09/10(Tue) 23:48:26
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

Re: Indesignから印刷用PDF書き出したところスミが全て4色なってしまった / .
X1aなら、PDFにした時点で透明のないCMYKデータになるので、RGBは入り込みませんね。
ですから、RGBによる4色墨なら、印刷所で何らかの操作があったということになります。
渡したPDFに起因しうる問題としては、(4色墨の状態がわからないので、なんとも言えませんが)墨でなくレジストレーションを使ってしまったという可能性くらいでしょうか。

渡したPDFが残っているなら、分版プレビューで確認するのが最初の手順かと思います。

No.9661 2019/09/12(Thu) 10:03:17
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
今更ながら4GBパッチについて / へいじ
いつも参考にさせていただいております。

もはやCCで64bit全盛期の今更なのですが、
まだまだInDesign CS5.5で作業しなければならないことが多くあり、
タイトルの「4GB Patch」を使おうか検討しております。

一時期、話題になったツールなのでご存知の方も多いかと思いますが、
https://ntcore.com/?page_id=371
のものです。

なお、CCとCS5.5環境の両方を使っている関係で、
OSは64bit版のWindowsを使っています。
メモリも16GBくらいあり、導入するとそれなりではあっても
効果はあるのかな、と思っています。

ただ、exeを書き換えてしまうということらしいので、変なことが起きたりしないのか心配です。

ざっとネットで調べた感じだと、過去にInDesignCS5などの時代に使っていた方もいたらしく「処理は早くはならないが安定は増す」らしいことは調べられたのですが…。

使ったことのある方いらしたら教えていただけませんか?

No.9651 2019/08/25(Sun) 21:11:18
Mozilla/5.0 (Windows NT 6.1; rv:64.0) Gecko/20100101 Firefox/64.0

Re: 今更ながら4GBパッチについて / dot
同じ環境で4GBパッチ当てて使用しています

CS5.5に関してはあまり効果は感じませんが、
CS3だとかなり効果があるので一応という感じで
CS5.5にもパッチを当てています

パッチを当てたことによる不具合はないです
書き換え前のexeも残りますので、戻すことは簡単にできます

No.9652 2019/08/26(Mon) 09:08:59
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362

Re: 今更ながら4GBパッチについて / へいじ
ご返答ありがとうございます。
CS5.5ではあまり効果はないのですね…。

確かに実際、今さっき重めの作業があったので、
リソースモニターを使ってメモリをチェックしてみましたが、
InDesignCS5.5自体は1GBどころか700MB分くらいしか
メモリを使わない状態でした。

なお、同じく立ち上げた「だけ」の状態のPhotoshopCCは、
処理していないで待機しているだけなのに、メモリ1.6GB占有でした。

InDesignCS5.5が2GB限度までメモリを使っているような様子もなさそうですし、やはり、4GBパッチを当ててもあまり効果はないのでしょうか…

No.9653 2019/08/26(Mon) 11:50:17
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
ノンブルの固定について / ちほ Email
いつもお世話になっております。

InDesignCC2015で、400P近くのものを並び替えすることとなりました。

1P確定となっており、全て似たような体裁となっております。
ヌケ防止や抜粋間違い防止も含め、作業手順としては
1.全ページのノンブルを固定
2.指示通りに並び替え
3.ノンブルの固定を解除しノンブルを通し直す
としたいです。

一気に現在のノンブルがズレないように固定し、
あとで一気にノンブルを通す何か良い方法はないでしょうか?

よろしくお願いいたします。

No.9644 2019/08/03(Sat) 09:52:32
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36

Re: ノンブルの固定について / works014 URL
新規ドキュメントに「配置」で元ファイルを配置して、ノンブル部分の上に「新規ノンブル」のフレームを重ねて隠す方法では?
※「読み込みオプションを表示」で配置頁を指定可能です。

No.9645 2019/08/03(Sat) 10:42:17
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Firefox/68.0

Re: ノンブルの固定について / お〜まち URL
ブック機能ではだめなんでしょうか。
No.9646 2019/08/03(Sat) 11:30:02
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.94 Safari/537.36 Vivaldi/2.6.1566.40

Re: ノンブルの固定について / ちほ Email
works014様>>
アドバイスいただきありがとうございます。
以前元ファイルを配置したものをPDFにした際に、崩れなどのエラーが出たことから、「InDesignの配置」は禁止しております。
また、あと最低でも2回は校正がはいるため、配置だと「修正→リンク更新」の作業が行われるため出来たらこの作業をさけたいと思っております。
そのため、「PDFを配置し、新規ノンブルを上にのせる」方法も避けたいです。
情報提供不足とわがままな希望で大変申し訳ございません。

お〜まち様>>
アドバイスいただきありがとうございます。
現在、50頁分ごとにデータをわけている作りとなっております。
そのため、1頁につき1データでないため、ブック機能での並び替えが出来ない状態となっております。
説明不足で申し訳ございません。

No.9647 2019/08/03(Sat) 12:19:05
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36

Re: ノンブルの固定について / (z-) URL
たとえばですが
・ページ番号の代わりに連結テキストフレームの[箇条書き]でノンブルを作成
・箇条書きをテキストに変換

したものをフレームの塗りを紙色にして実際のノンブルに上位レイヤーで重ねておき、
ページを任意に並べ替え、確認、
用が済んだらそのレイヤーを非表示、
みたいなトリッキーな方法なら、あるいは。

どこかでスクリプティングが必要になる可能性はあります。

No.9648 2019/08/06(Tue) 12:30:17
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8

Re: ノンブルの固定について / .
・自動ノンブルを、専用のレイヤに移動する。
・固定ノンブル用のレイヤを作って、固定ノンブルをスクリプトで作成。
・移動作業中は、自動ノンブルを隠して作業。
・作業終了後に固定ノンブルを削除し、自動ノンブルを出す
みたいな方法が現実的では。

No.9649 2019/08/06(Tue) 12:39:20
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36

Re: ノンブルの固定について / Subi
.さんの方法が現実的ではと思います。
特定のレイヤーのノンブルをオーバーライドで固定する方法は
https://forums.adobe.com/thread/438115
このスレッドでKasyan Servetskyさんが提示しているスクリプトのレイヤー名を書き換えれば可能です。

No.9650 2019/08/24(Sat) 11:43:39
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
全2018件 [ ページ : << 1 ... 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ... 289 >> ]