updmap + cm-super
Bob Tennent notified by, that updmap (in teTeX-2.0) generates wrong
output for the map files of cm-super for dvipdfm. The following patch
should fix this (and other cases where the name of the .enc file contains
characters other than [A-Za-z0-9]).
Thomas
--- updmap-2.0 Sat Feb 1 18:57:18 2003
+++ updmap Tue Feb 4 06:25:31 2003
@@ -734,9 +734,9 @@
{
sed -e 's@$@ %@' \
-e 's@^\(\([^ ]*\).*\)@\1\2@' \
- -e 's@\(.*[^A-Za-z0-9]\([^ ]*\)\.enc\(.*\)\)@\1 \2@' \
+ -e 's@\(.*<\[* *\([^ ]*\)\.enc\(.*\)\)@\1 \2@' \
-e '/%[^ ]*$/s@$@ default@' \
- -e 's@\(.*[^A-Za-z0-9]\([^ ]*\)\.pf[ab].*\)@\1 \2@' \
+ -e 's@\(.*<<* *\([^ ]*\)\.pf[ab].*\)@\1 \2@' \
-e '/%[^ ]* [^ ]*$/s@\( \([^ ]*\).*\)$@\1 \2@' \
-e 's@\(.* \([.0-9-][.0-9-]*\) *ExtendFont.*\)@\1 -e \2@' \
-e 's@\(.* \([.0-9-][.0-9-]*\) *SlantFont.*\)@\1 -s \2@' \
mpost problem
Hi all, I am one of maintainers of teTeX in Debian and got a bug report on mpost. Please visit http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179505 And one of our maintainers, Julian, told me that this might be caused by the line in texmf.cnf parse_first_line = f and changing this to: parse_first_line = t would make things work again. Further, he advised to add to the beginning of /usr/bin/makempx parse_first_line=t export parse_first_line to prevent this going wrong for other people. How do you think on this advice? I noticed in ChangeLog that it said Sat Oct 26 21:54:03 CEST 2002 * remove that parse_first_line.mpost line (it does not help) so this might be already discussed in this (or somewhere else) list. If so, very sorry. Best regards, 2003-2-4(Tue) -- Debian Developer & Debian JP Developer - much more I18N of Debian Atsuhito Kohda <[EMAIL PROTECTED]> Department of Math., Tokushima Univ.
Re: teTeX-2.0
Thomas Esser <[EMAIL PROTECTED]> writes: > > what's the reason that you changed file names of the archives and > > of the toplevel directory from teTeX-src-2.0 to tetex-src-2.0 > > only about two days before release in rc2 ? > > A challenge for people who depend on these names :-) > > > I really like and try seeing TeX not being spelled "tex" -- and > > even worse, it broke my scripts for automated builds... ;-) > > There is no really good reason. Axel Thimm told me something about > standars in rpm names and that made me think about my archive names > (don't get me wrong: Axel has not suggested that I change the naming > convention; it was my own idea). If youse'all jes used Windows that dang problem wud take care of itself. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: teTeX-2.0
> what's the reason that you changed file names of the archives and > of the toplevel directory from teTeX-src-2.0 to tetex-src-2.0 > only about two days before release in rc2 ? A challenge for people who depend on these names :-) > I really like and try seeing TeX not being spelled "tex" -- and even worse, > it broke my scripts for automated builds... ;-) There is no really good reason. Axel Thimm told me something about standars in rpm names and that made me think about my archive names (don't get me wrong: Axel has not suggested that I change the naming convention; it was my own idea). Thomas
Re: teTeX-2.0
Hi Thomas, On Feb 02, Thomas Esser wrote: > Well, a long time has been around since teTeX-1.0 ... I hereby proudly > presend: > > === >teTeX 2.0 > === > > This is the announce of teTeX-2.0, a TeX distribution for UNIX > compatible systems. first a bing thank for releasing 2.0 !!! > From these servers, you need the following files for teTeX-2.0: > > sources of the programs (required): > ==> tetex-src-2.0.tar.gz what's the reason that you changed file names of the archives and of the toplevel directory from teTeX-src-2.0 to tetex-src-2.0 only about two days before release in rc2 ? I really like and try seeing TeX not being spelled "tex" -- and even worse, it broke my scripts for automated builds... ;-) Harald Koenig -- "I hope to die ___ _ before I *have* to use Microsoft Word.", 0--,|/OOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen.<_/ / /OOO\ \ \/OOO\ \ O|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag// / \\ \ [EMAIL PROTECTED]^ ^
Re: Possible byte-order problems in TeX format files with -rc1
On 03 Feb 2003, Olaf Weber said: > nix writes: > >> This is TeXk, Version 3.14159 (Web2C 7.4.0) > >> This is TeXk, Version 3.14159 (Web2C 7.4.4) > > These tex binaries come from different web2c versions. There's no > guarantee that you can exchange formats between them. I spotted this about an hour after you sent this email; one missing symlink and an insufficiently attentive admin :( I'd not expect such interchangeability to work. Sorry to waste your time :( -- 2003-02-01: the day the STS died.
Re: Possible byte-order problems in TeX format files with -rc1
nix writes:
> This is TeXk, Version 3.14159 (Web2C 7.4.0)
> This is TeXk, Version 3.14159 (Web2C 7.4.4)
These tex binaries come from different web2c versions. There's no
guarantee that you can exchange formats between them.
I've done some tests with: linux (i386, little-endian), IRIX (MIPS 32
bit, big-endian), and IRIX (MIPS 64 bit, big-endian), and can exchange
the formats. The formats differ in more than a few bytes, but they
are mutually interchangable.
What's tripping you up is probably the first part of this change, as
it changed the size of one datatype from 2 bytes to 4.
$ cvs diff -u -rtexk-7_4_0 -rtexk-7_4_4 tex.ch
Index: tex.ch
===
RCS file: /usr/local/cvsroot/texk/texk/web2c/tex.ch,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- tex.ch 11 Nov 2002 09:54:11 - 1.51
+++ tex.ch 14 Jan 2003 10:43:32 - 1.52
@@ -197,8 +197,8 @@
@y
@d file_name_size == maxint
@d ssup_error_line = 255
-@d ssup_max_strings ==65535
-{Larger values may be used, but then the arrays consume much more memory.}
+@d ssup_max_strings == 262143
+{Larger values than 65536 cause the arrays consume much more memory.}
@d ssup_trie_opcode == 65535
@d ssup_trie_size == 262143
@@ -229,7 +229,7 @@
{string of length |file_name_size|; tells where the string pool appears}
@#
@!inf_main_memory = 2999;
-@!sup_main_memory = 800;
+@!sup_main_memory = 3200;
@!inf_trie_size = 8000;
@!sup_trie_size = ssup_trie_size;
@@ -267,7 +267,7 @@
@!inf_font_max = 50; {could be smaller, but why?}
@!inf_pool_size = 32000;
-@!sup_pool_size = 1000;
+@!sup_pool_size = 4000;
@!inf_pool_free = 1000;
@!sup_pool_free = sup_pool_size;
@!inf_string_vacancies = 8000;
--
Olaf Weber
(This space left blank for technical reasons.)
Re: Possible byte-order problems in TeX format files with -rc1
On 02 Feb 2003, [EMAIL PROTECTED] spake: > Format generated on sparc-unknown-linux-gnu, TeXing on i586-pc-linux-gnu: > > This is TeXk, Version 3.14159 (Web2C 7.4.0) > %&-line parsing enabled. > latex: fatal: Item 6 (=1192) of .fmt array at 81df168 <-268435455 or >1020. Just spotted the version number. Bad sign. I expect, now, that there is no bug, merely a moronic operator error. ... yep, it works now I've created the appropriate symlink and am actually running the right bloody version. Oops. Sorry to waste your time. (There should be a warning on the label: `Do not upgrade when ill'...) >> I have just successfully used a i366-linux generated format file >> (tex.fmt and latex.fmt) on a sparc-solaris. So, I don't see anything >> wrong... > > I do, alas :( ... no longer. -- 2003-02-01: the day the STS died.
Re: Possible byte-order problems in TeX format files with -rc1
On 02 Feb 2003, [EMAIL PROTECTED] uttered the following: > (But it's not every byte in the file, or even most of them... so the > problem's not *that* obvious. Alas.) It's more obvious; TeX from web2c-2.4.0 and -2.4.4 cannot share format files! (oops.) -- 2003-02-01: the day the STS died.
