js 기반 클래스

jsarticle에 “10포인트”라고 지정한 일본어 본문을 실제로 재 보면 9.25포인트 남짓밖에 되지 않습니다. 이는 결함이 아니라 설계입니다. 오쿠무라 하루히코의 jsclasses(jsarticle, jsbook)는 라틴 문자의 10 pt가 아니라 일본어 인쇄가 쓰는 13급(3.25 mm) 을 기준으로 본문을 짜기 때문입니다. js 계열 클래스는 LaTeX 표준 클래스의 사용감을 그대로 두고, 일본어에 필요한 것만 바꿉니다. 폰트 메트릭, 글자 크기의 눈금, 그리고 그것을 확대·축소하는 장치입니다. ltjsclasses는 이 설계를 LuaLaTeX으로, BXjscls는 모든 엔진으로 옮겼습니다. 이 페이지에서는 세 계열이 각각 무엇을 풀었는지, 그리고 무엇을 고를지 살펴봅니다.

jsclasses가 표준 클래스에서 바꾼 두 가지

jsclasses에 딸린 매뉴얼이 “표준 도큐먼트 클래스와의 차이”로 드는 것은 일본어 폰트 메트릭과 크기 옵션의 처리 두 가지뿐입니다. 여백이나 행간의 사상을 새로 쓴 것이 아니라, 일본어를 조판할 때 실제로 망가지던 두 곳을 고친 것이 jsclasses의 출발점입니다. 첫째, 일본어 TFM으로 예전의 min10, goth10 대신 도쿄쇼세키인쇄의 고바야시 하지메 가 만든 JIS 폰트 메트릭 jis.tfm, jisg.tfm 을 씁니다. 둘째, 크기 지정을 다시 만들었습니다. 표준 클래스는 10pt, 11pt, 12pt 세 단계뿐이었고, 매뉴얼의 표현을 빌리면 표준인 10포인트를 벗어나면 글꼴의 균형이 다소 무너지는 상태였습니다.

이 둘은 사실 같은 뿌리에서 나옵니다. 일본어 인쇄는 글자 크기를 급(Q, 1급 = 0.25 mm) 으로 세고, 본문은 13급 곧 3.25 mm가 정석입니다. 그런데 JIS 폰트 메트릭의 전각은 그대로 두면 13.527급이므로, jsclasses는 일본어 글꼴을 0.961배(= 13 ÷ 13.527) 하여 전각을 정확히 13급에 맞춥니다. 매뉴얼은 이 계산을 그대로 적어 두고, 9.62216 pt 메트릭을 0.961배 한 결과 “공칭 10포인트라 해도 실은 9포인트 남짓”이라고 밝힙니다. 이 비율은 실수 매크로 \Cjascale 에 들어 있으며, jsarticle, jsbook, jsreport에서는 0.924690(= 9.62216 pt × 0.961 ÷ 10 pt)입니다. 2018년 이후의 OTF 패키지는 이 값을 읽어 일본어 크기를 맞춥니다.

% upLaTeX: the dvipdfmx option is a global option for graphicx/hyperref
\documentclass[uplatex,dvipdfmx,a4paper,papersize]{jsarticle}
\begin{document}
こんにちは、\LaTeX！
\end{document}

클래스 구성은 jsarticle(논문·보고서), jsbook(책), jsreport(보고서) 셋이고, 그 밖에 학회지용 jspf와 기요용 kiyou가 함께 들어 있습니다. jsreport는 2017년 2월, 게시판 논의를 계기로 그전까지 jsbook의 report 옵션으로 대신하던 쓰임을 독립시킨 클래스입니다. 원래 오쿠무라가 LaTeX3 Project의 classes.dtx 와 주식회사 ASCII의 jclasses.dtx 를 바탕으로 썼고, 2009년에 다나카 다쿠지 의 upLaTeX 지원 패치가 병합되었으며, 2016년 7월부터 일본어 TeX 개발 커뮤니티(GitHub의 texjporg/jsclasses)가 유지 관리합니다. TeX Live에 기본 포함되어 있어 따로 설치할 필요가 없습니다.

\mag과 nomag — 글자 크기는 어떻게 만들어지는가

jsclasses는 본문을 10포인트로 조판한 다음, TeX의 프리미티브 \mag 으로 문서 전체를 확대·축소해 지정한 크기에 맞춥니다(11pt는 1.095배, 12pt는 1.200배). 그래서 표준 클래스에 없는 등비수열 크기 8pt, 9pt, 14pt, 17pt, 20pt, 21pt, 25pt, 30pt, 36pt, 43pt와 급 단위의 12Q, 14Q, 실치수의 10ptj, 10.5ptj, 11ptj, 12ptj까지 마련할 수 있습니다. \mag은 용지도 글자도 괘선도 한꺼번에 늘리므로 발상은 강력하지만, 그 값을 이해하지 못하는 도구가 있고 뒤 단계의 dvipdfmx나 dvips 처리에 결과가 좌우된다는 약점이 있었습니다.

