ご質問はこちらへ
dvipdfmxの非全角幅のCID文字の扱い,VFの扱い
下記のTeXソース(このメッセージの末尾)で,\char 3つで「T」「e」「X」と印字されますが(合計3zw),
文字送りがJFMと一致しませんでした。
VFはotfパッケージからお借りしたものです。
具体的には
===TeX ===
のように文字が詰まって印字されます
JFMでは3文字がそれぞれ1zwなので,
===T e X ===
となることを想像していました。
これはdvipdfmxの仕様でしょうか。
---
dvipdfmxのvf.cでは0xf2(LONG_CHAR)エントリの文字幅はskip_bytesで捨てており,
/* Skip over TFM width since we already know it */
skip_bytes (4, vf_file);
とあります(似たような箇所が複数箇所)。それ以降は私には追いかけられなかったのですが,結果的に3zw進んでいるので直接の原因ではないと思いました。
---
また,論点がずれますが,LONG_CHARエントリのSET2に続けてRIGHTを置いてもRIGHTは必ず無視されるようでした。
LONG_CHAR
SET2<XXXX>
RIGHT3<XXXXXX>
のような並びのときです。
---
さらに,
LONG_CHAR
SET2<XXXX>
SET2<1>
のように本来の文字の後ろにCID 1(空白)を付け足したVFを作ったところ,「TeX」という文字列が「右から左」に印字されるという現象もありました。dvipdfmxのlr_modeはデフォルトでは「右から左」なのでしょうか(RIGHTが効かないこととも関連がありますでしょうか)。
---
いずれにしろ,SET2で(同一フォントで?)非全角文字を連続で置いたとき,JFMの文字幅が1文字ずつ反映されないように思います(JFMの文字幅が反映されるほうが自然だと思います)。
また,VFにあるはずのRIGHT等(スキップ関連?)が無視される理由が分かりません(逆に通常の和文JFMで括弧などが正常に印字されることに対して合致しない挙動のようにも思いますが,頭がこんがらかってしまいました。
主なテストはTeX Live 2021で行い,メッセージ末尾のTeXソースはTeX Live 2023でも確認しました。mapファイルは「ヒラギノ」「リュウミン」1書体ずつで確認しましたが結果は同じでした(埋め込むOpenType依存ではなさそうです)。
TeX Live 2023 (Windows 11, ARM64):
e-pTeX 3.141592653-p4.1.0-230214-2.6 (utf8.sjis) (TeX Live 2023)
kpathsea version 6.3.5
ptexenc version 1.4.3
This is dvipdfmx Version 20220710 by the DVIPDFMx project team,
modified for TeX Live,
an extended version of dvipdfm-0.13.2c developed by Mark A. Wicks.
TeX Live 2021 (macOS Ventura, universal-darwin):
e-pTeX 3.141592653-p3.9.0-210218-2.6 (utf8.euc) (TeX Live 2021)
kpathsea version 6.3.3
ptexenc version 1.3.9
This is dvipdfmx Version 20210318 by the DVIPDFMx project team,
modified for TeX Live,
an extended version of dvipdfm-0.13.2c developed by Mark A. Wicks.
以下,TeXソースです。
---
% encoding: utf-8
\documentclass{jarticle}
\begin{document}
\parindent0zw
\font\f=cidjmr2-h at20pt
\f
===%
\char\jis"4448 % 槌 => T
\char\jis"4459 % 潰 => e
\char\jis"444C % 通 => X
===%
\end{document}
Windows/Fonts とは別の場所にあるフォントを使いたい(パスを通す?)
https://okumuralab.org/tex/mod/forum/discuss.php?d=3612
で質問をさせていただいた者です.
恐らく TeX Live のパスの設定の問題だと思い,別にスレッドを立てさせていただきました.
さて,私は Adobe Acrobat 2020 を2台のPCにインストールしています.1台は Windows 10 機,もう1台は Windows 11 機です.
フォント KozMinPr6N-Regular.otf は両機それぞれ
C:\Program Files (x86)\Adobe\Acrobat 2020\Resource\CIDFont
にあります.また,どちらの C:\Windows\Fonts にもありません.
https://okumuralab.org/tex/mod/forum/discuss.php?d=3612
で教えていただいた方法は,Windows10機では成功しましたが,Window11機では
Package fontspec Error: The font "KozMinPr6N-Regular" cannot be found.
というエラーが出て,止まりました.
Acrobat インストールの際は標準設定のまま進めました.また,上記の方法を試す際,フォント関係の設定は何もいじっていません.よって,恐らく TeX Live をインストールする際,後者では何かパス関係の設定を忘れており,これが原因で失敗するのではないかと考えております.
そこで質問ですが,TeX Live のパス関係の設定を後からやり直す方法はありますでしょうか.それとも TeX Live を最初からインストールし直すしかないのでしょうか.
ご存じの方,ご教示賜れば幸いです.
山下
文献参照の方法
TeXLive2023におけるotf.sty(uplatex)で\CID{}表記が使えない
cloudlatexを使用しております。 cloudlatexではuplatexのコンパイラに安定版(TeXLive2022のもの)と開発版(TeXLive 2023のもの)を使い分けられるのですが,2023のものをコンパイラに選択すると以下のような, texファイルがコンパイルできません。2022のものではコンパイルできます。 不具合または仕様変更でしょうか?
\documentclass[uplatex]{jlreq}
\usepackage{otf}
\begin{document}
\CID{8705}
\end{document}
なお, \UTF{9AD9}とした場合には出力されます。
ダブルスペースで印刷する方法
BBEditでLaTeXを使っておられる方へ、 ご報告です。
ご報告です。(ヒヨッとしたら既知の事柄かも知れませんが)
昨日、BBEdit14にグレードアップした際、新規の機能について
検索していたら
『modern latex with bbedit and tectonic』
と言う記事を見つけました。
[https://ineed.coffee/post/modern-latex-with-bbedit-and-tectonic]
The Tectonic Typesetting System
[[https://tectonic-typesetting.github.io/en-US/]]
以前『BBEditでLaTeX』を『辻森先生から頂いた』設定で実施していましたが、
今回はXeLaTeXでのコンパイルについて書かれていたので早速
Mac OS10.11.6.8 BigSurに環境を整備して試してみました。
requirements
Skim (brew install skim)
Tectonic (brew install tectonic)
TexLab (brew install texlab)
iTerm2
と書かれている内の不足分Tectonic&TexLabを「brew install」
01)TeX Compile PDF.scpt
02)TeX Open PDF.scpt
2つのスクリプトもLibrary>Application Support>BBEdit> Scriptsへ配置。
TeX WiKi BXjsclsのサンプル「例(XeLaTeX + bxjsarticle クラス)」を
BBEditに書き込んでスクリプト・メニューから
『TeX Compile PDF』を選択しコンパイル実行!
TeX WiKi XeTeXの項目に書かれている『XeLaTeX で日本語』
XeLaTeX では BXjscls が使用可能です。から逆引きしました。
音楽家なので、必然的に英独仏などの外国語を併記して
使うことが多いので多国語latex環境が使えたTeXworksを
XeLaTeXでコンパイルしていました。此れもかなり昔の事。
奥村先生の「LaTeX2e 改訂第5版」が暫くして6版に成る前の事。
今回は、懐かしさのあまり『XeLaTeX』をついつい触ってみました。若松久仁光拝
追伸
関連箇所へのリンクを書いていますが、以前の様なWiKi Linkが機能する様に
書き込むには、どのタイプのフォーマットで投稿したら宜しいのでしょうか?
アドバイスを頂ければ幸甚です。
sn-jnl.clsを使ったタイプセット
\renewcommandと\RenewDocumentCommandで挙動が変わるのはなぜでしょうか?
\renewcommandと\RenewDocumentCommandで挙動が変わるものがあり、理由がよくわからず気になっています。
再現できると思われる最小のソースを以下に示します。所望の出力は添付PDFのものです。
\renewcommandを使った際† は\refを用いて「Listing 1.1に示す」「Listing 2.1に示す」と望み通り参照できるものの、\RenewDocumentCommandを使った際†† は\refすると「Listing 1.0に示す」「Listing 2.0に示す」と番号がおかしくなってしまいます。
† \renewcommand{\thelstlisting}{\arabic{section}.\arabic{lstlisting}}とした際
†† \RenewDocumentCommand\thelstlisting{}{\arabic{section}.\arabic{lstlisting}}とした際
ひとまず\RenewDocumentCommandではなく\renewcommandを使うことで対処していますが、この挙動の違いの理由が気になります。
理由がお分かりの方いらっしゃいましたら、ぜひご教示お願いします。
※ \AtBeginDocument内の記述はhttps://ta-b0.hateblo.jp/entry/2020/08/13/001223を参考にしました。
\documentclass{jlreq}
\usepackage{listings}
\makeatletter
\AtBeginDocument{
\renewcommand{\thelstlisting}{\arabic{section}.\arabic{lstlisting}} % うまくいく
% \renewcommand{\thelstlisting}{\arabic{section}.\protect\arabic{lstlisting}} % うまくいかない
% \RenewDocumentCommand\thelstlisting{}{\arabic{section}.\arabic{lstlisting}} % うまくいかない
\@addtoreset{lstlisting}{section}
}
\makeatother
\begin{document}
\section{hoge}
Listing~\ref{list:hoge}に示す。
\begin{lstlisting}[caption=hoge,label=list:hoge]
print("Hello, LaTeX!")
\end{lstlisting}
\section{fuga}
Listing~\ref{list:fuga}に示す。
\begin{lstlisting}[caption=fuga,label=list:fuga]
print("Oh, TeX...")
\end{lstlisting}
\end{document}
(LuaLaTeX)