libpaper 1.2 breaks a TeX Live psutils test

[mbakke]

Hi! Sorry for bothering you about breakage in an unrelated package, but I'm not sure whether this is a regression in libpaper or a flawed test. Is the new libpaper supposed to be 100% compatible with 1.1?

After updating libpaper from 1.1.24 to 1.2.1, the TeX Live psresize test started failing:

./psresize -Pa4 -pa5 playsel.ps \
        | sed -e 's/-0\.000000 /0.000000 /' >playres.ps \
        && diff playres.ps $srcdir/tests/playres.ps \
        && echo "psresize tests OK" \
        || failed="$failed psresize"
+ ./psresize -Pa4 -pa5 playsel.ps
+ sed -e 's/-0\.000000 /0.000000 /'
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] Wrote 11 pages, 16065 bytes
+ diff playres.ps ../../../texlive-20210325-source/texk/psutils/tests/playres.ps
283c283
<  595.275591 0 rlineto 0 844.647797 rlineto -595.275591 0 rlineto
---
>  595.275591 0 rlineto 0 844.647799 rlineto -595.275591 0 rlineto

[...many duplicate lines omitted...]

413c413
<  595.275591 0 rlineto 0 844.647797 rlineto -595.275591 0 rlineto
---
>  595.275591 0 rlineto 0 844.647799 rlineto -595.275591 0 rlineto
+ failed=' psresize'

The playres.ps file can be found here: https://github.com/TeX-Live/texlive-source/blob/trunk/texk/psutils/tests/playres.ps

I don't speak PostScript, but it looks like one Y coordinate is off by 0.000002, which should be insignificant for units smaller than kilometers, but still... Rounding error perhaps? This is on a x86_64 GNU/Linux system (GNU Guix).

Thoughts?

[rrthomas]

Thanks for this report, which is certainly apropos (it helps that I'm the upstream maintainer of psutils too; I'm hoping that version 2 will soon be adopted by TeXLive!).

Yes, the new libpaper is supposed to be 100% compatible with the old.

Having done a lot of testing assuming that TeXLive was using the old psutils 1.17, I see that in fact it's using my version 1.23, which uses paper size information from libpaper! Suddenly, it makes sense that the output would change!

However, TeXLive patches psutils 1.23 to use libpaper differently from the upstream version of psutils (there are tedious but good reasons for this).

If you can edit psresize.c to dump out the contents of spec just before the call to pstops_write, and also to dump out the values of width, height, inwidth and inheight just before the comment try normal orientation first, then we will be able to see the values acquired from libpaper, and the final values computed for the call to pstops_write. (I'm sorry, I can't face building TeXLive right now, and a quick test tells me that I need to build at least kpathsea in order to build the TeXLive version of psutils.)

[mbakke]

Thanks for the feedback and tips. Here are the requested values, printed to 18 decimals(!).

	libpaper 1.1.24	libpaper 1.2.1
width	419.527558999999996558	419.527559055118103970
inwidth	595.275590999999963060	595.275590551181039700
height	595.275590999999963060	595.275590551181039700
inheigth	841.889764000000013766	841.889763779527470433
specs->scale	0.704761904138	0.704761904762
specs->xoff	0.000000	0.000000
specs->yoff	0.971878924558	0.971878515186

The long 999 and 000 segments from libpaper 1.1 are interesting, but I don't know what to make of them... Ideas?

[rrthomas]

Thanks very much for this. I am not really worried about such tiny errors (it just suggests that slightly different operations are being done in each case), and also both libpaper 1.2 and psutils 2 have their own test suites, so these tests will become obsolete.

I would suggest updating the test results for now; when TeXLive adopts psutils 2.x, it will no longer need its own tests.

[mbakke]

Agreed; these miniscule differences seem safe to ignore. Thanks for having a look! :-)