-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
テストケース作り #35
Comments
ライセンスは調べないといけないかもしれませんが,ptexlive の配布の中に,テストケース(文字が出るかといった単純なものも含む)があります. LaTeX出力のテストケースで課題があるとすると,何が出力として正しいか(expected)をどう持てば普遍的か,どうやって actual と expected が等しいと自動で判断するか,というところが難しいのが悩みです. |
情報ありがとうございます。試しに ptexlive-20110322 を採ってきてみると macro/sample.tex というのがありました。これはアスキーの pLaTeX 2.09 付属のサンプル (\documentstyle) を pLaTeX2e 向け (\documentclass) にいじったものでした。pLaTeX 2.09 の配布条件は
なので(アスキー公式アーカイブの platex209 付属の README.txt より)、改変しなければ再配布可能です。ptexlive は変更してしまっているため、厳密な意味ではライセンスを守っていなかったことになります…が、しょうがない気もします。ptexlive の sample.tex を頂いてよければ、これはぜひ使いたいです。
互換性を重視して「不変かどうか」を基準にすると話は簡単で、pdvitype を使って DVI の同一性をチェックすることを考えていました。これは TRIP test も同じ方法に基づいているため自然だと思います。pdvitype の出力を比較して diff すればよいはずです。もちろん #32 のように組版結果を変える変更を含むときだけ、pdvitype ではなく“見た目”に頼る必要がありますが。 また、pdvitype だと DVI 出力しか比較できないため、LaTeX2e が採用している「ログレベルでの比較」(regression test) も必要だと思います。LaTeX2e svn に本家のテストケースが多数あるので、これを移植することを考えています。 |
そういえば,ptexlive のテストケースは,「TeX環境」を提供する側として,正しくコンパイルできたかのほうに主眼が置かれていたかもしれませんね.Makefile を読むと,何をテストケースにしていたかわかりますが,jsclasses.dtx や utf/otf パッケージ関係の適当なファイルもタイプセットしていました. |
これ2017年と今では少し状況が変わってきているかもしれませんね.一回 CI 追加の提案 (#34) があったのを当時は見送ったようですが,今また GitHub Actions などで設定する方向を議論するための issue を新たに建てるのはどうでしょうか. 関連して,この issue で募集したいテストケースは原則としては そういった用途では最近 texjporg が整備しているドキュメント類(例えば ptex-manual)がそのまま使えそうですね.また私が翻訳した日本語版『TeX Live ガイド』もそれなりに分量がある上,図の読み込みなどもしているのでいいテストケースかもしれません(というか私は新しい pLaTeX が出ると手許ではこの文書を使って簡単にテストしています). これらの外部ドキュメントは |
確かに,そうだと思います。議論は新しい issue を立てなくとも,ここで継続して良いのではないでしょうか(標題と目的は一致していますので)。ちなみに,GitHub の管理者権限がないと Actions も CI も設定できないので,その作業は私以外の誰かが作業する必要があります…(私はメンバー権限なので不可)。 肝心のテストケースについては,「platex/tests の小さいファイル」+「外部のドキュメントソースを git submodule で取ってくる」のほか,以下も作っていましたので,備忘録として: テスト対象として「タイプセット成否」(エラーが出ないかどうか)は,必要ではありますが十分ではないので,ログもしくは DVI の比較も必要だと思います。ただ,遅々として進まない原因が下記にあります:
|
LaTeX ファイルを platex-dev でコンパイルして、dvipdfmx で PDF に変換したものを、さらに ImageMagick で PNG ファイルに変換したものと、想定されている PDF ファイルを PNG ファイルに変換したものを比較してテストするサンプルを作ってみました。Web開発で使用されている、reg-cli というブラウザのスクリーンショット同士を比較するソフトを使っています。画像同士が異なる場合、異なっている場所をわかりやすく表示してくれます。 以下を git clone する。 以下を docker pull する。
そうすると お役に立てば幸いです。 |
@tamuratak ありがとうございます。PNGを重ねた比較という方法は非常に役に立つと思います。ひとつ伺いたいのですが,docker で走る platex-dev のソースコードを更新することは可能でしょうか? 私が docker の作り方を知らないので…。 理由は以下のとおり:「GitHub に置いてある開発版」と「普通に配布されている TeX Live に収録されている -dev 版」では,そのソースコードに時間差が生じます。単にコマンド名を platex-dev に変えるだけではなく,本 GitHub にあるソースコードを pull してから fmtutil-sys を走らせてフォーマット更新したうえでテストが走る仕組みだと,最新開発版のテストに使えるようになります。(もし難しいようでしたら,教えていただいた方法を元に reg-cli をローカルに入れておいて走らせるという活用が考えられます) |
開発に必要なパッケージ(make や gcc)を更に追加で Docker のイメージにインストールした上で、Docker コンテナ内で platex のソースコードをビルドして、Docker コンテナ内の TeX Live に対してインストール( 開発版の platex をビルドして、すでにインストールされている TeX Live のファイルに上書きする方法( |
|
現在の TeX Live 2020 最新版(本日朝に frozen すなわち凍結されました)において一般配布されている「LaTeX2e の開発版 + pLaTeX2e」であれば,以下の表示になるはずです。
となるはずです。この状態でこちらの投稿にあるソースコードを platex-dev で処理するとエラーが出るはずです。一方,本 GitHub で配布している pLaTeX2e の開発版 master をインストールしてフォーマット作成 (fmtutil-sys --byfmt platex-dev) すればエラーが消えると思います。現在の確認方法としてはそれが良いと思います。 |
以下のような Dockerfile で上記の LaTeX ファイルをコンパイルすることができました。
上の例では GitHub から pull していますが、現在作業中のローカルのファイルから同様の Docker のイメージを作るには、
を実行します。 |
おぉ,これはよいです。最近少々忙しくて開発環境にいないのですが,後日時間ができたときに触ってみます。大変ありがとうございます。 あとは,コーナーケースを突いたテスト用 LaTeX ファイルを色々と準備することも力を入れないといけないですね。確認が目視より自動化されるだけでありがたいですね。 |
forum:2139 で流したところ、さっそく私個人宛に 2 つ送られてきました。後ほどアップしますが、GitHub の皆様も何か使えそうな .tex ファイルがありましたら送ってください。或いは、テストケースに使えそうな(=改変と再配布が許諾された)適当な tex ファイルをご存知ならば、お知らせください。
The text was updated successfully, but these errors were encountered: