dvipaste - creating dvipaste-binary for debian buster / grfpaste - problems with new dvips.def and l3backend-dvips.def

[Ulrich-Diez]

Hello,

yesterday I bothered you in TeX LaTeX StackExchange with my attempts of compiling the program dvipaste for debian buster.

I have an i386-vanilla TeX-Live-installation:

• LaTeX2e <2020-10-01> patch level 4
• L3 programming layer <2021-01-09>
• xparse <2020-03-03>
• dvips.def 2017/06/20 v3.1d

---

I now managed to get a binary which, apart from one problem, seems to work on debian buster:

• The test-suite provided in the dvipaste-package, where dvi-files are created via plain TeX, works.

• But with my vanilla TeX-Live-installation the test-suite provided by the package grfpaste, where dvi-files are created via LaTeX, works out only if the .dvi-files that are to be pasted are created while the following two conditions are met:

  1. An older dvips.def is in use. (I tested with dvips.def 2014/04/23 v3.0j which I copied from my old Win95-MiKTeX2.4-installation to the directory where grfp1.tex, gefp2.tex and grfp3.tex are stored.)
  2. l3backend-dvips.def is "neutralized" by placing an empty file l3backend-dvips.def into the directory where the files to compile are placed.

  Seems these conditions need to be met for the .dvi-files that are to be pasted but don't need to be met for the .dvi-file where stuff is to be pasted to.

As long as I just compile grfp1.tex and grfp2.tex on my up-to-date vanilla TeX Live installation in the more recent debian-buster platform with recent dvips.def and with l3backend-dvips.def not "neutralized", i.e., without obeying these conditions, and then apply my dvipaste-binary for debian-buster, within the resulting .dvi-file those copied portions do not show up that stem from the first \sendout/from the first page of a .dvi-file whose content is to be copied.

By the way:

When I compile grfp1.tex and grfp2.tex and grfp3.tex on my old Win95-MiKTeX2.4-installation and do not apply the DOS-binary (DVIPASTE.EXE) shipped along with the dvipaste-package but move the resulting .dvi-files to my more recent debian buster-platform and apply the dvipaste-binary created for the more recent debian-buster-platform, then everything works out also.

For control:

Vice versa: When I compile grfp1.tex and grfp2.tex and grfp3.tex on my up-to-date vanilla TeX Live installation in the more recent debian-buster platform (with recent dvips.def and with l3backend-dvips.def not "neutralized") and do not apply the dvipaste-binary created for the more-recent debian-buster-platform, but move the resulting .dvi-files to my old Win95-MiKTeX2.4-installation and apply the DOS-binary (DVIPASTE.EXE) shipped along with the dvipaste-package, then things don't work out on the old platform.

When I compile grfp1.tex and grfp2.tex and grfp3.tex on my old Win95-MiKTeX2.4-installation and on that old platform do apply the DOS-binary (DVIPASTE.EXE) shipped along with the dvipaste-package, then everything works out.

In short:

( ⟨.dvi-files compiled with LaTeX on platform⟩ ) AND ( ⟨dvipaste-binary of platform⟩ ) → ⟨result⟩.

(.dvi-files compiled with LaTeX - TeX Live 2020/debian buster) AND (dvipaste-binary of TeX Live 2020/debian buster) → things don't work out.

(.dvi-files compiled with LaTeX - TeX Live 2020/debian buster) AND (dvipaste-binary of Win95/MiKTeX 2.4) → things don't work out.

(.dvi-files compiled with LaTeX on Win95/MiKTeX 2.4) AND (dvipaste-binary of Win95/MiKTeX 2.4) → things do work out.

(.dvi-files compiled with LaTeX on Win95/MiKTeX 2.4) AND (dvipaste-binary of TeX Live 2020/debian buster) → things do work out.

(.dvi-files compiled with LaTeX - TeX Live 2020/debian buster with old dvips.def and with l3backend-dvips.def neutralized) AND (dvipaste-binary of TeX Live 2020/debian buster) → things do work out.

(.dvi-fFiles compiled with LaTeX - TeX Live 2020/debian buster with old dvips.def and with l3backend-dvips.def neutralized) AND (dvipaste-binary of Win95/MiKTeX 2.4) → things do work out.

---

In order to obtain that binary I compiled via sudo make all after doing the following changes:

In dvipaste.c I removed the lines:

1247  #ifndef MICROSOFTC
1248  #define strnicmp strncmp
1249  #define strcmp strcmp
1250  #endif

Reason:

1248 #define strnicmp strncmp

This is for handling the situation of using a c-compiler where strnicmp is not defined. strnicmp, if defined, usually is case-insensitive comparing of n characters of a string while strncmp usually is case-sensitive comparing of n characters of a string. I suppose case-insensitive comparing shouldn't be turned into case-sensitive comparing except when comparing filenames and turning from a system with case-insensitive file names (e.g., MS-DOS) to a system with case-sensitive filenames (e.g., some Unix/Linux).

1249 #define strcmp strcmp - is redundant.

I used the following config.h

#define ANSI /* To use ANSI functions instead of old-style K&R functions. */
#undef MICROSOFTC
#define LITTLENDIAN
#ifndef MICROSOFTC
/* Despite the phrase "case" being in the functions' names */
/* strncasecmp/strcasecmp do case-insensitive comparing. */
#define strnicmp strncasecmp
#define stricmp strcasecmp
/* Seems K&R c didn't need the following two includes. */
/* Dunno if checking for MICROSOFTC not being defined */
/* or checking for ANSI being defined is the appropriate */
/* condition for inclusion. In my scenario both conditions */
/* are met. */
#include <unistd.h>
#include <stdlib.h>
#endif
#ifdef ANSI
/* Other things in ANSI C are good, but this is a crock */
#define READ_BINARY "rb"
#define WRITE_BINARY "wb"
#else
/* The good old simple and logical K&R I/O */
#define READ_BINARY "r"
#define WRITE_BINARY "w"
#endif

---

I did not yet find the time to track down what goes wrong in dvipaste when using newer dvips.def and non-neutralized l3backend-dvips.def.

I suppose the problem has to do with the ways in which dvipaste "decides" what to copy into the target .dvi-file and that therefore the algorithms implemented in the dvipaste-program would need some alteration.

But my c-knowledge is rusty. The first and last time I was seriously confronted with c-programming was during a course at the university in 1998. (Back in school we had to program everything in Pascal. BASIC and Turbo Assembler were en vogue also.) So the undertaking of grasping dvipaste.c and probably modifying it correctly would take some time.

Thank you for taking the time to read through my elaborations. ;-)

Sincerely

Ulrich