4～5年前に、このフオーラムに質問しながら、回答者諸氏の扶けを得て、何とか纏めた島崎藤村の『若菜集』です。できる限り初版本のイメージを保ちつつ仕上げたいと思いながらド素人の私が、私なりに一応の形を得ることが出來たのも、このForumのお蔭と感謝しております。昨日久しぶりにコンパイルしたところ、どうにもエラーがたって、出來ません。以前は問題なかつたところから、多分個別のソフトの「仕様変更」の所爲ではないか、それもfont周りの仕様変更が疑われるのですが、非力な小生には、原因を探ることが出來ません。以前コンパイルして得たPDFも添付しますので、どなたか原因と対策をご教授してくださいませんか。そのためにわざわざ環境を整えるのも、面倒とは存じますが、愛着のある文芸作品なので、是非また動作させたいと願つて居ります。中村不折の挿画が秀逸で、この形で市販されているのは古書しかないようですので、ぜひお願いしたいと存じます。添付を御覧下さい。添付が大きすぎると叱られましたので、二度に分けたいとおもいます。
\includegraphicsの數が多いのに、またそれらがⅠ箇所にまとまつていなくて分散しているのに、質問者が回答者にcomment outしてください、というのも失礼極まりないと反省しました。改めてcomment outしたものを、添付し直します。
私の環境では正常に PDF を作成できました。
添付の .log ファイルを見る限り uplatex ではエラーは出ていないみたいですね。
dvipdfmx でエラーが出ているのでしょうか？
mr2h さんは TeXworks をお使いでしたよね？
エラーになったときに TeXworks の画面の下部の「ログの表示」のところにエラーメッセージが出ていると思うのでそれをコピーしたものを添付していただけますか？
---
【メモ】タイプセットに必要なファイルの入手場所
* sfkanbun.sty shiika.sty jdkintou.sty
* http://xymtex.com/fujitas2/texlatex/index.html
* indent.sty
* https://ctan.org/pkg/indent
* bxglyphwiki.sty bxglyphwiki.lua
* https://github.com/zr-tex8r/BXglyphwiki
* samminh.otf
* https://www.akenotsuki.com/eyeben/fonts/sammin.html
添付の .log ファイルを見る限り uplatex ではエラーは出ていないみたいですね。
dvipdfmx でエラーが出ているのでしょうか？
mr2h さんは TeXworks をお使いでしたよね？
エラーになったときに TeXworks の画面の下部の「ログの表示」のところにエラーメッセージが出ていると思うのでそれをコピーしたものを添付していただけますか？
---
【メモ】タイプセットに必要なファイルの入手場所
* sfkanbun.sty shiika.sty jdkintou.sty
* http://xymtex.com/fujitas2/texlatex/index.html
* indent.sty
* https://ctan.org/pkg/indent
* bxglyphwiki.sty bxglyphwiki.lua
* https://github.com/zr-tex8r/BXglyphwiki
* samminh.otf
* https://www.akenotsuki.com/eyeben/fonts/sammin.html
(./bxgw_u82e5-k.def) (./bxgw_u82e5-k.def) (./bxgw_u82e5-k.def)
(./bxgw_u82e5-k.def) [195] [196] [197] [198] (./bxgw_u8e48-j.def)
(./bxgw_u6885-k.def) (./bxgw_u6885-k.def) (./bxgw_u6885-k.def)
(./bxgw_u6885-k.def) (./bxgw_u8449-k.def) (./bxgw_u5be6-j.def)
(./bxgw_u4e82-j.def) (./bxgw_resp_.def) (./bxgw_u5cfd-j.def)
(./bxgw_u5cfd-j.def) (./bxgw_u5cfd-j.def) (./bxgw_u5cfd-j.def)
(./bxgw_u5ee3-h.def) (./bxgw_u8449-k.def) (./bxgw_inaz_u898b-var-001.def)
(./bxgw_u8072-j.def) (./bxgw_u7d72-j.def) (./bxgw_u5dd6-g.def)
(./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def)
(./bxgw_u82e5-k.def) [199] [200] [201] [202] (./bxgw_u8449-k.def) [203]
(./bxgw_u7fbd-k.def) (./bxgw_u7fbd-k.def) (./bxgw_inaz_u898b-var-001.def)
(./bxgw_u885e.def) (./bxgw_u885e.def) (./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def)
(./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def) (./bxgw_u8ff7-k.def)
(./bxgw_resp_.def) (./bxgw_u524a-k.def) (./bxgw_u524a-k.def)
(./bxgw_u524a-k.def) (./bxgw_u524a-k.def) (./bxgw_u5dd6-g.def)
(./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def)
(./bxgw_u788e-g.def) (./bxgw_u7368-t.def) (./bxgw_u6d6e-k.def) [204] [205]
[206] [207] [208] (./bxgw_u9189-j.def) (./bxgw_aj1-13783.def)
(./bxgw_aj1-13783.def) (./bxgw_aj1-13783.def) (./bxgw_aj1-13783.def)
(./bxgw_u5e36-t.def) (./bxgw_u975c-ue0109.def) (./bxgw_u908a-itaiji-008.def)
(./bxgw_inaz_u898b-var-001.def) (./bxgw_u8349-k.def) (./bxgw_u8ff7-k.def)
(./bxgw_aj1-13783.def) (./bxgw_aj1-13783.def) (./bxgw_aj1-13783.def)
(./bxgw_aj1-13783.def) [209] [210] (./bxgw_u82e5-k.def) (./bxgw_u83dc-k.def)
***** List of packages loaded by `plautopatch': *****
pxmulticol.
*****************************************************
[211] (./若菜集2.aux) )
(see the transcript file for additional information)
Output written on 若菜集2.dvi (221 pages, 332808 bytes).
SyncTeX written on ���؏W2.synctex.gz.
Transcript written on 若菜集2.log.
という「ログの表示」ですが、dviまではできている、というところでしょうか。このまま報知すると texworks自体が落ちてしまいます。（2から3分後）埋め込みfontは原の味です。
(./bxgw_u82e5-k.def) [195] [196] [197] [198] (./bxgw_u8e48-j.def)
(./bxgw_u6885-k.def) (./bxgw_u6885-k.def) (./bxgw_u6885-k.def)
(./bxgw_u6885-k.def) (./bxgw_u8449-k.def) (./bxgw_u5be6-j.def)
(./bxgw_u4e82-j.def) (./bxgw_resp_.def) (./bxgw_u5cfd-j.def)
(./bxgw_u5cfd-j.def) (./bxgw_u5cfd-j.def) (./bxgw_u5cfd-j.def)
(./bxgw_u5ee3-h.def) (./bxgw_u8449-k.def) (./bxgw_inaz_u898b-var-001.def)
(./bxgw_u8072-j.def) (./bxgw_u7d72-j.def) (./bxgw_u5dd6-g.def)
(./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def)
(./bxgw_u82e5-k.def) [199] [200] [201] [202] (./bxgw_u8449-k.def) [203]
(./bxgw_u7fbd-k.def) (./bxgw_u7fbd-k.def) (./bxgw_inaz_u898b-var-001.def)
(./bxgw_u885e.def) (./bxgw_u885e.def) (./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def)
(./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def) (./bxgw_u8ff7-k.def)
(./bxgw_resp_.def) (./bxgw_u524a-k.def) (./bxgw_u524a-k.def)
(./bxgw_u524a-k.def) (./bxgw_u524a-k.def) (./bxgw_u5dd6-g.def)
(./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def) (./bxgw_u5dd6-g.def)
(./bxgw_u788e-g.def) (./bxgw_u7368-t.def) (./bxgw_u6d6e-k.def) [204] [205]
[206] [207] [208] (./bxgw_u9189-j.def) (./bxgw_aj1-13783.def)
(./bxgw_aj1-13783.def) (./bxgw_aj1-13783.def) (./bxgw_aj1-13783.def)
(./bxgw_u5e36-t.def) (./bxgw_u975c-ue0109.def) (./bxgw_u908a-itaiji-008.def)
(./bxgw_inaz_u898b-var-001.def) (./bxgw_u8349-k.def) (./bxgw_u8ff7-k.def)
(./bxgw_aj1-13783.def) (./bxgw_aj1-13783.def) (./bxgw_aj1-13783.def)
(./bxgw_aj1-13783.def) [209] [210] (./bxgw_u82e5-k.def) (./bxgw_u83dc-k.def)
***** List of packages loaded by `plautopatch': *****
pxmulticol.
*****************************************************
[211] (./若菜集2.aux) )
(see the transcript file for additional information)
Output written on 若菜集2.dvi (221 pages, 332808 bytes).
SyncTeX written on ���؏W2.synctex.gz.
Transcript written on 若菜集2.log.
という「ログの表示」ですが、dviまではできている、というところでしょうか。このまま報知すると texworks自体が落ちてしまいます。（2から3分後）埋め込みfontは原の味です。
エラーは以下のが出ているので PDF 作成しようとしたときエラーになっていますね、
dvipdfmx:warning: Could not read encoding file: unicode
dvipdfmx:warning: Could not locate a virtual/physical font for TFM "uphminrn-v".
dvipdfmx:warning: >> This font is mapped to a physical font "samminh.otf".
dvipdfmx:warning: >> Please check if kpathsea library can find this font: samminh.otf
dvipdfmx:fatal: Cannot proceed without .vf or "physical" font for PDF output...
一応 PDF ファイルはできるのですが、15 バイトくらいなのも影響して
texworks も落ちてしまうのかと思います。
はやてさんが示された https://www.akenotsuki.com/eyeben/fonts/sammin.html を参考に
三番明朝Hの方をダウンロードし samminh.otf を取り出すと PDF 作成できました。
dvipdfmx:warning: Could not read encoding file: unicode
dvipdfmx:warning: Could not locate a virtual/physical font for TFM "uphminrn-v".
dvipdfmx:warning: >> This font is mapped to a physical font "samminh.otf".
dvipdfmx:warning: >> Please check if kpathsea library can find this font: samminh.otf
dvipdfmx:fatal: Cannot proceed without .vf or "physical" font for PDF output...
一応 PDF ファイルはできるのですが、15 バイトくらいなのも影響して
texworks も落ちてしまうのかと思います。
はやてさんが示された https://www.akenotsuki.com/eyeben/fonts/sammin.html を参考に
三番明朝Hの方をダウンロードし samminh.otf を取り出すと PDF 作成できました。
不具合があるものの、最終的にはPDFは作成されます。ただ、以前にはなかった現象として、
① 非常に時間が掛かる。（dvi作成までは、通常の速さ、でもdvipdfmxで時間がかかっているように見える）
② （前にも報告したとおり）時々texworksがハングアップする。ただ、再度起動すると、PDFは出來て居る。
と、まあ、こんな現象で、そこからは一向に改善されません。
何で以前は正常だったのに、こんなことになったのか全くわかりません。
tllmgr update --self --all は毎日のように手動で実行しています。
なお、ほかのTeX原稿は、正常に処理できます。
ということは三番明朝フオントの設定あたりが怪しい、ということでしょうか。
（設定当初は問題なくても、その後なんらかの仕様変更があったとか。）
① 非常に時間が掛かる。（dvi作成までは、通常の速さ、でもdvipdfmxで時間がかかっているように見える）
② （前にも報告したとおり）時々texworksがハングアップする。ただ、再度起動すると、PDFは出來て居る。
と、まあ、こんな現象で、そこからは一向に改善されません。
何で以前は正常だったのに、こんなことになったのか全くわかりません。
tllmgr update --self --all は毎日のように手動で実行しています。
なお、ほかのTeX原稿は、正常に処理できます。
ということは三番明朝フオントの設定あたりが怪しい、ということでしょうか。
（設定当初は問題なくても、その後なんらかの仕様変更があったとか。）
1200dpiでスキャンされたんですね。階調のある写真やスキャン画像ならオフセット印刷でもたかだか仕上がり350dpiくらいが一般的でしょうか。PDFでなくてもJPEGかPNGでそのままLaTeXで取り込めると思います。
あと、ここにアップロードされる際に、JPEGやPNGやPDFは圧縮する必要ありません（圧縮してもサイズは変わらない）。
あと、この画像についていえば、JPEGだから画質が悪いのではなく、もともとの印刷の網点が見えてしまっているだけだと思います。画像編集ソフトで平滑化して網点除去するといいのかもしれません。
（念のため）低解像度でスキャンし直すのでなく（そうするとモアレが出る可能性あり）、現状（高解像度）のデータを画像処理で網点平滑化し、仕上がり解像度350dpi程度になるように画像を縮小するという意味です。このあたりのノウハウ、私も詳しいわけではないので、デジタルアーカイブなどにかかわっておられるかたがおられたらご教示いただければ幸いです。
（追記）何度もすみません。350dpiというのは一般論で、この画像の場合は網点の密度以上に解像度を上げても意味がないですね。
あと、ここにアップロードされる際に、JPEGやPNGやPDFは圧縮する必要ありません（圧縮してもサイズは変わらない）。
あと、この画像についていえば、JPEGだから画質が悪いのではなく、もともとの印刷の網点が見えてしまっているだけだと思います。画像編集ソフトで平滑化して網点除去するといいのかもしれません。
（念のため）低解像度でスキャンし直すのでなく（そうするとモアレが出る可能性あり）、現状（高解像度）のデータを画像処理で網点平滑化し、仕上がり解像度350dpi程度になるように画像を縮小するという意味です。このあたりのノウハウ、私も詳しいわけではないので、デジタルアーカイブなどにかかわっておられるかたがおられたらご教示いただければ幸いです。
（追記）何度もすみません。350dpiというのは一般論で、この画像の場合は網点の密度以上に解像度を上げても意味がないですね。
ファイルをコピーして試してみると確かに TeXworks が落ちますね……
放置していると落ちるというのはその時間はまだ dvipdfmx の PDF 作成が進行中なためです。dvipdfmx による PDF 作成が終わったタイミングで落ちます。（dvipdfmx の処理に数分かかります。）
画像の枚数が 10 枚程度までは大丈夫だったので、TeXworks の PDF ビューアーがメモリ不足で落ちているのではないかと思います。（PC のメモリが足りないわけではなく TeXworks が扱えるメモリサイズの制限によるものです。）
奥村先生が書かれているように画像を縮小してサイズを小さくすれば大丈夫になると思います。
リサイズと解像度変更が簡単にできるツールがあるといいのですが……
（画像サイズの変更だけならは Windows 標準の「フォト」でもできるのですが、解像度が 1200dpi のままになってしまうので PDF に取り込んだ時のサイズも小さくなってしまいますね……）
---
ちなみに、（PDF にそのままコピーするだけの）JPEG なのに dvipdfmx の処理にこんなに時間が掛かるのは、読み込みに使っているバッファサイズが 1024 バイトしかなく 20M のコピーに 20000 回の処理が必要になるから……
放置していると落ちるというのはその時間はまだ dvipdfmx の PDF 作成が進行中なためです。dvipdfmx による PDF 作成が終わったタイミングで落ちます。（dvipdfmx の処理に数分かかります。）
画像の枚数が 10 枚程度までは大丈夫だったので、TeXworks の PDF ビューアーがメモリ不足で落ちているのではないかと思います。（PC のメモリが足りないわけではなく TeXworks が扱えるメモリサイズの制限によるものです。）
奥村先生が書かれているように画像を縮小してサイズを小さくすれば大丈夫になると思います。
リサイズと解像度変更が簡単にできるツールがあるといいのですが……
（画像サイズの変更だけならは Windows 標準の「フォト」でもできるのですが、解像度が 1200dpi のままになってしまうので PDF に取り込んだ時のサイズも小さくなってしまいますね……）
---
ちなみに、（PDF にそのままコピーするだけの）JPEG なのに dvipdfmx の処理にこんなに時間が掛かるのは、読み込みに使っているバッファサイズが 1024 バイトしかなく 20M のコピーに 20000 回の処理が必要になるから……
自己レスですが。
確か画像フアイルは、バイトオーバーで、そちらのサーバーの容量制限に引つかかり添付できなかったと思います。とすると、画像なしでも、texworksのビユーワのメモリー制限を オーバーしているらしいので、ヨリ小さな容量の画像ファイルを使用してみたところで、画像なしより更にメモリーオーバーとなるはず。試みようとしていることは、試みる前に、「ムダ」という結論になるのでは？ viewerのメモリーオーバーというより、TeX自体のmemory overなのではないかしら？ logの末尾に記載されるアレです。
*****************************************************
[211] (./若菜集2.aux)
***********
pLaTeX2e <2023-02-14>+1, based on
LaTeX2e <2023-11-01> L3 programming layer <2024-01-04> ***********
)
Here is how much of TeX's memory you used:
16335 strings out of 476310
318505 string characters out of 5798434
1934373 words of memory out of 5000000
35105 multiletter control sequences out of 15000+600000
618131 words of font info for 118 fonts, out of 8000000 for 9000
28 hyphenation exceptions out of 8191
95i,9n,107p,908b,1025s stack positions out of 10000i,1000n,20000p,200000b,200000s
Output written on 若菜集2.dvi (221 pages, 332648 bytes).
================================================
texworksのviewerのmemory不足が原因だとしたら、texworksを通さずに、コマンドラインならPDFを無事に生成できるのでしょうか？
確か画像フアイルは、バイトオーバーで、そちらのサーバーの容量制限に引つかかり添付できなかったと思います。とすると、画像なしでも、texworksのビユーワのメモリー制限を オーバーしているらしいので、ヨリ小さな容量の画像ファイルを使用してみたところで、画像なしより更にメモリーオーバーとなるはず。試みようとしていることは、試みる前に、「ムダ」という結論になるのでは？ viewerのメモリーオーバーというより、TeX自体のmemory overなのではないかしら？ logの末尾に記載されるアレです。
*****************************************************
[211] (./若菜集2.aux)
***********
pLaTeX2e <2023-02-14>+1, based on
LaTeX2e <2023-11-01> L3 programming layer <2024-01-04> ***********
)
Here is how much of TeX's memory you used:
16335 strings out of 476310
318505 string characters out of 5798434
1934373 words of memory out of 5000000
35105 multiletter control sequences out of 15000+600000
618131 words of font info for 118 fonts, out of 8000000 for 9000
28 hyphenation exceptions out of 8191
95i,9n,107p,908b,1025s stack positions out of 10000i,1000n,20000p,200000b,200000s
Output written on 若菜集2.dvi (221 pages, 332648 bytes).
================================================
texworksのviewerのmemory不足が原因だとしたら、texworksを通さずに、コマンドラインならPDFを無事に生成できるのでしょうか？
画像返還と処理時間について
＊画像変換
奥村さんが提案されていた ImageMagic での変換ですが
https://qiita.com/hsagae/items/1320428f74ce57816197
を参考に
convert -filter point -interpolate Nearest ORIG.jpg NEW.png
などとして変換した NEW.png を使用すると警告メッセージもなく PDF 作成できます。
Windows での ImageMagic は scoop などでインストールできます。
＊処理速度は Apple M1 Max でですがいずれも 50 秒弱程度でした。参考までに。
＊画像変換
奥村さんが提案されていた ImageMagic での変換ですが
https://qiita.com/hsagae/items/1320428f74ce57816197
を参考に
convert -filter point -interpolate Nearest ORIG.jpg NEW.png
などとして変換した NEW.png を使用すると警告メッセージもなく PDF 作成できます。
Windows での ImageMagic は scoop などでインストールできます。
＊処理速度は Apple M1 Max でですがいずれも 50 秒弱程度でした。参考までに。
示された PDF ファイルから popplar のpdfimage を使って
pdfimages -all 若菜集2.pdf 挿画
で取り出し、適宜 rename して retry しました。
取り出した画像は 72dpi になっていました。
* poplar も scoop(windows) brew(osx) などで導入できます。
綺麗な挿絵付きのドキュメントにほっこりしています。
画像ファイルが一個増えているのでそれは無視し、
includegraphics のオプションが「viewport=0 0 270 320,angle=90」から
「width=\linewidth,angle=90]」に変更しているであろうと
予想して変更してほぼ同様の結果を得ました。
以下は、個人的な主観ではありますが、ソースファイルや PDF などを拝見して ...
1) documentclass のオプションで uplatex-dev の警告が出ています。
2) glyphwiki のページからダウンロードしたファイルの置き場所
bxglyphwiki のオプションに dir= を指定すると指定されたディレクトリに
glyphwiki からダウンロードキャッシュディレクトリに保存でき、
ソースファイルのディレクトリがスッキリします。
3) Widows and orphans が気になります
例えば、1ページ目の最後の行は、
次のページに送り出した方が読みやすいです。
1ページフルフルの画像が含まれているので
ページ数をそれなりに考慮しなければなりませんが、
一つの説（ブロック）がページ別れしてしまうのは
「詩」として読んでいてとても違和感があります。
書籍として出版＝ページ数削減が求められていない限り
「紙＝ページ」という枠があるので
ページを超えるブロックでないという制限はありますが、
一つのブロックは同一ページにした方が読みやすいと思います。
対処策としては neefspace パッケージを利用して、
このブロックは何行必要ですと記述すれば良いかと思います。
pdfimages -all 若菜集2.pdf 挿画
で取り出し、適宜 rename して retry しました。
取り出した画像は 72dpi になっていました。
* poplar も scoop(windows) brew(osx) などで導入できます。
綺麗な挿絵付きのドキュメントにほっこりしています。
画像ファイルが一個増えているのでそれは無視し、
includegraphics のオプションが「viewport=0 0 270 320,angle=90」から
「width=\linewidth,angle=90]」に変更しているであろうと
予想して変更してほぼ同様の結果を得ました。
以下は、個人的な主観ではありますが、ソースファイルや PDF などを拝見して ...
1) documentclass のオプションで uplatex-dev の警告が出ています。
2) glyphwiki のページからダウンロードしたファイルの置き場所
bxglyphwiki のオプションに dir= を指定すると指定されたディレクトリに
glyphwiki からダウンロードキャッシュディレクトリに保存でき、
ソースファイルのディレクトリがスッキリします。
3) Widows and orphans が気になります
例えば、1ページ目の最後の行は、
次のページに送り出した方が読みやすいです。
1ページフルフルの画像が含まれているので
ページ数をそれなりに考慮しなければなりませんが、
一つの説（ブロック）がページ別れしてしまうのは
「詩」として読んでいてとても違和感があります。
書籍として出版＝ページ数削減が求められていない限り
「紙＝ページ」という枠があるので
ページを超えるブロックでないという制限はありますが、
一つのブロックは同一ページにした方が読みやすいと思います。
対処策としては neefspace パッケージを利用して、
このブロックは何行必要ですと記述すれば良いかと思います。
書きかけで、へんなことになりました。
==========================================
まず、叮嚀に見ていただき、またアドヴァイスいただき、感謝いたします。
documentclass のオプションで uplatex-devの警告
▶ 対処方法ありますか？
bxglyphwiki のcache file の置き場所
▶ こういう事ができることだけは以前から知つて居ましたが使つたことはありません。
オプションの指定法？
\usepackage[dir=MyCache]{bxglyphwiki} % MyCacheはdirectory名
で良いのでしようか。
画像によって一つの詩が「ページ分かれ」している
▶ 私も以前から氣にはなつていました。
初版は、この点気にしていないようですが、これは避けた方がベター。
どうせ、ページの割り付け自体が初版とは異なるのだし、こんど直します。
今回の画像は前に使つていたものとは異なります
前のは私がスキャンしたもの。
今回のは、netに公開されたほかの方が作成されたもの。
小容量で綺麗だったので使用させていただいた
製作の過程でページの設定はいろいろ試します。
たとえば、フオントの大きさ、一行の文字数、Ⅰページの行数、
行間隔（アキ）、……などなど。
そうしている内に、行末のアキなどが、変わつていつてなかなか難しい。
==========================================
まず、叮嚀に見ていただき、またアドヴァイスいただき、感謝いたします。
documentclass のオプションで uplatex-devの警告
▶ 対処方法ありますか？
bxglyphwiki のcache file の置き場所
▶ こういう事ができることだけは以前から知つて居ましたが使つたことはありません。
オプションの指定法？
\usepackage[dir=MyCache]{bxglyphwiki} % MyCacheはdirectory名
で良いのでしようか。
画像によって一つの詩が「ページ分かれ」している
▶ 私も以前から氣にはなつていました。
初版は、この点気にしていないようですが、これは避けた方がベター。
どうせ、ページの割り付け自体が初版とは異なるのだし、こんど直します。
今回の画像は前に使つていたものとは異なります
前のは私がスキャンしたもの。
今回のは、netに公開されたほかの方が作成されたもの。
小容量で綺麗だったので使用させていただいた
製作の過程でページの設定はいろいろ試します。
たとえば、フオントの大きさ、一行の文字数、Ⅰページの行数、
行間隔（アキ）、……などなど。
そうしている内に、行末のアキなどが、変わつていつてなかなか難しい。
▶documentclass のオプションで uplatex-devの警告の対処方法
TeXLive 開発版でタイプセットしているのでなければ -dev を削除
▶bxglyphwiki のcache file の置き場所
オプションの指定法は「=」一個多いですが
基本以下で良いでしょう
\usepackage[dir=MyCache]{bxglyphwiki}% 要 事前に mkdir MyCache
ただし指定するディレクトリは小文字だけの方が良いように思います。
以下は私の macOS で発生したので調べた結果です。
macOS でファイル名の大文字小文字を区別しない運用しているのですが、
「mkdir MyCache」だと最初は書き込みできるのに
途中で書き込み不可でエラーになってしまいます。
NG 「dir=MyCache」で「mkdir MyCache」
OK 「dir=MyCache」で「mkdir mycache」
その他の例えば 「dir=Test」で「mkdir Test」 でも問題はないのですが。
TeXLive 開発版でタイプセットしているのでなければ -dev を削除
▶bxglyphwiki のcache file の置き場所
オプションの指定法は「=」一個多いですが
基本以下で良いでしょう
\usepackage[dir=MyCache]{bxglyphwiki}% 要 事前に mkdir MyCache
ただし指定するディレクトリは小文字だけの方が良いように思います。
以下は私の macOS で発生したので調べた結果です。
macOS でファイル名の大文字小文字を区別しない運用しているのですが、
「mkdir MyCache」だと最初は書き込みできるのに
途中で書き込み不可でエラーになってしまいます。
NG 「dir=MyCache」で「mkdir MyCache」
OK 「dir=MyCache」で「mkdir mycache」
その他の例えば 「dir=Test」で「mkdir Test」 でも問題はないのですが。
エクスプローラで目的のディレクトリが表示できれば
そのフォルダを右クリックして表示されるサブメニュー
にターミナルで開くなどの選択ができます。
あとは -output-directory out を
タイプセットのコマンドオプションに追加も検討しておいてください
行頭が揃わないのは、ルビを振った文字列が行頭に来たときですね。
なんとなく、空白が入り込んでいますね。
またルビの振り仮名の文字間が異様の広いのも気になります。
その辺をマニュアル見ながら調整中です。
それとデフォルトにしようとして rubysetup をコメントアウトすると
「松島瑞 寺に遊び葡萄 栗鼠の木彫を観て」のところでエラーになってしまう
件もおいおい調べてみたいと思います。
そのフォルダを右クリックして表示されるサブメニュー
にターミナルで開くなどの選択ができます。
あとは -output-directory out を
タイプセットのコマンドオプションに追加も検討しておいてください
行頭が揃わないのは、ルビを振った文字列が行頭に来たときですね。
なんとなく、空白が入り込んでいますね。
またルビの振り仮名の文字間が異様の広いのも気になります。
その辺をマニュアル見ながら調整中です。
それとデフォルトにしようとして rubysetup をコメントアウトすると
「松島瑞 寺に遊び葡萄 栗鼠の木彫を観て」のところでエラーになってしまう
件もおいおい調べてみたいと思います。
▶rubysetup の変更をコメントアウトすると途中でエラーになる
→原因は 2425 行目のルビの振り仮名「{ずい|がん|じ }
に空白が含まれていたためだと思われます。
「じ」の直後の空白を取り除くと正常になりました。
▶ルビの文字間が異様に空いている
→挫折
調べたけどよくわからない。
目次のところはいい感じなのですが、
本文はルビ以外も文字の縦方向感が広いのでそれが影響しているかもしれません。
▶行頭で \ruby{...}{...} があるとやや文字が下がってしまい行頭が不揃い
→妥協案です。
マニュアルによると行頭であれば「||->] で
コントロールできそうですがうまくゆかず
下がっている分およそ4/18em ないし 5/28em 上げるという
強引な方法で対処してみました。
原理は「\!」で3/18em だけマイナス方向の空白が入れられます。
一個だけでは不十分ですが二個だと逆に飛び出てしまいます。
-4/18em や -5/18em だけバックするコマンドがないため
\:( 4/18em の空白）ないし\;（5/18em の空白）を併用し
「\!\!\!\;」つまり(-3/18em X 3) ＋ 5/18em で
結果として 4/18em だけ戻すようにしたところ
見た目上はほぼほぼ行頭が揃うようになりました。
これを行頭で始まる ruby に対して反映させるため
\newcommand{\RUBY}[2]{\!\!\!\;\ruby[||-|]{#1}{#2}}
を定義し、若菜集2.tex は以下の perl one-liner で
一括変換しています。
perl -i.backup -pne 's/^(.noindent |)(.)(ruby)([{])/$1$2RUBY$4/' 若菜集2.tex
「\noindet \ruby{」ないし「\ruby{」
で始まる ruby を RUBY（大文字）に変更するという操作です。
でも一部行頭で始まる \ruby には group ルビもいくつかあったので
とりあえず手作業で熟語ルビに変換しておきました。
テストに使用したソースを添付しますが、
includegraphics する画像ファイルのパスはカレントになっています
glyphwiki からダウンロードするディレクトリは bxgw にしています
ので適宜修正してください。
→原因は 2425 行目のルビの振り仮名「{ずい|がん|じ }
に空白が含まれていたためだと思われます。
「じ」の直後の空白を取り除くと正常になりました。
▶ルビの文字間が異様に空いている
→挫折
調べたけどよくわからない。
目次のところはいい感じなのですが、
本文はルビ以外も文字の縦方向感が広いのでそれが影響しているかもしれません。
▶行頭で \ruby{...}{...} があるとやや文字が下がってしまい行頭が不揃い
→妥協案です。
マニュアルによると行頭であれば「||->] で
コントロールできそうですがうまくゆかず
下がっている分およそ4/18em ないし 5/28em 上げるという
強引な方法で対処してみました。
原理は「\!」で3/18em だけマイナス方向の空白が入れられます。
一個だけでは不十分ですが二個だと逆に飛び出てしまいます。
-4/18em や -5/18em だけバックするコマンドがないため
\:( 4/18em の空白）ないし\;（5/18em の空白）を併用し
「\!\!\!\;」つまり(-3/18em X 3) ＋ 5/18em で
結果として 4/18em だけ戻すようにしたところ
見た目上はほぼほぼ行頭が揃うようになりました。
これを行頭で始まる ruby に対して反映させるため
\newcommand{\RUBY}[2]{\!\!\!\;\ruby[||-|]{#1}{#2}}
を定義し、若菜集2.tex は以下の perl one-liner で
一括変換しています。
perl -i.backup -pne 's/^(.noindent |)(.)(ruby)([{])/$1$2RUBY$4/' 若菜集2.tex
「\noindet \ruby{」ないし「\ruby{」
で始まる ruby を RUBY（大文字）に変更するという操作です。
でも一部行頭で始まる \ruby には group ルビもいくつかあったので
とりあえず手作業で熟語ルビに変換しておきました。
テストに使用したソースを添付しますが、
includegraphics する画像ファイルのパスはカレントになっています
glyphwiki からダウンロードするディレクトリは bxgw にしています
ので適宜修正してください。
大分お手間を煩わせしたと思います。有り難うございました。
私の方でも『行頭不揃い』の原因を究明しておりました。
見つけました。shiika環境とpxrubricaパッケージとの相性が良くなかつたのです。
約60組近いshiika環境のうち、「前書き」はrubyと無関係なので、これを除き総てをコメントアウトしたところ『行頭不揃い』は解消しました。
ただこうすると、全体のバランスが崩れますので、修正が必要となりました。
和田さんの成果とこの修正を反映したものを添付致します。
ただ、私としてはshiika 環境が使えないのはとても惜しいと思います。
これは、藤田眞作さんが、「和歌」を念頭に製作されたもので、
字間の四分アキだか六分アキだか存じませんが、このアキが大層
美しくお気に入りなのです。ルビを使うときは同じ藤田眞作さんのfurikanaパッケージを使えばよいのかも知れません。今回は面倒だから試さないですが。
添付フアイルをご覧下さい。
私の方でも『行頭不揃い』の原因を究明しておりました。
見つけました。shiika環境とpxrubricaパッケージとの相性が良くなかつたのです。
約60組近いshiika環境のうち、「前書き」はrubyと無関係なので、これを除き総てをコメントアウトしたところ『行頭不揃い』は解消しました。
ただこうすると、全体のバランスが崩れますので、修正が必要となりました。
和田さんの成果とこの修正を反映したものを添付致します。
ただ、私としてはshiika 環境が使えないのはとても惜しいと思います。
これは、藤田眞作さんが、「和歌」を念頭に製作されたもので、
字間の四分アキだか六分アキだか存じませんが、このアキが大層
美しくお気に入りなのです。ルビを使うときは同じ藤田眞作さんのfurikanaパッケージを使えばよいのかも知れません。今回は面倒だから試さないですが。
添付フアイルをご覧下さい。
色々書いているうちに 部 shiika 環境を使わない
バージョンのソースがアップされていましたが、
shiika 環境を使用して前のソースで、
「ルビの突出禁止や進入を見直し」しています。
親文字の字数の２倍以上のルビ文字数がある場合は
\rubysetup{||hj)}（*1） の影響もあり空白ができてしまいます。
特に３ページ目には行頭に親文字数 1 ルビ文字数 3 のものがあり、
「||」の「前突出禁止」が影響して異様すぎる空白ができてしまっていました。
(*1) 「||hj)」「前突出禁止、肩付き、熟語ルビ、後進入小」だと
「前突出禁止」や「肩付き」が影響してルビ文字数によっては、
どちらかというと下方向に領域が広がってしまい、
全体的にルビが振られた後ろに間延び感が生じているようです。
また、デフォルトの「|cjPeF|」だと
前進入、後進入が小さすぎるようで全体的に間延び感が残ります。
特に行頭にあるルビ部分で折角持ち上げた親文字部分が、
ルビの影響で下がってしまうなどの副作用が出てしまいました。
そこで思い切って前後の「進入」を「大」にする
「」「前進入大、熟語ルビ、後進入大」すると昨夜よりは改善できたようです。
簡単なチェックは2ページ目や３ページ目で確認できると思います。
みた限りでは
親文字が一つであればルビ三文字まで
親文字が二つであればルビ四文字まで
はあまり違和感はありません。
これを超えると空きが目立ちます。
この調整を行なっても「{都鳥}{みやこ|どり} のようにルビ文字数が
親文字の字数より２倍を超える場合をのぞいて、かなり改善できているように見えます。
変更メモ
1) rubysetup を 「||hj)」から「」に変更
2) それに伴い 行頭の \ruby 用の \RUBY を同様に変更
3) さらに \ruby[g] を \ruby[] に変更
4) \RUBY で上にさらに 1/18 em 持ち上げた方が良かったので微調整
1) 2) 4) は手作業ですが、3) は perl one liner で一括修正。
熟語ルビ ( から全部グループルビ にしても見た目は変わりありませんでした。
検証したものをアップしておきます。
なお https://okumuralab.org/tex/mod/forum/discuss.php?d=3692&parent=23047
でアップされていた不内容を見て
glyphwiki のデータは mycache
画像ファイルは mygraphics
に変更してあります。
バージョンのソースがアップされていましたが、
shiika 環境を使用して前のソースで、
「ルビの突出禁止や進入を見直し」しています。
親文字の字数の２倍以上のルビ文字数がある場合は
\rubysetup{||hj)}（*1） の影響もあり空白ができてしまいます。
特に３ページ目には行頭に親文字数 1 ルビ文字数 3 のものがあり、
「||」の「前突出禁止」が影響して異様すぎる空白ができてしまっていました。
(*1) 「||hj)」「前突出禁止、肩付き、熟語ルビ、後進入小」だと
「前突出禁止」や「肩付き」が影響してルビ文字数によっては、
どちらかというと下方向に領域が広がってしまい、
全体的にルビが振られた後ろに間延び感が生じているようです。
また、デフォルトの「|cjPeF|」だと
前進入、後進入が小さすぎるようで全体的に間延び感が残ります。
特に行頭にあるルビ部分で折角持ち上げた親文字部分が、
ルビの影響で下がってしまうなどの副作用が出てしまいました。
そこで思い切って前後の「進入」を「大」にする
「」「前進入大、熟語ルビ、後進入大」すると昨夜よりは改善できたようです。
簡単なチェックは2ページ目や３ページ目で確認できると思います。
みた限りでは
親文字が一つであればルビ三文字まで
親文字が二つであればルビ四文字まで
はあまり違和感はありません。
これを超えると空きが目立ちます。
この調整を行なっても「{都鳥}{みやこ|どり} のようにルビ文字数が
親文字の字数より２倍を超える場合をのぞいて、かなり改善できているように見えます。
変更メモ
1) rubysetup を 「||hj)」から「」に変更
2) それに伴い 行頭の \ruby 用の \RUBY を同様に変更
3) さらに \ruby[g] を \ruby[] に変更
4) \RUBY で上にさらに 1/18 em 持ち上げた方が良かったので微調整
1) 2) 4) は手作業ですが、3) は perl one liner で一括修正。
熟語ルビ ( から全部グループルビ にしても見た目は変わりありませんでした。
検証したものをアップしておきます。
なお https://okumuralab.org/tex/mod/forum/discuss.php?d=3692&parent=23047
でアップされていた不内容を見て
glyphwiki のデータは mycache
画像ファイルは mygraphics
に変更してあります。
行頭で \ruby{...}{...} があるとやや文字が下がってしまい行頭が不揃い
これはpxrubricaの仕様によるものです。
マニュアル2.2節の「前補助設定」「後補助設定」の説明を見ると、
空白挿入量の既定値は和文間空白である。
とあります。shiika環境では和文間空白が四分空き（つまり\kanjiskip＝0.25zw）であるため、ルビ付き文字の前後にその分の空きが入るわけです。
もちろん折り返し行頭でこの空きが入るのは正しくないのですが、そもそも「前後の状態を考慮して自動処理する」のがpTeX系では難しいため、pxrubricaではそこは「前補助設定」「後補助設定」で手動で調整する仕様になっています。
例えば折り返し行頭直後の\rubyで前に空きを入れたくない（後は入れる）場合は
\ruby[.-]{漢字}{かん|じ}です。
と指定します。
ただし（既に話題に出ている通り）pxrubricaはいわゆる「空け組」（和文間空白がゼロでない組み方）に対応できていません。少し実装コードを見返しましたが、ほとんど何も考慮してないため、不可解な動作が起こることもありそうです。
そもそもpxrubricaが根拠としているJIS規格のルビの規則が「空け組」でないことを前提にしているので、対処するのは難しそうです。
（むしろルビ付き文字の部分は\kanjiskipを強制的にゼロに設定すべき？）