\DocumentMetadata results in incorrect version number of pdfTeX

[stone-zeng]

Brief outline of the bug

When using the \DocumentMetadata command, the producer information in pdf metadata is incorrect: pdftex-1.40.25 becomes pdftex-1.4.25 (with a missing zero).

Minimal example showing the bug

Use pdflatex or pdflatex-dev to compile the following code:

\DocumentMetadata{}
\documentclass{article}
\begin{document}
Hello, world!
\end{document}

Then check the metadata of the generated PDF file with pdfinfo:

Creator:        LaTeX
Producer:       pdftex-1.4.25  <-- should be pdftex-1.40.25
CreationDate:   Wed Mar 15 12:09:07 2023
ModDate:        Wed Mar 15 12:09:07 2023
Tagged:         no
Form:           none
Pages:          1
Encrypted:      no
Page size:      612 x 792 pts (letter) (rotated 0 degrees)
File size:      24069 bytes
Optimized:      no
PDF version:    1.5

Log file (required) and possibly PDF file

1.log
1.pdf

Version info

% pdflatex --version
pdfTeX 3.141592653-2.6-1.40.25 (TeX Live 2023)
kpathsea version 6.3.5
Copyright 2023 Han The Thanh (pdfTeX) et al.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Han The Thanh (pdfTeX) et al.
Compiled with libpng 1.6.39; using libpng 1.6.39
Compiled with zlib 1.2.13; using zlib 1.2.13
Compiled with xpdf version 4.04

[muzimuzhi]

a latex3 issue, what stored in \c_sys_engine_version_str is wrong. Evidence of how it's used by \DocumentMetadata{}.

(assuming this will be transferred to latex3 repo)

Update: For pdftex that str holds the expansion of

latex3/l3kernel/l3candidates.dtx

Lines 1320 to 1325 in 2dd8e7e

	{ pdftex }
	{
	\fp_eval:n { round(\int_use:N \tex_pdftexversion:D / 100 , 2) }
	.
	\tex_pdftexrevision:D
	}

here \fp_eval:n { round(1.4, 2) } is expected to be 1.40, but gives 1.4.

Update 2: It seems \fp_eval:n and other fp evaluators always trim non-significant trailing zeros. How about inserting the dot with macro expansion like

% will fail if pdftex major version number has two or more digits
\exp_last_unbraced:Nno \use_ii_i:nn . { \int_use:N \tex_pdftexversion:D }
.
\tex_pdftexrevision:D

or if one prefers calculations

% relies on the assumption that the miner version is always two digits, 
% which is documented in luatex manual but not in pdftex manual
\int_div_truncate:nn { \tex_pdftexversion:D } { 100 }
.
\int_mod:nn { \tex_pdftexversion:D } { 100 }
.
\tex_pdftexrevision:D

Update 3: luatex has similar problem

latex3/l3kernel/l3candidates.dtx

Lines 1339 to 1344 in 2dd8e7e

	{ luatex }
	{
	\fp_eval:n { round(\int_use:N \tex_luatexversion:D / 100, 2) }
	.
	\tex_luatexrevision:D
	}

[muzimuzhi]

or if one prefers calculations

% relies on the assumption that the miner version is always two digits, 
% which is documented in luatex manual but not in pdftex manual
\int_div_truncate:nn { \tex_pdftexversion:D } { 100 }
.
\int_mod:nn { \tex_pdftexversion:D } { 100 }
.
\tex_pdftexrevision:D

Just realized this second suggestion adds no additional assumption on value of \tex_pdftexversion:D, compared to the current fp way.

[josephwright]

% relies on the assumption that the miner version is always two digits,
% which is documented in luatex manual but not in pdftex manual

The pdfTeX manual says 'Returns the version of pdfTeX multiplied by 100', so I think we are allowed to assume that the lowest two digits are the decimal part.