> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/ja/xiang-xi-ji-shi/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md). # LuaTeX入門（第1部）：それは何か—そして何がそんなに違うのか？ LuaTeX は *ツールキット*—そこには、高度なソフトウェアツールやコンポーネントが含まれており、それらを使って幅広い文書を作成（組版）できます。この論文の副題は、LuaTeX について 2 つの問いも投げかけています。すなわち、それは何か—そして何がそんなに違うのか？ 「それは何か？」という問いへの答えは明白に思えるかもしれません。「TeX の組版エンジンです！」確かにそのとおりですが、より広い見方をすると、そして本稿の筆者が支持する見方では、LuaTeX は極めて多用途な TeX ベースの *文書構築・エンジニアリングシステム*. ### LuaTeX を解説する：どこから始めるか？ LuaTeX に関するこの最初の記事の目的は、この TeX エンジンが何を提供し、なぜ／どのようにその設計が、複雑な組版やデザインの問題に対する幅広い解決策をユーザーが構築／設計／作成できるようにしているのか、その文脈を提示することにあります—そして、ユーザーが絶えず変化する技術的エコシステムに適応できる TeX ベースのソフトウェアをますます必要としていることを考えると、ある程度の「将来性」も提供するかもしれません。筆者の見解では、LuaTeX の能力と可能性を理解するうえで、その機能／能力を列挙して説明することが、必ずしも最良の出発点ではありません。そのようなアプローチは、他の TeX エンジンに馴染みがない読者や、機能ベースの比較にあまり意味を見いだせない読者には、特に役立たないでしょう。 読者の忍耐を使い果たしてしまうリスクを承知で（「要点をさっさと言ってくれ！」）、私はより「全体論的」なアプローチを取り、役立つ背景情報を提供できればと思いますが、その代わりに少し余分な読み物が増え、理解を助けるためにいくつかのプログラミング話題にも踏み込みます。では、 [第2部](/latex/ja/xiang-xi-ji-shi/09-an-introduction-to-luatex-part-2-understanding-directlua.md) では、 `\directlua` しかし今のところは、LuaTeX を理解するための基本的な土台を築くことを試みます。 この記事は、LuaTeX を理解し評価するうえでの筆者自身の「旅」を強く反映しています。LuaTeX 開発の背後にある哲学についてまず少し知り、それをソフトウェアツールのコンテナとして見ることで、この驚くべきソフトウェアが切り開く広範な解決領域を、より深く理解できるようになるでしょう。 ## LuaTeX：学術や数学だけのものではない！ LuaTeX に組み込まれている豊富な機能と能力は、従来の LaTeX を通じて非常に高品質な組版を提供するだけでなく、複雑な文書制作やエンジニアリングの問題に対する、独自仕様の非 LaTeX ベースの解決策を開発するための大きな余地も与えます。LuaTeX には強力な Lua スクリプト言語が組み込まれているため、たとえば Lua を使って LuaTeX に「プラグイン」（外部ソフトウェアライブラリ）を読み込むことができます。これにより、さらなる自動化、既存のソフトウェアシステムやワークフローへの統合、データ・テキスト・グラフィックス処理のための専門ソフトウェアの活用が可能になります。 歴史的に、TeX は学術的な執筆／出版、特に数学分野と結びつけられてきましたが、LuaTeX はとりわけ、商業的な PDF 文書制作を含む多くの他の領域で応用できる大きな可能性を持っています。その一例が [speedata publisher](https://speedata.github.io/publisher/) で、これは XML ベースのワークフロー内で PDF 生成エンジンとして LuaTeX だけを使用しており、LaTeX はまったく使っていません。実際、speedata publisher には TeX コードがほとんど含まれておらず、私は [Patrick Gundlach](https://twitter.com/patrickgundlach)speedata publisher の開発者である ## LuaTeX を最初に見つけた経緯 私が LuaTeX の存在を初めて知ったのは 2009 年末から 2010 年初頭にかけてで、まだ中間ベータ版の段階（バージョン 0.50）でした。当時私は、アラビア語の学習に取り組む中で生じた手書きのノートを組版するための TeX ベースのソフトウェアを探していました。Google 検索で、TUG 2009 カンファレンスの動画集（[現在は YouTube で](https://www.youtube.com/playlist?list=PL2D4DD50DC9C0BA0E)）が見つかり、そこには非常に高品質なアラビア語組版のデモ（Hans Hagen の [ConTeXt パッケージ](http://wiki.contextgarden.net/Main_Page)を通じて）が含まれていました。これらの動画にはまた、 [LuaTeX プロジェクト：バージョン 1 への半ば](https://youtu.be/AKv4po9PGW0). その精緻なアラビア語組版を生成していた TeX エンジンは「LuaTeX」と呼ばれるものでした。当時私は科学（物理）出版の仕事をしており、TeX/LaTeX には十分に精通していたものの、LuaTeX という名前は聞いたことがありませんでした。私は興味をそそられ、この新しい TeX エンジンについてもっと知りたくなりました。LuaTeX はまだベータ開発段階にあり、急速に開発が進んでいたため、最新の更新に常に追随したいと思っていました。そのため、最良の選択肢（私にとって）は、LuaTeX の実行ファイルをソースコードから自分でビルド（コンパイル）することでした。実行可能な LuaTeX プログラムに加えて、LuaTeX を実行する環境を提供するための「TeX インストール」（たとえば texmf.cnf、マクロパッケージ、フォントなど）も必要です。巨大な [TeX Live](https://www.tug.org/texlive/) 配布版をダウンロードしてインストールする代わりに、LuaTeX を試すための、まったく最小限のカスタム TeX インストールを作成することにしました（これは「興味深い」作業で、私は [自分の個人ブログに記録しました](http://www.readytext.co.uk/?cat=30)）。LuaTeX の新しいリリースには、それに対応するリファレンスマニュアル（たとえば[バージョン 1.0.4](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co)）が付属し、ソフトウェアの最新機能や機能性が文書化されています。しかし、それは *リファレンス* マニュアルであり、この驚くべき TeX エンジンを使い始めたい初心者向けの説明は（必然的に）かなり少なめです。低レベルの TeX 概念についてある程度の知識があることが前提とされています。私は LuaTeX をその開発の比較的早い段階で知ったので、当時は良い入門資料を見つけるのが比較的難しく、いろいろと調べ、試行錯誤し（そして少々フラストレーションも感じつつ…）、やっと全体像がつながり始めました。言うまでもなく、私はこの素晴らしいソフトウェアに魅了され、アラビア語学習は急停止し、やがてアラビア語組版のための LuaTeX [プラグイン](http://www.readytext.co.uk/?p=3143) の執筆へと移っていきました！ 私自身の「LuaTeX の旅」は確かにかなり非直線的でしたが、その過程で（Lua）TeX（および TeX インストール）を「ゼロから」学ぶ機会にも恵まれました。私のブログには、その期間に探究し取り組んださまざまな話題に基づく、折衷的な記事群が掲載されています。願わくば、本記事がその時間と経験を適切に活用し、LuaTeX の機能を探究し始めるきっかけとして他の人の興味を引ければと思います。LuaTeX は今も開発が続いており、執筆時点では TeX Live 2017 とともにリリースされたバージョン 1.0.4 に達しています。開発者たちは非常に सक्रियで、見つかったバグは通常、報告後まもなく修正されます—たとえば、 [記事](http://www.readytext.co.uk/?cat=3) dev-luatex メーリングリスト [や](https://mailman.ntg.nl/mailman/listinfo/dev-luatex) オンライン LuaTeX バグトラッカー [を通じてです。 ](http://tracker.luatex.org/my_view_page.php)LuaTeX は 1.0 に到達するずっと前から実運用可能でした—もちろん、機能が継続的に進化しており、時には変更によって既存の TeX コードが壊れる可能性があることを受け入れる必要はありましたが。現在ではもちろん、LuaTeX は Overleaf および ShareLaTeX プラットフォームによって（LuaLaTeX として）サポートされています。 ## 変化する世界の中の TeX：新技術とワークフロー 明らかに、TeX エンジンは技術的に静的な世界の中で動作しているわけではなく、時折、TeX エンジンに即座に、しかも明白に取り込むべき革新が現れます—その一例が、後ほど簡単に触れる OpenType 可変フォントです。TeX ベースの組版ソフトウェアが非常に多用途であることに疑いはほとんどありませんが、TeX エンジンはいまや、急速に変化し、非常に多様なソフトウェア・エコシステムの中で動作しています。新しいワークフローは、統合の必要性と、TeX がその一部にすぎないかもしれない幅広い文書／組版ソリューションを実装する柔軟性を強調しています。 TeX は、現在のユーザーにとっての関連性を保つだけでなく、次世代にとっても有用であり続けるコンテンツ作成ソリューションを可能にすることで、新しい利用者も引きつけなければなりません—つまり、TeX を単独のツールとしてではなく、Overleaf のようなオンライン共同作業プラットフォームを通じた全体的なワークフローの一部として使いたい人たちです。 を少し眺めるだけでも [質問で](https://tex.stackexchange.com/) 、TeX ベースのソフトウェアで作成・実装されている文書やソリューションの圧倒的な多様性がわかります—人々が生成したいと考える用途やコンテンツ種別がますます増える中で、驚くべき創意工夫がしばしば見られます。さらに、TeX ベースのマークアップ／コンテンツを処理して PDF 以外（および DVI 以外）の出力を生成できるワークフローの必要性は、かつてないほど高まっています—たとえば MathML/XML や HTML です。たとえば、TeX を [JATS XML](https://jats.nlm.nih.gov/) 形式へ「変換」することは（長く学術雑誌出版で使われてきましたが）、近年では電子書籍出版で使われる epub の台頭もあります。 ### 可変フォント技術――時代は変わる 2016 年 9 月 14 日、Microsoft、 [Google](https://opensource.googleblog.com/2016/09/introducing-opentype-font-variations.html), [Adobe](https://blog.typekit.com/2016/09/14/variable-fonts-a-new-kind-of-font-for-flexible-design/) そして Apple は新しいフォント技術を発表しました： [OpenType 可変フォント](https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369)。ここではこの技術を詳しくは扱いませんが、Thomas Phinney や [Thomas Phinney](https://twitter.com/ThomasPhinney) や [John Hudson](https://twitter.com/TiroTypeworks) は（[Twitter で](https://twitter.com/ThomasPhinney/status/917087509342851072)）可変フォント技術は以前の多くのフォント革新よりもはるかに速く採用されていると指摘しています—これはおそらく、モバイル端末に存在する無数の画面サイズ／解像度に適応するレスポンシブデザインを必要とする Web デザイナーのニーズに後押しされているのでしょう。 明らかに、OpenType 可変フォントはフォント技術における興味深く刺激的な進展であり、TeX ユーザーはそこから確かに恩恵を受けられるはずです—実際、この問いは必然的に [tex.stackexchange で提起され](https://tex.stackexchange.com/questions/355104/tex-luatex-xetex-fontspec-support-for-opentype-variable-fonts) LuaTeX によるサポートは LuaTeX [メーリングリストで議論されています](https://www.tug.org/pipermail/luatex/2016-September/006204.html). ちなみに、「パラメトリック」なフォント作成に基づくフォント技術は、まったく新しい発想ではないことも指摘しておく価値があります。Knuth の METAFONT や Adobe の Multiple Master 技術は、実装の詳細はかなり異なるものの、ある意味では初期の先駆けです。 ### 可変フォント：いつ欲しいのか—今でしょ？ 新しく有用な技術標準／仕様は、開発者や実装者からなる対象エコシステムに「定着」するための時間が必要です—仕様そのものに含まれる曖昧さや文言解釈を整理する時間も含みます。開発者は文書を読み、理解し、それを実際に動くソフトウェアへと落とし込まなければなりません。ここには、フォントと、それを使うための技術—互換ブラウザや組版エンジン—の作成も含まれます。TeX 開発者は、可変フォント技術のサポートを実装（プログラミング）する際の信頼できる「ベンチマーク」として使える、高品質な可変フォントにアクセスできる必要が明らかにあります。 TeX に可変フォントのような新技術を実装することは、 *可能性としての* TeX エンジン内部の修正を必要とすることを示唆します—もちろん、それが必要かどうかは、その技術の性質、そして特に TeX のどの挙動が変更対象になっているかに依存します。TeX エンジン自体の修正が常に必要とは限らず、補助的／周辺的なソフトウェア、さらにはそれらのプログラム内で使われている「コンポーネント」（サードパーティ製コードライブラリ）の変更だけで済む場合もあります。内部的に、TeX エンジンは *ひどく* 複雑です—信頼できる修正を行うのに十分な TeX ソースコード理解を得るには、相当な、しかも高度に専門的な知識が必要であり、そのような専門家は非常に限られています。また、いかなる修正も TeX エンジンの長期的な安定性／互換性を損なわないことが不可欠です。これは TeX コミュニティにとって、そして作者の（La）TeX ファイルを後で処理する人々、特に学術出版社や Overleaf、ShareLaTeX のようなクラウドベースのサービスにとって極めて重要です。 多くの TeX ユーザーは可変フォントを活用したいと考えているでしょう。たとえば、新しいデザインの可能性を実現したり、厄介な組版問題の解決策を見つけたりするためです。ある意味では、ここには難問があります。つまり、新技術へのアクセスを望む TeX ユーザーは多いものの、その実装は非常に限られた資源、すなわちそれを実現できる資格と能力を持つ開発者の数に依存しているのです。TeX の内部を修正するのは難しく、一般には可能な限り避けるのが最善ですが、TeX に新機能／能力の（ある種のクラスを）追加する別の方法はあるのでしょうか？ あります！ そして LuaTeX はその道を選びました。 #### 初期の実験：OpenType 可変フォントと LuaTeX LuaTeX の設計により、可変フォント技術の迅速な実験が可能になりました。すでに 2017 年 4 月の時点で、LuaTeX を使用する ConTeXt TeX フォーマットには、 [ベータ版](https://mailman.ntg.nl/pipermail/ntg-context/2017/088343.html) OpenType 可変フォントを実装したものがありました。これは、ConTeXt のフォントサポートが Lua コードで構築されており（ConTeXt には Lua で書かれた独自の fontloader があります）、それによって可能になったのです。 ## LuaTeX：背景と歴史 LuaTeX は、TeX の文脈では 10 年以上活発に開発されてきたにもかかわらず、「新参者」です。LuaTeX の Web サイトは [記載しており](http://www.luatex.org/roadmap.html) 、LuaTeX は 2005 年に始まり、私の理解では 2006 年に活発で継続的な開発が始まりました。その本質的な複雑さと、これを構築した人々の尽力のおかげで、LuaTeX がバージョン 1.0 に到達するまでには本当に 10 年かかりました。それは [その開発者たちによって発表され](https://mailman.ntg.nl/pipermail/dev-luatex/2016-September/005882.html) （Hans Hagen、Hartmut Henkel、Taco Hoekwater、Luigi Scarso）2016 年 9 月 27 日に公表されました。 そのリリース発表には、重要な原則の表明が含まれています： > 「私たちの主目的は、内部の動作を適応させる必要なく、ユーザー拡張を可能にする TeX の変種を提供することです。」 この文言は LuaTeX 開発の背後にある哲学を完璧に要約しており、TeX ベースのソフトウェアが、すでに触れた課題—新技術の採用と新しい世代のユーザーにとっての関連性維持—に対処するための道筋を示しています。 ここで、本記事の副題に含まれる 2 つ目の問い「何がそんなに違うのか」に取り組む時が来ました。「...内部の動作を適応させる必要なく、ユーザー拡張を可能にする」という意味を探ることで、LuaTeX が「提供しているもの」の本質をよりよく理解できます。 ## LuaTeX：TeX の「ブラックボックス」を開く Knuth が最初に書いた TeX プログラムは、現在使われているすべての近代的 TeX エンジンの共通祖先であり、LuaTeX は事実上その最新の進化段階です。pdfTeX プログラムを基にしつつ、多くの追加機能をもたらす強力なソフトウェアコンポーネントが加わっています。Knuth が TeX ソフトウェアのオリジナル版を書いたとき、彼はその組版動作を制御しプログラムする方法として TeX 言語も提供しました。およそ 320 個の低レベル命令（プリミティブ）が、TeX マクロパッケージのユーザーや開発者に公開されました。これらの命令は、TeX の組版動作の特定の側面に対してさまざまな程度の制御や影響を与えられましたが、TeX の内部機能、アルゴリズム、意思決定過程、データやデータ構造の多くはユーザーから隠されていました。言うなれば、Knuth の TeX プログラムは完全な「ブラックボックス」ではありませんでしたが、確かにかなり濃い灰色でした—たしかにソースコードは公開されていましたが、ほとんどの人にとって、それもまた理解不能なブラックボックスです。 TeX の内部プロセスは、ある意味で「ブラックボックス」だと私たちは言います。しかし LuaTeX は、TeX ベースの内部構造を開放し、ユーザー／開発者が TeX エンジンの奥深くで起きている、かつては隠されていた多くの処理に、より広くアクセスし、制御できるようにします。LuaTeX はまた、新機能を制御する多くの新しいプリミティブ命令も追加します。 ### LuaTeX：pdfTeX を起点としているが pdfTeX のコードは使用しない 正確を期すために述べると、LuaTeX を pdfTeX 由来と説明しましたが、LuaTeX は pdfTeX の元のプログラムコードを直接使っているわけではありません。LuaTeX の開発者の一人（Taco Hoekwater）は、実に *ヘラクレスのように途方もない* 作業として、LuaTeX のコア TeX エンジンを、クリーンで आधुनिकな C コード（CWEB）で書き直しました。 #### 歴史的注記 Knuth の元の TeX ソースコードはかなり古く、そこから現代の後継が派生しているため、それを修正して新しい TeX ベースの組版エンジンを適応させたり作成したりするのは、複雑で入り組んだプロセスです。その過程の一部には、Pascal コードを C コードへ変換する作業が含まれますが、それにも [ある程度の複雑さ](http://www.readytext.co.uk/?p=2529)があります。結果として生成される機械生成の C コードは非常に冗長で、読むのも理解するのも極めて困難です。明らかに、LuaTeX のコードを完全に書き直すことで、Pascal から C への変換プロセス全体を回避できます。 ## LuaTeX の構成ブロック 序文では、LuaTeX を「ツールキット」と呼び、「文書構築・エンジニアリングシステム」と説明しました。LuaTeX 1.0 の発表で開発者が次のように述べていることも見てきました： > 「私たちの主目的は、内部の動作を適応させる必要なく、ユーザー拡張を可能にする TeX の変種を提供することです。」 ここで、これらの流れをまとめ直し、これが *実際に何を意味するのか* 実際に ### LuaTeX のジグソーパズル 「内部」を覗いてみると、実行可能な LuaTeX ソフトウェアは、LuaTeX の全体機能を提供するために組み合わされた一連のソフトウェアコンポーネントから構成されていることがわかるでしょう。もちろん、これは新しいことではなく、ほとんどのソフトウェアはそのように構成されています。しかし LuaTeX が他の TeX エンジンと異なるのは、これらのコンポーネントが、ユーザーが TeX の内部機能の多くの側面—組版アルゴリズム、意思決定過程、データやデータ構造—に、より広くアクセスできるような仕方で組み合わされている点です。TeX の内部を開放することで、ユーザーは実際の TeX エンジン自体を修正することなく、新しい組版ソリューションを構築できるようになります。 ### LuaTeX の Lua：『ブラックボックス』への鍵 Lua は非常に強力でありながら習得しやすいスクリプト言語で、 [ブラジル発祥です](https://www.lua.org/about.html)—1993 年に作成され、現在も活発に開発されています。Lua の強みの一つは、異種のソフトウェアコンポーネントを「接着」するためのプログラミング言語として使えることです。これにより、シンプルでありながら多用途なスクリプト言語を通じて、それらを利用できます。Lua は LuaTeX TeX エンジンの内部動作を開放するうえで中心的な役割を果たしますが、その仕組みをよりよく理解するために、少し寄り道して 2 つのプログラミング概念を簡単に説明しておく価値があります： * アプリケーション・プログラミング・インターフェース（API）； * プログラミング言語バインディング。 これらの概念に慣れているなら、この節は飛ばしていただいて構いません。どちらの話題も詳しくは扱いません—厳密な技術的厳格さを目指すのではなく、これらの概念、その意味と LuaTeX との関連性を認識するのに十分な背景だけを提供することが目的です。 ### アプリケーション・プログラミング・インターフェース（API） あなたがプログラマーで、他の利用者（別のプログラマー）にとって役立つかもしれないコードを書いたと想像してください。しかし、そのコードは複雑で、利用者にそんな低レベルの詳細を気にしてほしくないとします。なお、それらのプログラマー／開発者は、あなたがそのコードを書くのに使ったのと同じプログラミング言語を使っています。さらに、コードの一部を書き直す計画があるとしましょう—たとえば、より速くしたり、より少ないメモリで済むようにしたりするためです。既存の利用者はそれについて心配する必要がありません。あなたが行う変更は、彼らのプログラムを壊すものであってはならないからです。では、解決策は何でしょうか？ 答えは API と呼ばれるものにあります。すなわち、 *アプリケーション・プログラミング・インターフェース*。利用者（別のプログラマー）に、変更される可能性のあるあなたのコードの低レベル詳細へアクセスさせる代わりに、あなたは *関数* の特定のセットを提供します。それらの関数はあなたのコードへの *インターフェース* であり、他の開発者はそこを通じて *アプリケーション* を、あなたのプログラムの内部動作を深く知らなくても構築できます。ある意味では、これはあなたのコードを取り囲み、利用者を煩雑な低レベルの詳細から「隔離」する追加レイヤーだと考えられます。 それらの関数（インターフェース）を変更しない限り、ソフトウェアの低レベルな詳細を自由に修正・更新でき、あなたのコードを使ってアプリケーションを構築している人たちの作業に影響（破壊）を与えずに済みます。そこから Application Programming Interface という用語が来ています。 #### API：LaTeX パッケージとの類推 LaTeX パッケージが提供するコマンドを使うとき、そのパッケージのコマンドは API の一形態だと考えることができます。利用者としては、それらのコマンドの背後にある TeX や LaTeX の魔法（つまりパッケージのコード）を必ずしも気にする必要はなく、ただそれらが提供する機能を使えればよいのです。 ### プログラミング言語バインディング 私たちは、便利なコード群（ *ライブラリ*と呼ばれる）を作成・公開するプログラマーが、いわゆるアプリケーション・プログラミング・インターフェース（関数群）を提供できることを見てきました。それを通じて、 *同じ* プログラミング言語を使う他のプログラマーがそのライブラリ（コードの集合）を利用できます。双方（ライブラリ開発者とその利用者）が *同じ* プログラミング言語 *別の* プログラミング言語のプログラマーもそのライブラリを使いたい場合はどうなるでしょうか？ たとえば、Lua 言語でスクリプトを書いているが、C/C++ のようなプログラミング言語で書かれたライブラリを使いたいとします。どうにかして、2 つの異なるプログラミング言語（Lua と C/C++）が互いに「通信」できる必要があります。この問題に対する 1 つの解決策が、いわゆる [言語バインディング](https://en.wikipedia.org/wiki/Language_binding). 言語バインディングの技術的詳細を検討するのは本記事の範囲外なので、一般原則を簡潔にまとめます。本質的には、元のライブラリに適切な追加の「層」のコードを加えることで、Lua のような別のプログラミング言語と「通信」できるようになります。そのコード層は *バインディング*と呼ばれます。これにより、API を介して 2 つの言語が相互運用できるようになり、2 番目の言語（たとえば Lua）のプログラマーは、そのライブラリが提供する機能／サービスにアクセスできます。 ![言語バインディングの概念を示す模式図。](/files/7ecdc128b1f7521820526af145f106be790d6a7c) **図 1**：Lua で書かれたプログラムが別のプログラミング言語で書かれた外部ライブラリを使えるようにする、言語バインディングの概念を示す模式図。Lua バインディングを用いることで、LuaTeX の内部コンポーネント、ひいては LuaTeX の内部組版機能の多くが、ユーザーが複雑な組版問題に対する解決策を開発するために利用可能になります。 ## LuaTeX：プログラミングの 2 つの選択肢—TeX と Lua 要するに、LuaTeX は 2 つのプログラミング言語—従来の TeX ベースの言語と Lua スクリプト言語—をサポートする TeX エンジンです。もちろん、同じ TeX 文書内で両方の言語を使ってもよいですし、望むなら TeX のみの経路で組版を続けても構いません。たとえば、LaTeX（LuaLaTeX）マクロパッケージを通じてです。TeX（あるいは LaTeX）は、使うのも学ぶのも容易なプログラミング言語ではなく、TeX の数多くの癖を本当に習得している人は比較的少数です。TeX の [トークン](https://www.overleaf.com/blog/522-what-is-a-tex-token) と展開 という概念は、ほとんどの人が抱くプログラミング言語への期待や経験とはかなり異質です。Lua を追加することで、TeX ベースの組版を、はるかに親しみやすく一般的なプログラミング言語で利用できるようになります—本記事の冒頭でも触れたように、Lua API を使えば [ほとんど TeX コードなしで高度な組版](http://wiki.luatex.org/index.php/TeX_without_TeX). ### LuaTeX は多くの新しいプリミティブを追加します すべての TeX エンジンは、いわゆるプリミティブ命令を何百も提供しています。これは、各組版エンジンがサポートする TeX ベース言語の基礎的な構成要素です。Donald Knuth が公開した元の TeX 版では約 320 個の命令が提供されていましたが、新しい TeX エンジン（pdfTeX、XeTeX、LuaTeX）は、それぞれユーザーに各エンジンの追加機能や機能性へアクセスさせるため、多くの新しいプリミティブを追加しています。LuaTeX が追加した多数の新しいプリミティブは、その [リファレンスマニュアル](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co). LuaTeX によって導入された多くの新しいプリミティブの中には、かつて `\directlua{...}` があり、これは Lua コードを使うための入り口です。LuaTeX エンジンの内部にアクセスし、高度な組版ツールやソリューションを構築できます。 ### \directlua{...}：Lua プログラミングへの入り口 すでに述べたように、Lua スクリプト言語は、LuaTeX の TeX ベースの組版エンジンや、LuaTeX を構成する多くのコンポーネントが提供する機能へアクセスするための「層」を提供するものと考えられます。Lua 言語はまた、LuaTeX の拡張性を可能にする仕組みでもあります。Lua には、専門的な外部ライブラリのソフトウェア／コードを読み込む能力があるからです。 LuaTeX が提供する Lua インターフェース（Lua ベースの関数群）は、総称してその *Lua API*と呼ばれます：これは LuaTeX の内部エンジン／コンポーネントとユーザーの文書をつなぐ「通信リンク」です。 ### \directlua{...} の簡単な例 以下の *極めて単純な* 例ですが、可能性の氷山の一角にすら触れていません。しかし、TeX のパラメータにアクセスする「TeX 的な方法」と「Lua 的な方法」の相互作用の基本的な考え方を示すには役立ちます。 注意： * `\hsize` これは、組版行の幅を決める内部パラメータの値を設定する TeX のプリミティブ（コマンド）です。たとえば、通常は適切な値を `\vbox{...}`. `\hsize` は、そのうちの *多数の* TeX パラメータの 1 つにすぎず、Lua コードでアクセスおよび／または変更できます。 * TeX パラメータへのアクセスは、LuaTeX の Lua API のほんの *わずかな* 一面にすぎません。ほかにもたくさんあります！ ```latex \documentclass{article} \begin{document} \let\\\relax % 展開の問題を避けるために \\ の意味を再定義 ここに {\ttfamily\string\hsize} の現在値があります（\LaTeX 経由で）： \the\hsize\par \directlua{ % Lua API を使って \hsize の現在値を取得する local hs=tex.hsize % Lua API 関数を使って % LaTeX コードと \hsize の値を出力する tex.print("Lua コードから報告された {\\ttfamily\\string\\hsize} の値は （スケールドポイントで）：") tex.print(hs.."\\par") % Lua API を使って \hsize の新しい値を設定する tex.hsize="400pt" % または tex.hsize=400*65536（スケールドポイントで）を使う }% % \directlua が終了したら、LaTeX に % \hsize の新しい値を知らせてもらう ここに {\ttfamily\string\hsize} の値があります \LaTeX{} によって報告された、{\tt\string\directlua} が終了した後の値： \the\hsize\par \end{document} ``` 以下は、LuaTeX によって LaTeX コード（上記）が組版された結果を示す画像です： ![LuaTeX の実行結果](/files/9002e5ab7aab866e97258d14f9536f40ba594df0) TeX 的な「ごまかし」である `\let\\\relax` は、LuaTeX による Lua コードの「展開」で生じる問題を避けるためのものです。その点については、後ほど簡単に触れます。 ### Lua コードの使用 TeX／LaTeX 文書で Lua コードを使う主な方法は 2 つあります： 1. **インライン**：Lua コードを直接あなたの `.tex` 文書内に記述する（上の例のように）； 2. **外部**：Lua コードを外部の `.lua` コードファイルに保存し、Lua の機能を使ってそれらを読み込み実行する。 方法 (1) は、短い Lua コード片に最も適しています。方法 (2) は、より大きなプログラムや Lua コードのライブラリに使われます。TeX のいわゆる `\catcode` 値 `\catcode` に関する厄介な問題（これは「かなりイライラする」ことがあります）を避けられる、という明確な利点があります。こうした問題の原因は、LuaTeX 内蔵の Lua インタプリタに渡される前に Lua コードが「展開」されることにあります。この展開は理解が難しい場合があるので、次の記事でさらに掘り下げます。 もちろん、.tex ファイルで Lua コードを使うのを助ける LaTeX パッケージもあります—たとえば、 [luacode パッケージ](https://ctan.org/pkg/luacode?lang=en). ## 要約と本稿第 2 部の紹介 LuaTeX を構成するソフトウェアコンポーネント群と、組み込まれた Lua スクリプト言語は、幅広い複雑な組版の問題を解決できるソリューションを構築し、TeX ベースの組版エンジンとの緊密な統合の恩恵を受けられる文書制作ワークフローを設計するための強力な組み合わせを提供します。では [この記事の第2部](/latex/ja/xiang-xi-ji-shi/09-an-introduction-to-luatex-part-2-understanding-directlua.md) LuaTeX が提供する最も強力なコマンドを詳しく見ていきます: `\directlua`. それでは、その時まで LuaTeX を楽しんでください！ ## 謝辞 著者は、次の方々に深く感謝しています [Luigi Scarso](https://twitter.com/luigi_scarso)、LuaTeX の開発者の一人である彼が、この論文の草稿を読んでくださり、非常に役立つ多くのコメントや提案をしてくださったことに、時間を割いていただいたことに深く感謝します。事実関係の誤りや記載漏れが残っているとすれば、もちろんそれは著者の責任です。さらに、次の方にも感謝したいと思います [Patrick Gundlach](https://twitter.com/patrickgundlach)、の開発者 [speedata publisher](https://speedata.github.io/publisher/)、私の質問に答えるために時間を割いてくださったことに感謝します。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/ja/xiang-xi-ji-shi/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.