실무에서는 기본값 usemag으로 시작해도 됩니다. geometry나 그림 배치, PDF 후처리에서 실제로 치수가 맞지 않을 때 nomag*를 시험하는 순서가 안전합니다. 처음부터 모든 옵션을 넣기보다, 같은 절차로 같은 PDF가 나오는 재현성을 우선하세요. 또한 \mag을 쓰는 문서는 뒤따르는 모든 DVI 도구에 “확대율이 걸려 있다”는 사실을 전해야 하므로, 공동 작업에서는 확대 방식도 빌드 절차와 한 세트로 정해 두면 사고가 줄어듭니다.

jsarticle은 pLaTeX인가 upLaTeX인가

둘 다 됩니다. 클래스가 스스로 판별하기 때문입니다. \documentclass{jsarticle}만 쓰고 upLaTeX으로 처리하면 로그에 Class jsarticle Info: Autodetected engine: upLaTeX가 나오고 일본어 내부 인코딩이 JY2/JT2로 바뀝니다. pLaTeX이면 Autodetected engine: pLaTeX입니다. 그래도 클래스 옵션에 uplatex(또는 platex, autodetect-engine)를 적는 이유는 두 가지입니다. 의도를 원고에 남기기 위해서, 그리고 어긋났을 때 조용히 다른 체재로 통과하는 일을 막기 위해서입니다. 지정과 실제 처리계가 어긋나면 클래스는 통과시키지 않습니다. ! Class jsarticle Error: Option 'platex' is specified but you are running upLaTeX. 처럼 분명히 멈춥니다.

반면 dvipdfmx 는 클래스 옵션이 아닙니다. jsclasses가 해석하지 않는 지정은 전역 옵션으로 뒤따르는 패키지에 전달되고, graphicx, color, hyperref가 그것을 보고 드라이버를 고릅니다. 그래서 \documentclass의 대괄호에 한 번 쓰면 패키지마다 따로 쓸 필요가 없어집니다. 흔한 [uplatex,dvipdfmx]의 정체는 그것뿐입니다.

A5로 짰는데 PDF가 A4로 나올 때

a5paper라고 썼는데 PDF가 A4로 나온다면 원인은 클래스가 아니라 DVI에 용지 치수가 적혀 있지 않다는 점입니다. TeX Live 2024에서 \documentclass[uplatex,a5paper]{jsarticle}을 조판해 dvipdfmx에 넘기면 나오는 PDF는 595.28 × 841.89 pt, 곧 A4입니다. DVI 자체에는 용지라는 개념이 없어 dvipdfmx가 자기 기본값을 쓰기 때문입니다. 클래스 옵션에 papersize 를 더하면 \special{papersize=...}가 기록되고, 같은 원고가 419.53 × 595.28 pt의 A5로 나옵니다. tombow를 함께 쓰면 톰보만큼 커져서 A5는 563.53 × 739.28 pt, 즉 사방에 1인치씩 더해집니다. LuaLaTeX(다음 절의 ltjsclasses)은 PDF를 직접 쓰므로 이 문제가 생기지 않습니다.

ltjsclasses — LuaLaTeX으로 옮긴 jsclasses

ltjsclasses는 jsclasses를 LuaLaTeX(LuaTeX-ja) 용으로 다시 쓴 클래스 모음이며 LuaTeX-ja 프로젝트가 유지 관리합니다. ltjsarticle, ltjsbook, ltjsreport(그 밖에 ltjspf, ltjskiyou)를 제공하고 이름 그대로 jsclasses와 일대일로 대응합니다. 여기서 가장 큰 차이는 확대 방식입니다. LuaTeX 공식 매뉴얼은 \mag에 의한 확대가 DVI 출력 모드에서만 지원된다고 분명히 적고 있어, PDF를 직접 쓰는 LuaLaTeX에서는 쓸 수 없습니다. 그래서 ltjsclasses는 nomag*를 기본값으로 두고, usemag을 지정하면 This ltjsarticle cls does not support 'usemag' option, since LuaTeX does not support \mag in pdf output 이라고 경고한 뒤 nomag*로 되돌립니다.

엔진 관련 옵션의 처리도 달라집니다. uplatex를 넘기면 오류(this class does not support 'uplatex' option)가 나고, autodetect-engine은 경고만 내고 무시됩니다. 처리계가 하나뿐이니 자연스러운 설계입니다. 일본어 메트릭은 LuaTeX-ja의 표준인 jfm-ujis.lua가 기본이고, ptexjis 옵션을 붙이면 jsclasses와 같은 JIS 메트릭(jfm-jis.lua)으로, mingoth이면 예전의 jfm-min.lua로 바뀝니다. 글꼴을 바꿀 때는 luatexja-fontspec을 함께 써서 OS에 설치된 OpenType 글꼴을 이름 그대로 지정할 수 있습니다.

