あまり書く人がいないので書きますが、おそらく根本的に考え方を改める必要がある
と思います。前にも同じような質問をされていることですし。
https://okumuralab.org/tex/mod/forum/discuss.php?d=1574
まず質問のしかたについて。
> 前回と同じく dvipdfmx を使っており、pdfファイルが出力されませんでした。
そのときにどんなエラーが出ているのか、答える人に実験させる前に自分でエラー
メッセージかなにか貼りつけるのが筋ではないですかね？
「ここに LaTeX ソースを添付します。これを platex hoge と dvipdfmx hoge と
すると…のエラーが出ます」
のように書いてあれば、何が起きているのか見ている人に伝わります。
最低限、このくらいは書いてほしいですね、回答してほしいという気があるならば。
そして、スペースについて。
スペースを含むファイル名は、「普通の人」なら極力使わないように使わないように
するのが常識です。そこまでして敢えてスペースを使いたい理由が分かりません。
どんなプログラムでも、スペースは“区切り”なのでそういうものとして扱われます。
それを「○○の場合は区切りとしてではなく××のように扱ってほしい」のように
思うのならば、そうなるように自分が動くことです。コードを書けばよいのです。
（もちろん既に「△△すれば□□の場合にスペースも大丈夫だよ」という方法を作っ
てくれている人がいるかもしれませんから、それを探すという方法もありますが。）
「普通の人」はそうやってスペースを含んでもよいようにするメリットをそこまで
感じないので、誰もやりたがりません。それでもと思うならば自分で作るか、もっとも
らしい理由を開発者に伝えるべきです。
と思います。前にも同じような質問をされていることですし。
https://okumuralab.org/tex/mod/forum/discuss.php?d=1574
まず質問のしかたについて。
> 前回と同じく dvipdfmx を使っており、pdfファイルが出力されませんでした。
そのときにどんなエラーが出ているのか、答える人に実験させる前に自分でエラー
メッセージかなにか貼りつけるのが筋ではないですかね？
「ここに LaTeX ソースを添付します。これを platex hoge と dvipdfmx hoge と
すると…のエラーが出ます」
のように書いてあれば、何が起きているのか見ている人に伝わります。
最低限、このくらいは書いてほしいですね、回答してほしいという気があるならば。
そして、スペースについて。
スペースを含むファイル名は、「普通の人」なら極力使わないように使わないように
するのが常識です。そこまでして敢えてスペースを使いたい理由が分かりません。
どんなプログラムでも、スペースは“区切り”なのでそういうものとして扱われます。
それを「○○の場合は区切りとしてではなく××のように扱ってほしい」のように
思うのならば、そうなるように自分が動くことです。コードを書けばよいのです。
（もちろん既に「△△すれば□□の場合にスペースも大丈夫だよ」という方法を作っ
てくれている人がいるかもしれませんから、それを探すという方法もありますが。）
「普通の人」はそうやってスペースを含んでもよいようにするメリットをそこまで
感じないので、誰もやりたがりません。それでもと思うならば自分で作るか、もっとも
らしい理由を開発者に伝えるべきです。
> 「普通の人」
この表現について、私の意図しない解釈を防ぐため補足しておきます。
TeX が長い期間を経てもスペースを必ずしも期待どおりに扱えない理由は
なんだろうと立ち止まると、今まで TeX を使ってきた大勢の人にとって
そもそも需要がなかったか、あるいはスペースを使わずに済む回避策が特に
苦ではなかったからではないかと“私は”思ったからです。
今まで大勢の人がそうしてきているのだからそういうものだろうと考えれば
不満を言ってもしょうがないと自分で納得してしまえるという思いです。
だからといって TeX に対応してほしいと思ったことはありませんでした。
文字列を読む際の空白の解釈を変えるのは影響が大きく、難しいのでしょう。
みんなそうやってきたのだろう＝それが普通なんだろう、これが根源です。
しかし使えなくて不満が起きるのも無理はないかもしれませんね。
恣意的であまり良い表現ではなかったと思いますのでここに訂正します。
ノイズ失礼しました。
この表現について、私の意図しない解釈を防ぐため補足しておきます。
TeX が長い期間を経てもスペースを必ずしも期待どおりに扱えない理由は
なんだろうと立ち止まると、今まで TeX を使ってきた大勢の人にとって
そもそも需要がなかったか、あるいはスペースを使わずに済む回避策が特に
苦ではなかったからではないかと“私は”思ったからです。
今まで大勢の人がそうしてきているのだからそういうものだろうと考えれば
不満を言ってもしょうがないと自分で納得してしまえるという思いです。
だからといって TeX に対応してほしいと思ったことはありませんでした。
文字列を読む際の空白の解釈を変えるのは影響が大きく、難しいのでしょう。
みんなそうやってきたのだろう＝それが普通なんだろう、これが根源です。
しかし使えなくて不満が起きるのも無理はないかもしれませんね。
恣意的であまり良い表現ではなかったと思いますのでここに訂正します。
ノイズ失礼しました。
お勧めはできませんが，ずいぶん以前から，
TeX source file name の場合は大体において
ファイル名にスペースを含めることができます。
(2つ以上の連続したスペースはだめ) 下記は OK:
tex "a b c d e f.tex"
ただし，include する image file については，エンジンに
よって，できるものとできないものがあります:
pdflatex, xelatex なら下記が OK ですが，他の大部分の場合はだめ。
\documentclass{article}
\usepackage{graphicx}
\usepackage{grffile}
\begin{document}
\includegraphics{a b c d e f.png}
\end{document}
image file は，"dot ひとつ，スペース無し" と覚えておく
のが安全です。
TeX source file name の場合は大体において
ファイル名にスペースを含めることができます。
(2つ以上の連続したスペースはだめ) 下記は OK:
tex "a b c d e f.tex"
ただし，include する image file については，エンジンに
よって，できるものとできないものがあります:
pdflatex, xelatex なら下記が OK ですが，他の大部分の場合はだめ。
\documentclass{article}
\usepackage{graphicx}
\usepackage{grffile}
\begin{document}
\includegraphics{a b c d e f.png}
\end{document}
image file は，"dot ひとつ，スペース無し" と覚えておく
のが安全です。
先を越されてしまった
grffile の一解法が示されたので別解法を...
＊＊ 処理環境依存＊＊の開放です。
python の処理系を有するか unix 系の OS であればという条件付きです。
また TeXLive 20xx に付属している DTL dviware package を利用してい
ますのでご注意ください。
＊対策と最初の問題点＊
空白を含むファイル名をダブルクォートでくくりますが
latex は通るけど dvipdfmx はうまく処理してくれない。
\documentclass{article}
\usepackage{graphicx}
\begin{document}
%\includegraphics{M M SPACE.eps} %こちらエラーになる
\includegraphics{"M M SPACE.eps"}%ダブルクォートでくくる
\end{document}
上記をコンパイルして dvipdfmx で処理すると以下のように
警告メッセージが表示され、画像ファイルが pdf には反映
されません。
dvipdfmx:warning: No filename specified for PSfile special.
dvipdfmx:warning: Interpreting special command PSfile (ps:) failed.
dvipdfmx:warning: >> at page="1" position="(148.712, 480.088)" (in PDF)
dvipdfmx:warning: >> xxx "PSfile=""include SPACE in filename.eps"" ..snip.."
dvipdfmx:warning: >> Reading special command stopped around >>""include SPACE in filename.eps"" ..snip.. <<
＊原因＊
ファイル名に余分な「" ダブルクォート」があるようで処理ができない
ようです。
＊解法を求めて＊
インターネットを調べると以下の URL に一つの解決作がありました。
http://wiki.lyx.org/LaTeX/FilesWithSpecialChars
ここに以下のスクリプトの URL があるので私は shell スクリプト
の方をダウンロードしました。
A python script, clean_dvi.py (12 April 2005, 3.5kB).
http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/clean_dvi.py
A shell script, clean_dvi.sh (12 April 2005, 2.7kB).
http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/clean_dvi.sh
これをみると以下のように DTL dviware package を使い
dvi ファイルを可視化させ余分な「" ダブルクォート」を
sed で取り除いたあと、再度 dvi ファイル化するようです。
dv2dt "$INFILE" | sed "$SEDCOMMANDS" | dt2dv -si "$OUTFILE"
なので
sh clean_dvi.sh 変換前.dvi 変換後.dvi
とするとファイル名に関して補正できますので
dvipdfmx 変換後.dvi
とすれば、変換後.pdf に目的の画像ファイルが取り込まれます。
＊別解 perl や ruby でできないか ...
sed で処理する部分を見ると「sed の高度なテクニックコマンド」
を使ってるけど以下のことをやってるだけだった。
dv2dt 変換前.dvi | sed '/PSfile=/s/""/"/g' | dt2dv 変換後.dvi
なので perl や ruby でもすぐに対応できそうですね。
> \documentclass{article}
> \usepackage{graphicx}
> \begin{document}
> %\includegraphics{M M SPACE.eps} %こちらエラーになる
> \includegraphics{"M M SPACE.eps"}%ダブルクォートでくくる
> \end{document}
不思議なことに，これは latex や platex で通るのですね。
\includegraphics{...} では " もファイル名に含まれるので
通らないのが普通。通っても，dvi には " もファイル名に
含まれている。不思議。
pdflatex では通りません。
> \usepackage{graphicx}
> \begin{document}
> %\includegraphics{M M SPACE.eps} %こちらエラーになる
> \includegraphics{"M M SPACE.eps"}%ダブルクォートでくくる
> \end{document}
不思議なことに，これは latex や platex で通るのですね。
\includegraphics{...} では " もファイル名に含まれるので
通らないのが普通。通っても，dvi には " もファイル名に
含まれている。不思議。
pdflatex では通りません。
これを書いている最中に質問者から回答がありましたが ...
一方 png の場合は includegrapics で bb オプションを指定しなければ
extractbb などで補助ファイルを作るなどの対応が必要になります。
そのファイルを探すときにスペースが邪魔してしまうと思います。
shellでextractbb を呼ぶ際にも類似の障害が起きるのではないのでしょうか？
ということで「 bb オプションを指定」すれば バウンディングボックス情報を求める作業がなくなるのでファイル操作しないので「latex が通る」ことになります（と思います）。
和田さんの
> 「 bb オプションを指定」すれば バウンディングボックス情報を求める作業がなくなるので
> ファイル操作しないので「latex が通る」ことになります（と思います）。
を読んで考えたのですが、どうもそういうわけでもなさそうです。
pdflatex で「スペース入り png」に対して出るエラーは
! LaTeX Error: Unknown graphics extension: .png".
です。つまり「.png"」という拡張子を知らないというエラーです。
しかし、(p)latex と dvipdfmx を組み合わせに対しては拡張子を知らないというエラーが
出てきません。「.eps"」という拡張子を知らないといわれてもおかしくないのに、です。
なんとなく画像の扱いは dvipdfmx.def とか pdftex.def を見る限り
(1) 拡張子をみる
(2) 結果に応じて直接 BB を読むか extractbb するか決める（知らない拡張子はエラー）
だと思っていたので（ここが間違っていたらごめんなさい）、拡張子エラーを出さずに「.eps"」を
通したのが不思議、という感触です。内部処理の差が効いているのでしょうが、深入りしないことにします。
> 「 bb オプションを指定」すれば バウンディングボックス情報を求める作業がなくなるので
> ファイル操作しないので「latex が通る」ことになります（と思います）。
を読んで考えたのですが、どうもそういうわけでもなさそうです。
pdflatex で「スペース入り png」に対して出るエラーは
! LaTeX Error: Unknown graphics extension: .png".
です。つまり「.png"」という拡張子を知らないというエラーです。
しかし、(p)latex と dvipdfmx を組み合わせに対しては拡張子を知らないというエラーが
出てきません。「.eps"」という拡張子を知らないといわれてもおかしくないのに、です。
なんとなく画像の扱いは dvipdfmx.def とか pdftex.def を見る限り
(1) 拡張子をみる
(2) 結果に応じて直接 BB を読むか extractbb するか決める（知らない拡張子はエラー）
だと思っていたので（ここが間違っていたらごめんなさい）、拡張子エラーを出さずに「.eps"」を
通したのが不思議、という感触です。内部処理の差が効いているのでしょうが、深入りしないことにします。
これで納得しました。
そもそも TeX は EPS だけは BB を自分で読めるので、DVI まで作る
段階をみると「TeX は EPS に対応している」。だから、未知の拡張子
はとりあえず EPS にフォールバックして読めなければエラー。
しかし pdfTeX の PDF 出力モードは EPS の BB を読むだけでは不足
で EPS -> PDF までしないと目的の PDF を作ることができない。
だから、「pdfTeX の PDF モードは EPS に未対応」。だから、EPS に
**フォールバックするわけにはいかなくて**、すぐにエラー。
ありがとうございます。
そもそも TeX は EPS だけは BB を自分で読めるので、DVI まで作る
段階をみると「TeX は EPS に対応している」。だから、未知の拡張子
はとりあえず EPS にフォールバックして読めなければエラー。
しかし pdfTeX の PDF 出力モードは EPS の BB を読むだけでは不足
で EPS -> PDF までしないと目的の PDF を作ることができない。
だから、「pdfTeX の PDF モードは EPS に未対応」。だから、EPS に
**フォールバックするわけにはいかなくて**、すぐにエラー。
ありがとうございます。
皆さん、ご回答ありがとうございます。
昔試したときには
texファイルにスペースが含まれているとコンパイルできなかったのですが
いま、やってみると普通にできることが分かりました。
画像に関してなのですが、
いろいろ試していて気がついたのですが
挿入できる場合とできない場合があります。
そのソースファイルを下記にアップしました。
http://fast-uploader.com/file/7000992628208/
\includegraphics[width=7.5cm,bb=0 0 800 800]{.//o r.png}
\includegraphics[width=7.5cm,bb=0 0 800 800]{.//o r.eps}
のようにしてbbを指定するとpngもepsもスペースがあっても
画像を挿入できるようです。
しかし、なぜかスペースの後のファイル名が文字列としてpdf内に埋め込まれてしまいます。
これはどうすれば除去できますか？
一方で
\includegraphics[width=7.5cm]{.//o r.png}
\includegraphics[width=7.5cm]{.//o r.eps}
のようにしてbbを含まない形で画像を指定すると
以下のエラーが出てコンパイルすることができません。
LaTeX Warning: File `.//o r.png' not found on input line 7.
I try without the new options
extractbb:warning: Can't find file (.//o), or it is forbidden to read ...skipping
extractbb:warning: Can't find file (r.png), or it is forbidden to read ...skipping
! LaTeX Error: Cannot determine size of image (no BoundingBox).
See the LaTeX manual or LaTeX Companion for explanation.
Type H <return> for immediate help.
...
l.7 \includegraphics[width=7.5cm]{.//o r.png}
?
画像ファイルのスペースを除去した上で
\includegraphics[width=7.5cm]{.//or.png}
\includegraphics[width=7.5cm]{.//or.eps}
同じくbb無しで画像を指定すると問題なくコンパイルすることができるため
bbの有無が原因なのではなく
スペースの有無が原因のようです。
bbを指定しないとスペース有りの画像を挿入できないのはなぜでしょうか？
詳しい例とエラーメッセージをありがとうございます。
これなら私にもすぐに試せます。
> なぜかスペースの後のファイル名が文字列としてpdf内に埋め込まれてしまいます。
> これはどうすれば除去できますか？
これは grffile を使えば大丈夫です。[space] オプション付きで使います。
% platex -> dvipdfmx
\documentclass{jsarticle}
\usepackage[dvipdfmx]{graphicx}
\usepackage[space]{grffile}
\begin{document}
\includegraphics[width=7.5cm,bb=0 0 800 800]{.//o r.png}
\includegraphics[width=7.5cm,bb=0 0 800 800]{.//o r.eps}
\end{document}
↑ 以前に同じことを答えてましたね…
https://okumuralab.org/tex/mod/forum/discuss.php?d=1577#p9005
問題の「bb= を指定しない場合」に失敗する理由は
・bb= を指定すれば extractbb によって BoundingBox を取得する必要がない
・bb= の指定がなければ extractbb によって BoundingBox を取得する必要が生じる
からです。extractbb は例えば
extractbb a.png b.png
のように実行すると a.xbb と b.xbb を作ります。
このようにスペースは「複数のファイル」とみなされます。
この仕様により、platex 実行中に extractbb に「o r.png」を渡したつもりが「o」と
「r.png」を渡したかのようにみなされてしまっているのです。
これなら私にもすぐに試せます。
> なぜかスペースの後のファイル名が文字列としてpdf内に埋め込まれてしまいます。
> これはどうすれば除去できますか？
これは grffile を使えば大丈夫です。[space] オプション付きで使います。
% platex -> dvipdfmx
\documentclass{jsarticle}
\usepackage[dvipdfmx]{graphicx}
\usepackage[space]{grffile}
\begin{document}
\includegraphics[width=7.5cm,bb=0 0 800 800]{.//o r.png}
\includegraphics[width=7.5cm,bb=0 0 800 800]{.//o r.eps}
\end{document}
↑ 以前に同じことを答えてましたね…
https://okumuralab.org/tex/mod/forum/discuss.php?d=1577#p9005
問題の「bb= を指定しない場合」に失敗する理由は
・bb= を指定すれば extractbb によって BoundingBox を取得する必要がない
・bb= の指定がなければ extractbb によって BoundingBox を取得する必要が生じる
からです。extractbb は例えば
extractbb a.png b.png
のように実行すると a.xbb と b.xbb を作ります。
このようにスペースは「複数のファイル」とみなされます。
この仕様により、platex 実行中に extractbb に「o r.png」を渡したつもりが「o」と
「r.png」を渡したかのようにみなされてしまっているのです。
> bb= を指定すれば extractbb によって BoundingBox を取得する必要がない
これは「TeX が動く段階では」BoundingBox を取得する必要がないという意味です。
「bbの値を変えても図の大きさが変わらないので」は TeX のあと dvipdfmx まで
実行した結果を見ておっしゃっているのでしょう。
BoundingBox の値には正解がありますので、正解の値を bb= に指定しなければ
なりません。画像が一つ存在して、それを処理するプログラム（例えば dvipdfmx
とか）が決まれば、正解の値は一意に定まります。
「bb の値を変える」ということは「少なくとも一方の値は間違っている」のです。
正解以外の値を指定したときに何が起きるかは誰にもわかりません。