Re: mpost problem
Thomas Esser writes:
A better fix was suggested by Olaf Weber:
--- orig/texk/web2c/mpware/makempx.in Fri Oct 26 15:22:46 2001
+++ texk/web2c/mpware/makempx.in Tue Feb 4 18:31:57 2003
@@ -15,7 +15,7 @@
: ${MPTOTEX=mpto -tex}
: ${MPTOTR=mpto -troff}
: ${NEWER=newer}
-: ${TEX=tex}
+: ${TEX=tex --parse-first-line}
: ${TROFF='eqn -d\$\$ | troff -Tpost'}
# convert relative path to absolute in $MAKEMPX_BINDIR:
By the way, I don't think quotes are required there, but do test so
they can be added if necessary.
--
Olaf Weber
(This space left blank for technical reasons.)
Re: Possible byte-order problems in TeX format files with -rc1
nix writes: I'm sharing format, pool and base files between a sparc64 (32-bit userspace) box and an i386 box --- or I was; but between 20021225 and -rc1, the byte-order independence of these files has broken, even without NO_DUMP_SHARE; all .base, .fmt. .efmt and .mem files differ between those platforms now. The date and time is stored in the format, resolution is a minute. When comparing the formats with 'cmp' verify how many bytes differ. If it is one or two bytes at offsets 97568 or 97567 you should be ok. If you generate the files on different dates, there will be more differences. -- Olaf Weber (This space left blank for technical reasons.)
Re: pdftosrc seg faults
Reinhard Kotucha writes:
Olaf Weber [EMAIL PROTECTED] writes:
Does the following change fix this?
Yes, thank you. But I have to provide the stream object number,
though the usage message says that it's optional.
[...]
I suppose that it should be optional. If it is omitted, pdftosrc
should behave as if stream-object-number is 0. In this case
it should look for /SourceFile. But srcStream.isStream(SourceFile)
is always 0. (pdftosrc.cc, line 85)
The reason it is always 0 is becayse there is no SourceObject in the
Catalog. To put the SourceObject there, use \pdfcatalog instead of
\immediate\pdfcatalog (it's not entirely clear to why the latter
doesn't work). And then you need to make sure there's something in
the pdf at all. So a corrected example would be:
\pdfcompresslevel=0
\immediate\pdfobj stream
attr {/Type /SourceFile /SourceName (\jobname.src)}
file {\jobname.tex}
\pdfcatalog{/SourceObject \the\pdflastobj\space 0 R}
Hello world!
\bye
At that point you'll also discover that pdftosrc writes its output to
a garbage file name, which turns out to be a use-after-free problem.
The full patch now becomes:
--- pdftosrc.cc-2002-12-20 19:47:27.0 +0100
+++ pdftosrc.cc 2003-01-26 14:58:25.0 +0100
@@ -61,7 +61,6 @@
}
fileName = new GString(argv[1]);
globalParams = new GlobalParams();
-xref = NULL;
doc = new PDFDoc(fileName);
if (!doc-isOk()) {
fprintf(stderr, Invalid PDF file\n);
@@ -72,6 +71,7 @@
if (argc = 4)
objgen = atoi(argv[3]);
}
+xref = doc-getXRef();
catalogDict.initNull();
xref-getCatalog(catalogDict);
if (!catalogDict.isDict(Catalog)) {
@@ -92,7 +92,8 @@
exit(1);
}
outname = srcName.getString()-getCString();
-srcName.free();
+// We cannot free srcName, as objname shares its string.
+// srcName.free();
}
else {
xref-fetch(objnum, objgen, srcStream);
@@ -110,7 +111,7 @@
outname = buf;
}
if (!(outfile = fopen(outname, wb))) {
-fprintf(stderr, Cannot open file for writting\n);
+fprintf(stderr, Cannot open file \%s\ for writing\n, outname);
exit(1);
}
s = srcStream.getStream();
--
Olaf Weber
(This space left blank for technical reasons.)
Re: pdftosrc and texmf.in problem?
Atsuhito Kohda writes:
Hi,
I am one of tetex maintainers of Debian and we got a bug report
that please include pdftosrc in tetex-bin
It seemed only a slight modification of texk/web2c/Makefile.in
would make pdftosrc. Is there any reason that pdftosrc was not
made by default?
I'm not sure, actually.
Next problem is; I found in some Japanese web site (or home page?)
that said texmf.in should be changed in the following two lines.
XDVIINPUTS = .;$TEXMF/{xdvi,dvips//}
DVIPDFMINPUTS = .;$TEXMF/{dvipdfm,dvips//}
to
XDVIINPUTS = .;$TEXMF/{xdvi,dvips}//
DVIPDFMINPUTS = .;$TEXMF/{dvipdfm,dvips}//
If this is correct, please fix texmf.in
It doesn't matter one way or the other, as texmf/xdvi doesn't have
subdirectories.
--
Olaf Weber
(This space left blank for technical reasons.)
Re: pdftosrc and texmf.in problem?
Thomas Esser writes: I am one of tetex maintainers of Debian and we got a bug report that please include pdftosrc in tetex-bin I see. pdftosrc was even included in good-old-teTeX-1.0... I have just added @PTEX@pdftosrc = pdftosrc ...tie $(ttf2afm) $(pdftosrc) ... to texk/web2c/Makefile.in. Seems that this is sufficient. Olaf, any objections? Go ahead. -- Olaf Weber (This space left blank for technical reasons.)
Re: 20021022 pretest
Paul Vojta writes: I'd rather you just used .fmt. After all, there's no possibility of an omega .fmt file having the same name as a TeX .fmt file. The context people tell me they've good reasons to do exactly that. Basically, their idea is to be able to do something like texexec --program=tex yourfile versus texexec --program=omega yourfile instead of having to select between cont* formats and gamma formats. More generally, I don't like the idea of Omega putting an `o' everywhere. I'd rather have it be that non-Omega TeXware accepted Omega variants of .tfm, .vf, .pk, etc. files and just used the ISO-8859-1 subset of them. An advantage of this is that oxdvi, odvips, etc. don't have to double their file searching activities. This is my preference as well whenever the omega version is a straightforward extension of the original format. However, in some cases the sizes of underlying datatypes change. As precedent, I point out that when DEK went from 7-bit TeX to 8-bit TeX, he didn't change file extensions. Going from 7-bit to 8-bit is compartively easy, as long as you were effectively working in 8-bit anyway, except that the 8th bit was a dead bit. For the on-disk layof of (say) tfm files, that was the case. DVI is simple, as it has the necessary extensions already. It is supporting formats like tfm and pk that are the problem. So, if you want to hack file extensions, I ask that you hack in the opposite direction: ofm -- tfm, opk -- pk, etc. --Paul Vojta, [EMAIL PROTECTED] -- Olaf Weber (This space left blank for technical reasons.)
Re: format files
Reinhard Kotucha writes:
Thomas == Thomas Esser [EMAIL PROTECTED] writes:
Another problem is that tex \latex myfile doesn't work
properly.
What exactly is the problem? I just have successfully tried $
tex \latex small2e This is TeX, Version 3.14159 (Web2C 7.3.9)
(/usr/share/texmf/tex/latex/base/small2e.tex LaTeX2e
2001/06/01 ... Transcript written on small2e.log
The problem is that the plain TeX search path is used rather the LaTeX
one. No problem with small2e, but generally you must say
--progname=latex to get the desired result. And I think that this is
tex-k specific.
I'm not sure to what extent this is really tex-k specific. However, I
do have an idea of what to change so that TeX will adapt its search
paths to the name of the format it is trying to load, pretty much
regardless of how this was specified.
This, plus some infrstructure changes to get this to compile.
Thomas, WDYT?
Index: tex.ch
===
RCS file: /usr/local/cvsroot/texk/texk/web2c/tex.ch,v
retrieving revision 1.50
diff -u -r1.50 tex.ch
--- tex.ch 20 Oct 2002 17:20:16 - 1.50
+++ tex.ch 25 Oct 2002 19:18:55 -
@@ -1683,10 +1683,14 @@
@x [29.523] l.10095 - Change to pack_buffered_name as with pack_file_name.
for j:=1 to n do append_to_name(xord[TEX_format_default[j]]);
+for j:=a to b do append_to_name(buffer[j]);
@y
if name_of_file then libc_free (name_of_file);
name_of_file := xmalloc_array (ASCII_code, n+(b-a+1)+format_ext_length+1);
for j:=1 to n do append_to_name(xord[TEX_format_default[j]]);
+for j:=a to b do append_to_name(buffer[j]);
+name_of_file[k+1]:=0;
+kpse_reset_program_name(name_of_file+1);{set search path to match format}
@z
@x [29.523] l.10100 - Change to pack_buffered_name as with pack_file_name.
--
Olaf Weber
(This space left blank for technical reasons.)
Re: [tex-k] Web2C 7.3.4: tex -fmt
Reinhard Kotucha writes: Hi Olaf, You've either got two different latex formats, where the two cases differ in which one they find, or tex and latex end up at different binaries (or a combination of both). Use the --kpathsea-debug=-1 flag to find out where the format files are found. Yes, I just see that latex is elatex. Seems to be quite dangerous. Normally one can avoid the %format line but makempx needs it since it always calls tex. It's probably not a good idea to fool tex about its name. Not entire certain whether it is in 7.3.4, but mpost has gotten a flag that allows you specify the TeX program to use on the command line. -- Olaf Weber Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety.
Re: Problem compiling teTeX on IA-64
Adrian Bunk writes: Bdale Garbee [EMAIL PROTECTED] reported the following problem with the 20001218 beta of teTeX: -- snip - The configure script in the texk/kpathsea directory seg faults when running the test program that checks whether putenv uses malloc. The problem is that the test program doesn't include enough headers, and implicit declarations on IA-64 almost always don't do what you want. That's odd: the C standard took a lot of care to ensure that implicit declarations would, in fact, continue to work. So this sounds like there is a possible conformance issue with the compiler and/or standard library lurking here. The fix is easy, that test program needs to #include stdlib.h #include string.h so that there aren't any implicitly declared library functions. The package builds cleanly once this change is made. The catch is that this piece of code dates from the good old days of pre-ANSI C systems where you might not have these headers at all. It seems a reasonable change to make these days. But perhaps there are some people with old systems and an opinion on the matter? -- Olaf Weber Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety.
