Discussion:
[tex-k] (x)dvipdf(m(x)) invocation and default file suffix
Andreas Scherer
2018-05-21 11:15:54 UTC
Permalink
FYI,

It has come to my attention that 'dvipdfm' (on Debian Linux, but also in
a genuine TeXlive installation on Ubuntu Linux) fails to run for

make; make ctangle.pdf

in the current source tree of CWEB 3.64c. It reports this error:

xdvipdfmx:fatal: Something is wrong. Are you sure this is a DVI file?

Apparently, 'xdvipdfmx' mistakes the executable file 'ctangle' (created
by 'make') for input instead of the expected 'ctangle.dvi' (created in
the first part of 'make ctangle.pdf').

I don't have a local version of 'dvipdfm' to check, but Ghostscript's
'dvipdf' works in this setting (as well as the alternative 'pdftex' used
in 'make PDFTEX=pdftex ctangle.pdf').

Andreas
Akira Kakuto
2018-05-22 04:43:18 UTC
Permalink
It has come to my attention ...
(x)dvipdfmx first searches for the input name as a (.xdv).dvi file.
If it fails, it tries by appending a suffix (.xdv).dvi.
Thus 'foo', 'foo.dvi' and/or 'foo.xdv' coexist, you have to
input the full name. That is a feature of (x)dvipdfmx.

Best,
Akira
Karl Berry
2018-05-22 22:38:54 UTC
Permalink
(x)dvipdfmx first searches for the input name as a (.xdv).dvi file.
If it fails, it tries by appending a suffix (.xdv).dvi.

Hi Akira - I think it should try appending .dvi first (unless the input
name already ends with ".dvi"). That's what almost most of the programs
do (I believe), precisely because of the situation Andreas is reporting.

I don't know if the (x)dvipdfmx behavior changed at some point or if
it's always been like that, but either way ...

E.g., with TeX:
tex foo.bar -> try foo.bar.tex first, then foo.bar.
tex foo -> try foo.tex first, then foo.

It's been this way for many years now.
Better for dvipdfmx to have the same behavior, I think? Ok? --thanks, karl.
Akira Kakuto
2018-05-23 00:35:08 UTC
Permalink
Hi Karl,
Post by Karl Berry
Hi Akira - I think it should try appending .dvi first (unless the input
name already ends with ".dvi"). That's what almost most of the programs
do (I believe), precisely because of the situation Andreas is reporting.
OK, done in r47799.

Thanks,
Akira
Andreas Scherer
2018-07-22 08:52:56 UTC
Permalink
Post by Akira Kakuto
OK, done in r47799.
May I point out that this revision is still only in 'Build' and hasn't
been promoted to 'Master' yet. 'xdvipdfmx' still is dated May 9th.

Andreas
Norbert Preining
2018-07-23 05:14:08 UTC
Permalink
Post by Andreas Scherer
Post by Akira Kakuto
OK, done in r47799.
May I point out that this revision is still only in 'Build' and hasn't
been promoted to 'Master' yet. 'xdvipdfmx' still is dated May 9th.
This is to be expected. Binaries are only recompiled once a year for the
release of TeX Live on DVD, unless there are serious bugs showing up.

Norbert

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Andreas Scherer
2018-09-15 09:13:11 UTC
Permalink
Post by Norbert Preining
This is to be expected. Binaries are only recompiled once a year for the
release of TeX Live on DVD, unless there are serious bugs showing up.
Yesterday's move of the xdvipdfmx binary from package xetex to package
dvipdfmx _might_ have been a good time to incorporate the fix for the
file extension handling. ;o)

Andreas
Norbert Preining
2018-09-15 12:28:26 UTC
Permalink
Post by Andreas Scherer
Yesterday's move of the xdvipdfmx binary from package xetex to package
dvipdfmx _might_ have been a good time to incorporate the fix for the
file extension handling. ;o)
The problem is not *moving* a binary from A to B, but recompiling it on
all architectures ...

Norbert

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Andreas Scherer
2018-09-16 17:54:52 UTC
Permalink
... a good time to incorporate the fix for the
file extension handling. ;o)
It took some iterations with the TL sources (and a 'build' script with a
long list of '--disable-XXX' options), but now I have a local version of
'xdvipdfmx' that fits into my TL installation and that works as expected
with the original CWEB Makefile.

Thanks,
Andreas
Norbert Preining
2018-09-16 23:03:19 UTC
Permalink
Post by Andreas Scherer
long list of '--disable-XXX' options), but now I have a local version of
./Build --disable-all-pkgs --enable-xdvipdfmx

should be enough AFAIR when I did test builds ;-)

Norbert

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Andreas Scherer
2018-09-17 15:15:51 UTC
Permalink
Post by Norbert Preining
./Build --disable-all-pkgs --enable-xdvipdfmx
should be enough AFAIR when I did test builds ;-)
I followed advise from the TeXlive build page and read './configure
--help'. Globbing all '--disable-XXX' options with identifiable 'XXX'
packages with the obvious exception 'dvipdfm-x' works fine.

Your suggested commandline fails with this diagnostic:

configure: WARNING: Sorry, neither ApplicationServices framework nor
fontconfig library: disabling xetex
configure: error: terminating.
=== configuring in web2c failed
Makefile:909: recipe for target 'recurse' failed
make[2]: *** [recurse] Error 1
make[2]: Leaving directory
'/home/andreas/Work/tmp/texlive2018/source/Work/texk'
Makefile:486: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/home/andreas/Work/tmp/texlive2018/source/Work/texk'
Makefile:574: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

so I'll use my handcrafted 'build' shell script at this time.

BTW, the long list of '--disable-XXX/---enable-YYY' options suggested by
'./configure --help' is quite confusing to digest. Maybe a list of
possible 'XXX' and 'YYY' entries in connection with a generic
description of the symmetric (?) '--disable/--enable' options would be
easier for novices to understand.

Andreas
Norbert Preining
2018-09-18 07:12:08 UTC
Permalink
Hi

Yes, as you found it is --enable-dvipdfm-x
Post by Andreas Scherer
configure: WARNING: Sorry, neither ApplicationServices framework nor
fontconfig library: disabling xetex
configure: error: terminating.
=== configuring in web2c failed
Yes, configure is still called in all dirs, but not the build process.
You need fontconfig-dev installed.

In my case the
./Build --disable-all-pkgs --enable-dvipdfm-x
did work out without any problem.
Post by Andreas Scherer
possible 'XXX' and 'YYY' entries in connection with a generic
description of the symmetric (?) '--disable/--enable' options would be
easier for novices to understand.
That is auto-generated from auto* stuff, we don't want to hack that.

Best

Norbert

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
a***@freenet.de
2018-09-18 07:53:01 UTC
Permalink
Post by Norbert Preining
Post by Andreas Scherer
=== configuring in web2c failed
Yes, configure is still called in all dirs, but not the build process.
You need fontconfig-dev installed.
Well, stacking "all" '--disable-XXX' options for './Build' somehow seems to circumvent this. I think I started with '--disable-web2c' at first and kept going with the other stuff from './configure --help' to speed things up. I'm pretty sure that 'fontconfig-dev' is not installed on my Linux box. For the time being I don't intend to dig into the texlive source tree any deeper, so I'm happy with the single updated executable.
Thanks again,Andreas
Please ignore the attached ad from freenet. I'm writing online.

Loading...