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:
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.)
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:
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. ;-)
Hello,
yesterday I bothered you in TeX LaTeX StackExchange with my attempts of compiling the program
dvipastefor debian buster.I have an i386-vanilla TeX-Live-installation:
I now managed to get a binary which, apart from one problem, seems to work on debian buster:
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:
dvips.defis in use. (I tested withdvips.def 2014/04/23 v3.0jwhich I copied from my old Win95-MiKTeX2.4-installation to the directory wheregrfp1.tex,gefp2.texandgrfp3.texare stored.)l3backend-dvips.defis "neutralized" by placing an empty filel3backend-dvips.definto 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.texandgrfp2.texon my up-to-date vanilla TeX Live installation in the more recent debian-buster platform with recentdvips.defand withl3backend-dvips.defnot "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.texandgrfp2.texandgrfp3.texon 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 thedvipaste-binary created for the more recent debian-buster-platform, then everything works out also.For control:
Vice versa: When I compile
grfp1.texandgrfp2.texandgrfp3.texon my up-to-date vanilla TeX Live installation in the more recent debian-buster platform (with recentdvips.defand withl3backend-dvips.defnot "neutralized") and do not apply thedvipaste-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.texandgrfp2.texandgrfp3.texon 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.defand withl3backend-dvips.defneutralized) 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.defand withl3backend-dvips.defneutralized) AND (dvipaste-binary of Win95/MiKTeX 2.4) → things do work out.In order to obtain that binary I compiled via
sudo make allafter doing the following changes:In
dvipaste.cI removed the lines:Reason:
1248 #define strnicmp strncmpThis is for handling the situation of using a c-compiler where
strnicmpis not defined.strnicmp, if defined, usually is case-insensitive comparing ofncharacters of a string whilestrncmpusually is case-sensitive comparing ofncharacters 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.hI did not yet find the time to track down what goes wrong in dvipaste when using newer
dvips.defand non-neutralizedl3backend-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 thedvipaste-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.cand probably modifying it correctly would take some time.Thank you for taking the time to read through my elaborations. ;-)
Sincerely
Ulrich