中ゴシックと中ゴBBBの問題
皆さんこんにちには。中ゴBBBが中ゴシック体に勝手に変換されて困るというトラブルに見舞われたことはないでしょうか?
今回まさにそういうことが生じまして、みなさんの知恵を拝借したいと思いました。状況は以下の通りです。
1.G4のクオーク4.1でフォーマット作成→作業後、G5でクオーク6.5で修正保存(この時形式は4のまま)
2.その後G4のクオーク4.1で再度開くと中ゴシック体に替わっている。
3.フォントはG5ではNew-CID。G4ではOCF。
おそらく原因はシンプルのように見えますが、往々にしてこういったことがあるのでしょうか?
また、このやり方を継続しつつ、フォントの代替がおこらない方法などないでしょうか?
中ゴシック体をシステムから引っこ抜くというのは乱暴でしょうか?
今回まさにそういうことが生じまして、みなさんの知恵を拝借したいと思いました。状況は以下の通りです。
1.G4のクオーク4.1でフォーマット作成→作業後、G5でクオーク6.5で修正保存(この時形式は4のまま)
2.その後G4のクオーク4.1で再度開くと中ゴシック体に替わっている。
3.フォントはG5ではNew-CID。G4ではOCF。
おそらく原因はシンプルのように見えますが、往々にしてこういったことがあるのでしょうか?
また、このやり方を継続しつつ、フォントの代替がおこらない方法などないでしょうか?
中ゴシック体をシステムから引っこ抜くというのは乱暴でしょうか?
[ポポンエス]-2008/04/10 10:30:21 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.9 (KHTML, like Gecko) Safari/312.6]
[匿名]-2008/04/10 10:41:45 [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)]
[今さらですが]-2008/04/10 10:44:00 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
[ken]-2008/04/10 12:57:18 [Mozilla/4.0 (compatible; MSIE 5.17; Mac_PowerPC)]
[若名]-2008/04/10 14:47:21 [Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)]
[見物人]-2008/04/10 23:13:10 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
[匿名]-2008/04/10 23:16:01 [Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)]
[ken]-2008/04/10 23:52:37 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
[見物人]-2008/04/11 00:26:12 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
[匿名]-2008/04/11 09:04:56 [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)]
» 010
>やってたんですけどねぇ。
自分の周りだけで判断しないでくださいね。
確かに「出来るか、出来ないか」と言えば実現可能でしょう。
その事は、ここに書き込んでいる人なら、皆が理解している事だと思います。しかし、それは一般的な使用法ではありません。
可能性を全てを網羅しようとすれば11ページは、その可能性の記述で一杯になるでしょう。書かれていないという事は、やはり「一般的でない」と言わざるを得ません。
そう言った逃げ道的な話をしても意味がないでしょう。
また、壊れるまで古いシステムを使い続ける事は出来ますし、特に不自由しなければ、システムを更新する事の必要も無いでしょう。
しかし仕事として使っているのであれば、これでは万が一故障した際のサポート切れの為、復旧が出来ません。
やはりシステムの維持、継続は企業努力として保たれるべきですし、社内互換は最低限のシステム維持だと思います。
>やってたんですけどねぇ。
自分の周りだけで判断しないでくださいね。
確かに「出来るか、出来ないか」と言えば実現可能でしょう。
その事は、ここに書き込んでいる人なら、皆が理解している事だと思います。しかし、それは一般的な使用法ではありません。
可能性を全てを網羅しようとすれば11ページは、その可能性の記述で一杯になるでしょう。書かれていないという事は、やはり「一般的でない」と言わざるを得ません。
そう言った逃げ道的な話をしても意味がないでしょう。
また、壊れるまで古いシステムを使い続ける事は出来ますし、特に不自由しなければ、システムを更新する事の必要も無いでしょう。
しかし仕事として使っているのであれば、これでは万が一故障した際のサポート切れの為、復旧が出来ません。
やはりシステムの維持、継続は企業努力として保たれるべきですし、社内互換は最低限のシステム維持だと思います。
[見物人]-2008/04/11 09:39:08 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
[安莉芳]-2008/04/11 10:14:48 [Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_4_11; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
» 012
>やってたんですけどねぇ
あなたでしたか…
いるんですねえそういう人。
会社の方針か何かかわらないけど
大変な環境だと思う。気の毒です。
皮肉ではなく、真面目にそう思う。
でも過去形になってるから今はやってないのかな?
>やってたんですけどねぇ
あなたでしたか…
いるんですねえそういう人。
会社の方針か何かかわらないけど
大変な環境だと思う。気の毒です。
皮肉ではなく、真面目にそう思う。
でも過去形になってるから今はやってないのかな?
[ken]-2008/04/11 20:03:41 [Mozilla/4.0 (compatible; MSIE 5.17; Mac_PowerPC)]
[匿名]-2008/04/11 20:10:34 [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)]
» 014
>私は、G4でOCF使えなかった方の方が気の毒だと思いますけどね。
フォントを自分だけではコントロール出来ない人も多いのですから。
ま、だから割れ物が流行ったんでしょうけど。
こう言う人って何処にでも居るんですね?
突っ込まれるとムキになる人って。
CIDがリリースされて久しいにも拘らず更新してもらえなかった方が悲しいです。
「いかにも裏技使ってG4でも使っていました。」みたいな口調ですが、その手法って、初期化さえしなければ良いのですから、誰でも安易に想像できることです。
またCIDがリリースされてすぐ飛びついている人はフォントメーカーのいいなりで良いお客さんだ。自分自身ではメンテも何も出来ないような人のように捉えているのでしょう。
でもそれは違いますね。それなりにodfに比べメリットがあるからこそ殆どの人が更新しているはずです。
>私は、G4でOCF使えなかった方の方が気の毒だと思いますけどね。
フォントを自分だけではコントロール出来ない人も多いのですから。
ま、だから割れ物が流行ったんでしょうけど。
こう言う人って何処にでも居るんですね?
突っ込まれるとムキになる人って。
CIDがリリースされて久しいにも拘らず更新してもらえなかった方が悲しいです。
「いかにも裏技使ってG4でも使っていました。」みたいな口調ですが、その手法って、初期化さえしなければ良いのですから、誰でも安易に想像できることです。
またCIDがリリースされてすぐ飛びついている人はフォントメーカーのいいなりで良いお客さんだ。自分自身ではメンテも何も出来ないような人のように捉えているのでしょう。
でもそれは違いますね。それなりにodfに比べメリットがあるからこそ殆どの人が更新しているはずです。
[やじ馬]-2008/04/11 21:37:53 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
[匿名]-2008/04/11 23:43:36 [Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)]
[ののりり]-2008/04/12 01:31:13 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
[若名]-2008/04/12 02:12:56 [Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)]
[匿名A]-2008/04/12 08:43:18 [Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)]
[ ]-2008/04/12 10:35:17 [Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_2; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
[やじ馬]-2008/04/12 11:11:32 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
[ひろし]-2008/04/12 12:37:53 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
[にゃごにゃご]-2008/04/12 12:38:07 [Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13]
[ののりり]-2008/04/12 13:50:02 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13]
[若名]-2008/04/12 14:23:17 [Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)]
[匿名]-2008/04/12 16:20:00 [Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)]
[とくめ~]-2008/04/13 21:36:00 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP-mac; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13]
» 027
QuarkXPress3.3J/4.1Jの出力現場だと(PostScriptを
はき出す段のことです)、
システムフォントの中ゴシック体と
OCFの中ゴシックBBB(ビットマップフォントでよい)
システムフォントの細明朝体と
OCFのリュウミンL-KL(ビットマップフォントでよい)
を一緒に入れておくのが安全です。
というのも、制作側でどちらかに統一されている、と
いうわけでも無いので(つまりデータごとにまちま
ち)、どちらも環境に存在させておくことによって、
不要なフォントの置き換わりが防げるのでした。
そういう意味で、いまどきのQuarkXPress3.3J/4.1Jに
おいてベストなモリサワフォント環境というのは、
細明朝体/リュウミンL-KL(ビットマップ)
/A-CIDリュウミンL-KL(ATM)
のトリプルなのではないでしょうか。
制作側の都合としても、QuarkXPress特有の縦組み組
版の仕様でOCFのモリサワフォントだと箱組の計算が
狂うので、中ゴシック体・細明朝体の方が組み版的に
便利という理由もあり統一ができないのだと思いま
した。
# いまどきのOCFモリサワ仕様のQuarkXPressデータ、
# アウトラインフォントで表示してきっちり組版しな
# いのであれば、ビットマップのOCFモリサワフォン
# トを入れておくと便利です。Mac OS 8 or 9環境も
# 必須ですが
QuarkXPress3.3J/4.1Jの出力現場だと(PostScriptを
はき出す段のことです)、
システムフォントの中ゴシック体と
OCFの中ゴシックBBB(ビットマップフォントでよい)
システムフォントの細明朝体と
OCFのリュウミンL-KL(ビットマップフォントでよい)
を一緒に入れておくのが安全です。
というのも、制作側でどちらかに統一されている、と
いうわけでも無いので(つまりデータごとにまちま
ち)、どちらも環境に存在させておくことによって、
不要なフォントの置き換わりが防げるのでした。
そういう意味で、いまどきのQuarkXPress3.3J/4.1Jに
おいてベストなモリサワフォント環境というのは、
細明朝体/リュウミンL-KL(ビットマップ)
/A-CIDリュウミンL-KL(ATM)
のトリプルなのではないでしょうか。
制作側の都合としても、QuarkXPress特有の縦組み組
版の仕様でOCFのモリサワフォントだと箱組の計算が
狂うので、中ゴシック体・細明朝体の方が組み版的に
便利という理由もあり統一ができないのだと思いま
した。
# いまどきのOCFモリサワ仕様のQuarkXPressデータ、
# アウトラインフォントで表示してきっちり組版しな
# いのであれば、ビットマップのOCFモリサワフォン
# トを入れておくと便利です。Mac OS 8 or 9環境も
# 必須ですが
[CL]-2008/04/14 04:33:43 [Opera/9.27 (Windows NT 6.0; U; ja)]