% compile with lualatex; nomag* is already the default here
\documentclass[a4paper]{ltjsarticle}
\usepackage{luatexja-fontspec}
\setmainjfont{Noto Serif CJK JP}
\setsansjfont{Noto Sans CJK JP}
\begin{document}
こんにちは、\LaTeX！
\end{document}

BXjscls — 같은 원고를 어느 엔진에서도

BXjscls(야토 다카유키, 통칭 ZR)는 jsclasses의 설계를 어느 엔진에서나 쓸 수 있게 넓힌 클래스 모음으로, bxjsarticle, bxjsbook, bxjsreport, bxjsslide를 제공합니다. 여기서 가장 먼저 걸리는 것이 엔진 지정 방법입니다. 엔진은 engine=이 아니라 맨 클래스 옵션으로 씁니다. lualatex, xelatex, pdflatex, platex, uplatex, latex, platex-ng 중 하나이거나 자동 판별인 autodetect-engine입니다. engine=lualatex라고 쓰면 지정이 전달되지 않아 ! Class bxjsarticle Error: An engine option must be explicitly given. 에서 멈춥니다.

% the engine is a bare option; ja= picks the Japanese driver
\documentclass[lualatex,ja=standard,a5paper]{bxjsarticle}
\begin{document}
こんにちは、\LaTeX！
\end{document}

% same body, different engine: swap the first option only
% \documentclass[uplatex,ja=standard,dvipdfmx,a5paper]{bxjsarticle}

두 번째 키는 ja=(예전 이름 jadriver)로, 일본어 처리 방식을 standard, minimal, modern, pandoc 중에서 고릅니다. 진짜 함정이 여기에 있습니다. ja=를 생략하면 (u)pLaTeX일 때만 standard가 보충되고, 그 밖의 엔진에서는 The option 'ja' is MISSING!! So 'ja=minimal' is assumed as fallback, but such implicit setting is now DEPRECATED! 라는 경고와 함께 minimal이 됩니다. 반대로 ja=를 적으면 엔진 옵션을 명시하는 것이 필수가 됩니다. 그러니 실무에서는 엔진과 ja=를 언제나 한 쌍으로 적는 것이 유일하게 안전한 형태입니다. ja=standard를 고르면 엔진마다 알맞은 일본어 패키지가 읽힙니다.

치수와 관련된 어휘는 jsclasses와 jlreq 양쪽에 맞춰 두었습니다. 라틴 문자 기준 크기는 base=(별칭 fontsize=), 일본어는 jbase=(별칭 jafontsize=), 일본어 스케일 비율은 scale=(별칭 jafontscale=)이며 기본값은 \jsScale = 0.924715(\Cjascale도 같은 값을 가리킵니다)입니다. 판면은 textwidth=, number-of-lines= 외에 jlreq와 같은 철자인 line_length=, number_of_lines=로도 쓸 수 있습니다. 확대 방식은 magstyle=으로 usemag, nomag, nomag*를 고를 수 있지만, LuaTeX v0.87 이후와 pTeX-ng에서는 기본값이 nomag*로 바뀌고 magstyle=usemag를 지정하면 ! Class bxjsarticle Error: The engine does not support 'magstyle=usemag' 로 멈춥니다.

jsclasses·ltjsclasses·BXjscls 중 무엇을 고를까

먼저 엔진을 정하고, 그에 맞는 클래스를 고르는 것이 순서입니다. 같은 “jsarticle풍 체재”라도 처리계가 바뀌면 클래스 이름이 바뀝니다. 반대로 클래스만 바꾸고 엔진을 그대로 두면 일본어 처리 자체가 사라져 체재가 무너집니다.

• pLaTeX/upLaTeX을 쓴다면 jsclasses. 기존 자산이나 투고 규정으로 처리계가 정해진 경우의 정석입니다. \documentclass[uplatex,dvipdfmx,papersize]{jsarticle}에서 출발하세요.
• LuaLaTeX 중심이라면 ltjsclasses. OS의 OpenType 글꼴을 그대로 쓸 수 있고 DVI를 거치지 않고 PDF가 나옵니다. nomag*가 기본값이고 용지 치수를 놓칠 일도 없습니다.
• 엔진을 고정하고 싶지 않거나 원고를 배포한다면 BXjscls. 엔진 이름과 ja= 두 곳만 바꾸면 같은 파일이 pdfLaTeX, XeLaTeX, LuaLaTeX, (u)pLaTeX 사이를 오갑니다.
• 판면 치수를 수치로 지정하고 싶다면 jlreq. js 계열과는 다른 계통으로, 자수·행수·여백을 규격에 근거해 설계할 수 있습니다.

로그에서 경로 확인하기

js 계열은 엔진과 클래스가 짝으로 정해지므로 .log 앞부분만 봐도 “의도한 경로로 조판되었는지” 알 수 있습니다. 공동 집필이나 CI에서는 PDF가 나왔다는 사실이 아니라 지정한 경로로 PDF가 나왔다는 사실을 확인하세요. 빌드 명령, \documentclass 줄, README 세 가지가 같은 이름을 가리키는 것이 이상적입니다.