From Sherlock@rna.nl Thu Oct 3 08:27:16 2002 From: Sherlock@rna.nl (Gerben Wierda) Date: Thu, 3 Oct 2002 09:27:16 +0200 Subject: [tex-k] Fwd: TeXShop/teTeX speed using TeX+ghostscript Message-ID: <8B59107C-D6A1-11D6-8E72-0003930AD8A4@rna.nl> There was a discussion on the Mac OS X TeX list on the past behaviour of TeX on NeXT (which is still lightning fast on 10-year old hardware fast compared to TeX on Mac OS X). I asked Tom Rokicki about this. His answer is appended below. I would love to see this return to TeX. It seems a small issue: 1. Make sure the output file is flushed whenever a page is shipped out. 2. Write something to a named pipe to signal a page has been shipped. The current --ipc implementation seems to be (from the man page) to write DVI to a socket. The man page doesn't say what/which socket. I would like to know if this is true for pdfTeX also. I would be interested in knowing if the original mechanism by Tomas Rokicki is still there somehow or if people are interested to have this added to texk. It would really be great to have this. Also note the remark that Tomas made at the end of his mail to me. That, of course, is a very interesting feature as well. G Begin forwarded message: > From: "Tomas G. Rokicki" > Date: Thu Oct 3, 2002 06:01:55 Europe/Amsterdam > To: Sherlock@rna.nl, rokicki@CS.Stanford.EDU > Subject: Re: Fwd: [OS X TeX] TeXShop/teTeX speed using TeX+ghostscript > > Howdy! > > No, I think --ipc would be trivial to implement. I think it's even > in teTeX---or it was, at one point. > > The only important things are as follows: > > 1. After each page is shipped, make sure that the dvi file is flushed. > 2. Write to a named pipe (that's how I did it but I'm sure that there > other other ways) indicating the availability of a new page and > the corresponding "new" eof in the dvi file. > 3. Modify the previewer to never read the dvi file past this eof, > and make it be prepared to deal with the new eof information. > > It's actually quite simple to do. > > Now, looking at teTeX, it looks like they have a different way of > doing it---sending the dvi info to a socket. This, to me, while > workable, isn't perfect; I'd rather just pull the bytes directly > from the dvi file that TeX is already writing. But that's just me. > > I'd be happy to discuss this with anyone interested in implementing it. > I did it for both the Amiga and the NeXT, and it does make a > significant difference. > > [So does preloading the format file, and "reloading" it from memory > rather than from disk by understanding what parts are mutable and > which are not, which allows you to reTeX almost instantly, and gives > you lightning-TeX like features pretty easy, but that's a different > topic . . .] > > -tom > From mdm@hanmail.net Thu Oct 3 16:37:35 2002 From: mdm@hanmail.net (마케팅) Date: Fri, 4 Oct 2002 00:37:35 +0900 Subject: [tex-k] (광고)2년동안 노하우를 모두 드립니다!! Message-ID: <200210031537.g93Fbtx07743@tug.org> Untitled Document
We inform you, inaccordance with the advise of Ministry of information and Communication, that this email is an advertisement and the address of which hasbeen gathered form bulletine boards on internet as well as that we do not have any further information about you other than your email adress.If you do not wish to receive this email refuse button.
버튼을 클릭하시면 수신거부처리가 이루어 집니다.
From te@dbs.uni-hannover.de Thu Oct 3 19:56:57 2002 From: te@dbs.uni-hannover.de (Thomas Esser) Date: Thu, 3 Oct 2002 20:56:57 +0200 Subject: [tex-k] (광고)2년동안 노하우를 모두 드립니다!! Message-ID: <200210031856.g93Iuv6V008422@gauss.informatik.uni-hannover.de> Sorry for the noise (last message). I (list maintainer) have hit the wrong button and accidently approved that message. Usually, messages like these end up until I decide about them and unless I hit the wrong button, junk like this will just be discarded. Sorry again, Thomas From janneke@gnu.org Fri Oct 4 15:29:40 2002 From: janneke@gnu.org (Jan Nieuwenhuizen) Date: Fri, 04 Oct 2002 16:29:40 +0200 Subject: [tex-k] Windows validation of texk patches? Message-ID: <87bs6auvjf.fsf@peder.flower> Hi Fabrice, For the teTeX distribution on Cygwin, I've had to make some patches, mainly to texk and web2c. You can find them here: http://tug.org/pipermail/tex-k/2002-September/000533.html I took care not to change the behaviour for mingw or plain Windows, but Olaf needs to make sure that my patches don't break your code. As non of us can test your Windows code, he wrote [Thomas and me]: There's stuff in there that I'm not sure about, because it looks like it might interact with Fabrice's [Windows] support (...) the KPSEDLL area, and I think it would be good if Jan could coordinate those bits with Fabrice. I would appreciate it if you could have a look/test at the patches*, notably the Cygwin patch and the DLL area, and tell me if there's any problems that we need to work out. Greetings, Jan. * In case you're not on the tex-k list, I can resend the patches to you personally; pulling them from the archive might be troublesome. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org From meling@item.ntnu.no Thu Oct 10 20:03:14 2002 From: meling@item.ntnu.no (Hein Meling) Date: 10 Oct 2002 21:03:14 +0200 Subject: [tex-k] (pdf)latex wishlist item; configurable output granularity Message-ID: <1034276595.6023.391.camel@arm.item.ntnu.no> Dear all, PS; I'm not on this list, so please respond directly to me. I'm using the tetex package (the Debian version.) What I have been missing for a long time is the possibility to set the granularity of the output produced by latex/pdflatex etc. I mean the jobname.log file contains most of the details anyway, and a lot of (less useful) stuff is output to the screen as well. I would like to be able to configure what is printed to the screen, so as to make it easier to identify "relevant problems," like missing references, over/underfull boxes etc. I normally don't care about which files (including figures, fonts) are begin loaded, on which page figures are placed etc. Could you please direct me to any documentation on this (if the feature exists), alternatively where should I start looking if I wanted to implement such a feature myself. Best regards, Hein Meling From olaf@infovore.xs4all.nl Fri Oct 11 18:00:29 2002 From: olaf@infovore.xs4all.nl (Olaf Weber) Date: 11 Oct 2002 19:00:29 +0200 Subject: [tex-k] Fwd: TeXShop/teTeX speed using TeX+ghostscript In-Reply-To: <8B59107C-D6A1-11D6-8E72-0003930AD8A4@rna.nl> References: <8B59107C-D6A1-11D6-8E72-0003930AD8A4@rna.nl> Message-ID: <87vg48gbbm.fsf@infovore.xs4all.nl> Gerben Wierda writes: > There was a discussion on the Mac OS X TeX list on the past behaviour > of TeX on NeXT (which is still lightning fast on 10-year old hardware > fast compared to TeX on Mac OS X). I asked Tom Rokicki about this. His > answer is appended below. The code is still there. The socket is named $HOME/.TeXview_Pipe Look for IPC in texmfmp.c, --with-ipc in configure. I don't use it myself, so make no claims as to whether is works for your (or any) purpose. > I would love to see this return to TeX. It seems a small issue: > 1. Make sure the output file is flushed whenever a page is shipped out. It uses unix 'write(2)' into a UNIX domain socket. I think the application doesn't need to do explicit flushes at that point. > 2. Write something to a named pipe to signal a page has been shipped. There is an end-of-page indicator in the message. But even if it only dumped a raw dvi stream, you'd just scan for the dvi eop operator in the stream. > The current --ipc implementation seems to be (from the man page) to > write DVI to a socket. The man page doesn't say what/which socket. I > would like to know if this is true for pdfTeX also. "probably" > I would be interested in knowing if the original mechanism by Tomas > Rokicki is still there somehow or if people are interested to have > this added to texk. It would really be great to have this. Also note > the remark that Tomas made at the end of his mail to me. That, of > course, is a very interesting feature as well. > G > Begin forwarded message: >> From: "Tomas G. Rokicki" >> Date: Thu Oct 3, 2002 06:01:55 Europe/Amsterdam >> To: Sherlock@rna.nl, rokicki@CS.Stanford.EDU >> Subject: Re: Fwd: [OS X TeX] TeXShop/teTeX speed using TeX+ghostscript >> >> Howdy! >> >> No, I think --ipc would be trivial to implement. I think it's even >> in teTeX---or it was, at one point. >> >> The only important things are as follows: >> >> 1. After each page is shipped, make sure that the dvi file is flushed. >> 2. Write to a named pipe (that's how I did it but I'm sure that there >> other other ways) indicating the availability of a new page and >> the corresponding "new" eof in the dvi file. >> 3. Modify the previewer to never read the dvi file past this eof, >> and make it be prepared to deal with the new eof information. >> >> It's actually quite simple to do. >> >> Now, looking at teTeX, it looks like they have a different way of >> doing it---sending the dvi info to a socket. This, to me, while >> workable, isn't perfect; I'd rather just pull the bytes directly >> from the dvi file that TeX is already writing. But that's just me. >> >> I'd be happy to discuss this with anyone interested in implementing it. >> I did it for both the Amiga and the NeXT, and it does make a >> significant difference. >> >> [So does preloading the format file, and "reloading" it from memory >> rather than from disk by understanding what parts are mutable and >> which are not, which allows you to reTeX almost instantly, and gives >> you lightning-TeX like features pretty easy, but that's a different >> topic . . .] >> >> -tom >> > _______________________________________________ > tex-k mailing list > tex-k@tug.org > http://tug.org/mailman/listinfo/tex-k -- Olaf Weber (This space left blank for technical reasons.) From martin@oneiros.de Fri Oct 11 23:33:31 2002 From: martin@oneiros.de (Martin Schroeder) Date: Sat, 12 Oct 2002 00:33:31 +0200 Subject: [tex-k] Fwd: TeXShop/teTeX speed using TeX+ghostscript In-Reply-To: <87vg48gbbm.fsf@infovore.xs4all.nl>; from olaf@infovore.xs4all.nl on Fri, Oct 11, 2002 at 07:00:29PM +0200 References: <8B59107C-D6A1-11D6-8E72-0003930AD8A4@rna.nl> <87vg48gbbm.fsf@infovore.xs4all.nl> Message-ID: <20021012003331.D11504@lucien.kn-bremen.de> On 2002-10-11 19:00:29 +0200, Olaf Weber wrote: > Gerben Wierda writes: > > The current --ipc implementation seems to be (from the man page) to > > write DVI to a socket. The man page doesn't say what/which socket. I > > would like to know if this is true for pdfTeX also. > > "probably" But only when producing DVI. Incrementally writing pdf is difficult if possible at all. Best regards Martin -- http://www.tm.oneiros.de From roozbeh@sharif.edu Sat Oct 12 01:47:41 2002 From: roozbeh@sharif.edu (Roozbeh Pournader) Date: Sat, 12 Oct 2002 04:17:41 +0330 (IRT) Subject: [tex-k] Fwd: TeXShop/teTeX speed using TeX+ghostscript In-Reply-To: <20021012003331.D11504@lucien.kn-bremen.de> Message-ID: On Sat, 12 Oct 2002, Martin Schroeder wrote: > Incrementally writing pdf is difficult if possible at all. But there's a section in PDF reference manual about this, IIRC. Isn't it? roozbeh From The Thanh Han Sat Oct 12 02:21:03 2002 From: The Thanh Han (The Thanh Han) Date: Sat, 12 Oct 2002 08:21:03 +0700 Subject: [tex-k] Fwd: TeXShop/teTeX speed using TeX+ghostscript In-Reply-To: <20021012003331.D11504@lucien.kn-bremen.de> References: <8B59107C-D6A1-11D6-8E72-0003930AD8A4@rna.nl> <87vg48gbbm.fsf@infovore.xs4all.nl> <20021012003331.D11504@lucien.kn-bremen.de> Message-ID: <20021012012103.GA3191@pc.thanh.home> On Sat, Oct 12, 2002 at 12:33:31AM +0200, Martin Schroeder wrote: > On 2002-10-11 19:00:29 +0200, Olaf Weber wrote: > > Gerben Wierda writes: > > > The current --ipc implementation seems to be (from the man page) to > > > write DVI to a socket. The man page doesn't say what/which socket. I > > > would like to know if this is true for pdfTeX also. > > > > "probably" > > But only when producing DVI. Incrementally writing pdf is > difficult if possible at all. it is possible with a few changes -- at the moment pdftex uses a few seek's that can be removed (at the price that the pdf output will be showwhat larger). Thanh From olaf@infovore.xs4all.nl Sun Oct 13 11:55:31 2002 From: olaf@infovore.xs4all.nl (Olaf Weber) Date: 13 Oct 2002 12:55:31 +0200 Subject: [tex-k] Fwd: TeXShop/teTeX speed using TeX+ghostscript In-Reply-To: <20021012012103.GA3191@pc.thanh.home> References: <8B59107C-D6A1-11D6-8E72-0003930AD8A4@rna.nl> <87vg48gbbm.fsf@infovore.xs4all.nl> <20021012003331.D11504@lucien.kn-bremen.de> <20021012012103.GA3191@pc.thanh.home> Message-ID: <87of9yehgc.fsf@infovore.xs4all.nl> The Thanh Han writes: > On Sat, Oct 12, 2002 at 12:33:31AM +0200, Martin Schroeder wrote: >> On 2002-10-11 19:00:29 +0200, Olaf Weber wrote: >>> Gerben Wierda writes: >>>> The current --ipc implementation seems to be (from the man page) to >>>> write DVI to a socket. The man page doesn't say what/which socket. I >>>> would like to know if this is true for pdfTeX also. >>> "probably" >> But only when producing DVI. Incrementally writing pdf is >> difficult if possible at all. > it is possible with a few changes -- at the moment pdftex uses a few seek's > that can be removed (at the price that the pdf output will be showwhat > larger). Generating compact output is also a virtue: disk may be large, but networks are often still slow. Would it be possible/worthwhile to make this conditional? -- Olaf Weber (This space left blank for technical reasons.) From martin@oneiros.de Tue Oct 15 10:06:43 2002 From: martin@oneiros.de (Martin Schroeder) Date: Tue, 15 Oct 2002 11:06:43 +0200 Subject: [tex-k] [rhn-admin@rhn.redhat.com: RHN Errata Alert: Command execution vulnerability in dvips] Message-ID: <20021015110643.O2098@artcom8.artcom-gmbh.de> --5xSkJheCpeK0RUEJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, this just arrived via a collegue. In which version of dvips has this been fixed? Best regards Martin -- http://www.tm.oneiros.de --5xSkJheCpeK0RUEJ Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from artcom7 by artcom8.artcom-gmbh.de with uucp (Smail3.2 #1) id m181KYq-000WDLC; Tue, 15 Oct 2002 07:48:08 +0200 (CEST) Received: from artcom0 by artcom7.artcom-gmbh.de with uucp (Smail3.2 #1) id m181KY2-000pAqC; Tue, 15 Oct 2002 07:47:18 +0200 (MEST) Received: by artcom0.artcom-gmbh.de (Smail3.2 #1) id m181KWv-00BMy2C; Tue, 15 Oct 2002 07:46:09 +0200 (CEST) Sender: pf@artcom0.artcom-gmbh.de (Peter Funk) Received: from artcom7 by artcom0.artcom-gmbh.de with uucp (Smail3.2 #1) id m181GxO-00BNV2C; Tue, 15 Oct 2002 03:57:14 +0200 (CEST) Received: by artcom7.artcom-gmbh.de (Smail3.2 #1) id m181GwM-000pAqC; Tue, 15 Oct 2002 03:56:10 +0200 (MEST) Received: (from uartcom@localhost) by artcomm.artcom-gmbh.de (8.11.6+Sun/8.9.3) with UUCP id g9F1t7B15331 for pf@artcom0.artcom-gmbh.de; Tue, 15 Oct 2002 03:55:07 +0200 (MEST) Received: from mx-2.kkf.net (mx-2.kkf.net [62.145.24.154]) by artinet.artcom-gmbh.de (8.9.3+Sun/8.9.3) with SMTP id DAA22850 for ; Tue, 15 Oct 2002 03:53:39 +0200 (MEST) Received: (qmail 6508 invoked by uid 54); 15 Oct 2002 01:53:39 -0000 Received: from rhn-bounce+1333960-1893562@rhn.redhat.com by mx-2 by uid 51 with qmail-scanner-1.10 (. Clear:0. Processed in 0.127422 secs); 15 Oct 2002 01:53:39 -0000 X-Qmail-Scanner-Mail-From: rhn-bounce+1333960-1893562@rhn.redhat.com via mx-2 X-Qmail-Scanner: 1.10 (Clear:0. Processed in 0.127422 secs) Received: from mail.rhn.redhat.com (HELO rhn-mail.rdu-colo.redhat.com) (66.187.232.120) by 0 with SMTP; 15 Oct 2002 01:53:38 -0000 Received: from scripts.rdu-colo.redhat.com (nat-pix.rdu.redhat.com [10.255.18.200] (may be forged)) by rhn-mail.rdu-colo.redhat.com (8.11.6/8.11.6) with ESMTP id g9F1rb119366 for ; Mon, 14 Oct 2002 21:53:37 -0400 Received: (from root@localhost) by scripts.rdu-colo.redhat.com (8.11.6/8.11.6) id g9F1nBt31110; Mon, 14 Oct 2002 21:49:11 -0400 Date: Mon, 14 Oct 2002 21:49:11 -0400 Message-Id: <200210150149.g9F1nBt31110@scripts.rdu-colo.redhat.com> Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: rhn-bounce+1333960-1893562@rhn.redhat.com From: Red Hat Network Alert Precedence: first-class Subject: RHN Errata Alert: Command execution vulnerability in dvips To: pefunk X-RHN-Email: X-RHN-Info: Autogenerated mail for pefunk X-RHN-Login: pefunk X-Qmail-Scanner-1.10: added fake MIME-Version header MIME-Version: 1.0 Sender: pf@artcom0.artcom-gmbh.de Red Hat Network has determined that the following advisory is applicable to one or more of the systems you have registered: Complete information about this errata can be found at the following location: https://rhn.redhat.com/network/errata/errata_details.pxt?eid=1230 Security Advisory - RHSA-2002:194-18 ------------------------------------------------------------------------------ Summary: Command execution vulnerability in dvips dvips contains a vulnerability allowing print users to execute arbitrary commands Description: The dvips utility converts DVI format into PostScript(TM), and is used in Red Hat Linux as a print filter for printing DVI files. A vulnerability has been found in dvips which uses the system() function insecurely when managing fonts. Since dvips is used in a print filter, this allows local or remote attackers who have print access to carefully craft a print job that would allow them to execute arbitrary code as the user 'lp'. A work around for this vulnerability is to remove the print filter for DVI files. The following commands, run as root, will accomplish this: rm -f /usr/share/printconf/mf_rules/mf40-tetex_filters rm -f /usr/lib/rhs/rhs-printfilters/dvi-to-ps.fpi However, to fix the problem in the dvips utility as well as removing the print filter we recommend that all users upgrade these errata packages which contain a patch for this issue. This vulnerability was discovered by Olaf Kirch of SuSE. Additionally, the file /var/lib/texmf/ls-R had world-writable permissions. This is also fixed in the packages referenced in this advisory. ------------------------------------------------------------------------------ ------------- Taking Action ------------- You may address the issues outlined in this advisory in two ways: - select your server name by clicking on its name from the list available at the following location, and then schedule an errata update for it: https://rhn.redhat.com/network/systemlist/system_list.pxt - run the Update Agent on each affected server. --------------------------------- Changing Notification Preferences --------------------------------- To enable/disable your Errata Alert preferences globally please log in to RHN and navigate from "Your RHN" / "Your Account" to the "Preferences" tab. URL: https://rhn.redhat.com/network/my_account/my_prefs.pxt You can also enable/disable notification on a per system basis by selecting an individual system from the "Systems List". From the individual system view click the "Details" tab. ---------------- Affected Systems ---------------- According to our records, this errata may apply to one or more of the systems that you've profiled with Red Hat Network. To see precisely which systems are affected, please go to: https://rhn.redhat.com/network/errata/systems_affected.pxt?eid=1230 The Red Hat Network Team This message is being sent by Red Hat Network Alert to: RHN user login: pefunk Email address on file: If you lost your RHN password, you can use the information above to retrieve it by email from the following address: https://rhn.redhat.com/forgot_password.pxt To cancel these notices, go to: https://rhn.redhat.com/oo.pxt?uid=1333960&oid=1893562 --5xSkJheCpeK0RUEJ-- From rokicki@CS.Stanford.EDU Tue Oct 15 16:20:25 2002 From: rokicki@CS.Stanford.EDU (Tomas G. Rokicki) Date: Tue, 15 Oct 2002 08:20:25 -0700 Subject: [tex-k] [rhn-admin@rhn.redhat.com: RHN Errata Alert: Command execution vulnerability in dvips] Message-ID: I am not sure whether this has been fixed or not. Further, I suspect it hasn't been. There is #ifdef SECURE, but I'm not even sure that covers all the possibilities. Dvips uses popen() and system() in 11 different places, and not all of them appear to be appropriately protected. I was not aware of this advisory before this time. I will have to spend some time and determine what the impact is. I will also spend some time and close all the obvious popen/system issues in dvips. I'm not sure how paranoid I need to be. The makefont subroutine executes scripts, which might be insecure or might execute binaries without hardwiring a path, which can then be hijacked, etc. But I will spend some time on it, probably next week (the 25th and 26th of October). There is some ancient functionality in there (the use of tek2ps and iff2ps to convert Tektronix graphics and Amiga IFF format to PostScript, neither of which are probably used by anyone) that might be hijacked. This *may* end up reducing the functionality of dvips. From kakuto@fsci.fuk.kindai.ac.jp Tue Oct 15 17:03:41 2002 From: kakuto@fsci.fuk.kindai.ac.jp (Akira Kakuto) Date: Wed, 16 Oct 2002 01:03:41 +0900 Subject: [tex-k] [rhn-admin@rhn.redhat.com: RHN Errata Alert: Command execution vulnerability in dvips] In-Reply-To: Your message of "Tue, 15 Oct 2002 08:20:25 -0700" References: Message-ID: <200210151603.BAA25174@jupiter.fsci.fuk.kindai.ac.jp> > I am not sure whether this has been fixed or not. > > Further, I suspect it hasn't been. system() is disabled by default in config.ps: * Run securely (z: disable system call, z0: enable system call) * overriden by -R0 and -R options, respectively. z * Boolean secure = 1 ; /* make safe for suid */ in dvips.c will be better. (Currently Boolean secure = 0 ; /* make safe for suid */) If one invokes by -R0 option, system() is enabled. -- Akira Kakuto From rokicki@CS.Stanford.EDU Tue Oct 15 17:17:07 2002 From: rokicki@CS.Stanford.EDU (Tomas G. Rokicki) Date: Tue, 15 Oct 2002 09:17:07 -0700 Subject: [tex-k] [rhn-admin@rhn.redhat.com: RHN Errata Alert: Command execution vulnerability in dvips] Message-ID: To my knowledge, this "disabling" of system only disables *some* of the system and popen calls, and not all. But I could be wrong. And yes, this is clearly a bug. -tom From twaugh@redhat.com Tue Oct 15 17:37:13 2002 From: twaugh@redhat.com (Tim Waugh) Date: Tue, 15 Oct 2002 17:37:13 +0100 Subject: [tex-k] [rhn-admin@rhn.redhat.com: RHN Errata Alert: Command execution vulnerability in dvips] In-Reply-To: References: Message-ID: <20021015163713.GH1098@redhat.com> --2zkT5PsbWu6kxoCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 15, 2002 at 08:20:25AM -0700, Tomas G. Rokicki wrote: > Dvips uses popen() and system() in 11 different places, and not all > of them appear to be appropriately protected. Indeed. Red Hat Linux 8.0 ships with secure mode enabled by default. The idea was that people could use -R0 when they needed it (in practice, there seems to be a bug preventing that from working..). > I was not aware of this advisory before this time.=20 Really? I'd been told that this was being discussed with the maintainer. > I'm not sure how paranoid I need to be. The makefont subroutine > executes scripts, which might be insecure or might execute binaries > without hardwiring a path, which can then be hijacked, etc.=20 (This is precisely what this advisory is about.) Tim. */ --2zkT5PsbWu6kxoCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9rEQ4tO8Ac4jnUq4RAkvnAKCRFJilKLQaQzu1re8Q0yoQ7gj6xACffoP9 qS5EklDG62ZLYRTup+7wL4A= =aaNF -----END PGP SIGNATURE----- --2zkT5PsbWu6kxoCU-- From twaugh@redhat.com Tue Oct 15 17:37:39 2002 From: twaugh@redhat.com (Tim Waugh) Date: Tue, 15 Oct 2002 17:37:39 +0100 Subject: [tex-k] [rhn-admin@rhn.redhat.com: RHN Errata Alert: Command execution vulnerability in dvips] In-Reply-To: <200210151603.BAA25174@jupiter.fsci.fuk.kindai.ac.jp> References: <200210151603.BAA25174@jupiter.fsci.fuk.kindai.ac.jp> Message-ID: <20021015163739.GI1098@redhat.com> --Gnkm4uF329L9IN0W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Oct 16, 2002 at 01:03:41AM +0900, Akira Kakuto wrote: > Boolean secure = 1 ; /* make safe for suid */ > in dvips.c will be better. This is the change made in Red Hat Linux 8.0. Tim. */ --Gnkm4uF329L9IN0W Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9rERStO8Ac4jnUq4RAkpqAJwM+RMPH7Ce3BXHIEpiBrxFGsyBxgCeMvJN ebx73u6zrtBzbtQVEt+0/Mo= =Ubj4 -----END PGP SIGNATURE----- --Gnkm4uF329L9IN0W-- From wybo@servalys.nl Tue Oct 15 12:34:58 2002 From: wybo@servalys.nl (Wybo Dekker) Date: Tue, 15 Oct 2002 13:34:58 +0200 (CEST) Subject: [tex-k] context -version option Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463811840-1419415111-1034681698=:12241 Content-Type: TEXT/PLAIN; charset=US-ASCII context has a -version option (like other tex executables) which does not really give the information one would expect, but rather version information about tex, web2c and kpathsea. Nevertheless, especially for the rapidly developing context, that information is of interest for developers. I have attached a small perl script that gives real version information, and I think that -version should give that information, too. -- Kind regards, Wybo Dekker ---Servalys Analytical Chemistry Services--- Wybo Dekker wybo@servalys.nl Deilsedijk 60 www.servalys.nl 4158 CH Deil tel +31-345-652164 The Netherlands fax +31-345-652383 ---1463811840-1419415111-1034681698=:12241 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=context_version Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=context_version IyEvdXNyL2Jpbi9wZXJsIC13DQoNCj1oZWFkMSBOQU1FDQoNCmNvbnRleHRf dmVyc2lvbiAtIHByaW50IENvblRlWHQncyB2ZXJzaW9uDQoNCj1oZWFkMSBT WU5PUFNJUw0KDQoJY29udGV4dF92ZXJzaW9uIFtpbnRlcmZhY2VdDQoNCj1o ZWFkMSBERVNDUklQVElPTg0KDQpBY2NvcmRpbmcgdG8gdGhlIHJlc3VsdCBv ZiBDb25UZVh0J3MgLWhlbHAgb3B0aW9uLCB0aGUgLXZlcnNpb24gb3B0aW9u IHNob3VsZCBwcm92aWRlDQp2ZXJzaW9uIGluZm9ybWF0aW9uLiBJdCBkb2Vz IG5vdC4gVGhpcyBzY3JpcHQgdGVsbHMgeW91IENvblRlWHQncyB2ZXJzaW9u LiBJdCBkb2VzIHNvDQppbiBDPHl5eXltbWRkPiBmb3JtYXQsIHNvIHRoYXQg eW91IGNhbiBlYXNpbHkgdGVzdCB5b3VyIHZlcnNpb24gYWdhaW5zdCBhDQpy ZXF1aXJlbWVudC4gDQoNClRoZSB2ZXJzaW9uIGlzIHRha2VuIGZyb20gdGhl IGZvcm1hdCBmaWxlLCBub3QgZnJvbSBGPGNvbnRleHQudGV4Pi4gVGhlIGxh dHRlciBtYXkNCmRpZmZlciBmcm9tIHRoZSBmb3JtYXQgaWYgeW91IGZvcmdv dCB0byBidWlsZCBhIG5ldyBmb3JtYXQuIA0KDQpDPGludGVyZmFjZT4gY2Fu IGJlIEM8ZW4+LCBDPG5sPiwgZXQgY2V0ZXJhLiBUaGUgZGVmYXVsdCBpcyBD PGVuPi4NCg0KPWN1dA0KDQpteSAkY29udGV4dD0nY29udC0nLihzaGlmdHx8 J2VuJyk7DQoNCm9wZW4oSU4sImVjaG8gXFxcXGVuZHwkY29udGV4dHwiKSBv ciBkaWUgIkNvdWxkIG5vdCBydW4gJGNvbnRleHRcbiI7IA0Kd2hpbGUoPElO Pikgew0KICAgIC92ZXI6IChcZCspXC4oXGQrKVwuKFxkKykvIGFuZCANCiAg ICAgICAgcHJpbnRmKCIlNGQlMDJkJTAyZFxuIiwkMSwkMiwkMyksbGFzdDsN Cn0NCg== ---1463811840-1419415111-1034681698=:12241-- From cahill@helix.nih.gov Fri Oct 18 19:41:34 2002 From: cahill@helix.nih.gov (Kevin Cahill) Date: Fri, 18 Oct 2002 14:41:34 -0400 Subject: [tex-k] fonts for dvips Message-ID: <3DB055DE.7050500@helix.nih.gov> My dvips can not find the right fonts. I am running Red Hat linux 7.3 and have installed the updates that were sent to me by Red Hat's up2date service. But when using the slides documentclass, I can't get dvips to find the fonts it needs, e.g., most subscripts and superscripts were missing. Would you be so kind as to tell me how to configure dvips or how to find and install a complete set of fonts from the web? Here is what dvips says when it fails to find the right fonts: This is dvips(k) 5.86 Copyright 1999 Radical Eye Software (www.radicaleye.com) ' TeX output 2002.10.18:1414' -> fest.ps kpathsea: Running mktexpk --mfmode phaserfs --bdpi 1200 --mag 2+88/1200 --dpi 2488 lcmss8 mktexpk: Running mf \mode:=phaserfs; mag:=2+88/1200; nonstopmode; input lcmss8 This is METAFONT, Version 2.7182 (Web2C 7.3.1) (/usr/share/texmf/fonts/source/public/latex/lcmss8.mf (/usr/share/texmf/fonts/source/public/cm/cmbase.mf) (/usr/share/texmf/fonts/source/public/latex/sroman.mf (/usr/share/texmf/fonts/source/public/latex/sromanu.mf (/usr/share/texmf/fonts/source/public/cm/romanu.mf [65] [66] [67] [68] [69] [70] [71] [72] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90]) [73]) (/usr/share/texmf/fonts/source/public/cm/romanl.mf ! bad pos. ; pos->...XPR3)<=currentbreadth:errmessage"bad pos"; fi.fi(x(SUFFIX2)r-x(SUFFIX... l.33 pos9(thin_join,360) ; z9l=z5l; > 0 WSW 1 SSW WSW 2 WNW NNW 3 NNE ENE 4 5 (ESE SSE) SSW 6 WSW 7 SSW 8 SSE ESE 9 ENE NNE 0 (NNW WNW) ! Strange path (turning number is zero). }} l.36 ...}...z8e{left}...{up}z7e&super_arc.e(7,6)}} ; % bowl [97] ! bad pos. ; pos->...XPR3)<=currentbreadth:errmessage"bad pos"; fi.fi(x(SUFFIX2)r-x(SUFFIX... l.66 ...pos3(if hefty:thin_join else: hair fi,180) ; ! bad penpos. ; penpos->...3):if(EXPR3)<=0:errmessage"bad penpos"; fi.fi(x(SUFFIX2)r-x(SUFFIX... l.67 ...,0); pos6(vair,-90); penpos7(x3l-x3r,-180) ; [98] [99] ! bad pos. ; pos->...XPR3)<=currentbreadth:errmessage"bad pos"; fi.fi(x(SUFFIX2)r-x(SUFFIX... l.122 ... pos3(if hefty:thin_join else: hair fi,0) ; ! bad penpos. ; penpos->...3):if(EXPR3)<=0:errmessage"bad penpos"; fi.fi(x(SUFFIX2)r-x(SUFFIX... l.123 ...80); pos6(vair,270); penpos7(x3r-x3l,360) ; [100] [101] [102] etc. -- Kevin Cahill sabbatical address: permanent address: 12A/2051, MS 5624 Physics Department National Institutes of Health University of New Mexico Bethesda, MD 20892-5624 Albuquerque, NM 87131-1156 301 402 1670 505 277 5318 From rokicki@CS.Stanford.EDU Fri Oct 18 20:05:33 2002 From: rokicki@CS.Stanford.EDU (Tomas G. Rokicki) Date: Fri, 18 Oct 2002 12:05:33 -0700 Subject: [tex-k] fonts for dvips Message-ID: You'll have to give me more of the stuff after the etc. The error you're seeing is very unusual at high resolutions, but it should not be fatal. -tom From rokicki@CS.Stanford.EDU Fri Oct 18 21:00:53 2002 From: rokicki@CS.Stanford.EDU (Tomas G. Rokicki) Date: Fri, 18 Oct 2002 13:00:53 -0700 Subject: [tex-k] fonts for dvips Message-ID: Okay, here's a patch that should get you over the hump, temporarily. TeXK guys, should bad penpos be as nonfatal as badpos? What is it about this font/mode combination that is causing bad errors at this high resolution? The change is to `which mktexpk`: *** omktexpk Fri Oct 18 12:57:08 2002 --- mktexpk Fri Oct 18 12:58:17 2002 *************** *** 204,215 **** grep '^!' $NAME.log | sort >$$.errs 2>/dev/null grep '^! Strange path' $$.errs >$$.strange 2>/dev/null grep '^! bad pos.' $$.errs >$$.badpos 2>/dev/null ! cat $$.badpos $$.strange | sort > $$.errs_accept if cmp $$.errs $$.errs_accept >/dev/null 2>&1; then test -s $$.strange >/dev/null 2>&1 \ && echo "$progname: warning: \`$cmd' caused strange path errors." >&2 test -s $$.badpos >/dev/null 2>&1 \ && echo "$progname: warning: \`$cmd' caused bad pos errors." >&2 else echo "$progname: \`$cmd' failed." >&2 test -s $NAME.log && mv -f $NAME.log "$KPSE_DOT" --- 204,218 ---- grep '^!' $NAME.log | sort >$$.errs 2>/dev/null grep '^! Strange path' $$.errs >$$.strange 2>/dev/null grep '^! bad pos.' $$.errs >$$.badpos 2>/dev/null ! grep '^! bad penpos.' $$.errs >$$.badpenpos 2>/dev/null ! cat $$.badpenpos $$.badpos $$.strange | sort > $$.errs_accept if cmp $$.errs $$.errs_accept >/dev/null 2>&1; then test -s $$.strange >/dev/null 2>&1 \ && echo "$progname: warning: \`$cmd' caused strange path errors." >&2 test -s $$.badpos >/dev/null 2>&1 \ && echo "$progname: warning: \`$cmd' caused bad pos errors." >&2 + test -s $$.badpenpos >/dev/null 2>&1 \ + && echo "$progname: warning: \`$cmd' caused bad penpos errors." >&2 else echo "$progname: \`$cmd' failed." >&2 test -s $NAME.log && mv -f $NAME.log "$KPSE_DOT" From tim@maths.tcd.ie Sat Oct 19 22:51:09 2002 From: tim@maths.tcd.ie (Timothy Murphy) Date: Sat, 19 Oct 2002 22:51:09 +0100 Subject: [tex-k] fonts for dvips In-Reply-To: <3DB055DE.7050500@helix.nih.gov> References: <3DB055DE.7050500@helix.nih.gov> Message-ID: <20021019215109.GA72889@boole.maths.tcd.ie> On Fri, Oct 18, 2002 at 02:41:34PM -0400, Kevin Cahill wrote: > But when using the slides documentclass, > I can't get dvips to find the fonts it needs, > e.g., most subscripts and superscripts > were missing. This is no answer to your query, but I've always found the seminar class superior in almost every way to the slides class. =============================================== \documentclass[a4,12pt,semhelv,portrait]{seminar} \pagestyle{empty} \begin{document} \begin{slide*} ... \end{slide*} \end{document} =============================================== -- Timothy Murphy e-mail: tim@maths.tcd.ie tel: 086-233 6090 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From olaf@infovore.xs4all.nl Wed Oct 23 19:08:47 2002 From: olaf@infovore.xs4all.nl (Olaf Weber) Date: 23 Oct 2002 20:08:47 +0200 Subject: [tex-k] Re: [tex-live] Problem with klibtool and/or kpathsea install on Mac OS X In-Reply-To: <8F84048F-E684-11D6-85A6-0003930AD8A4@rna.nl> References: <8F84048F-E684-11D6-85A6-0003930AD8A4@rna.nl> Message-ID: <87lm4pni34.fsf@infovore.xs4all.nl> Gerben Wierda writes: > When klibtool installs libkpathsea in its libdir destination, the > timestamp on the library file gets newer than the ranlib table of > contents. As a result, a non-functional (linking against it will fail) > libkpathsea.a is installed. As a result, a 'make extras' on TeX Live > will always fail because this includes a kpathsea install and a > reconfigure of ttf2pk, which checks for kpathsea (this while procedure > is confused in itself, but let's not get into that) > The kpathsea makefile sets the RANLIB variable, but this seems not to > effect klibtool. > To be able to install TeX Live on systems where the ranlib table of > contents is checked against the file date, this needs to be > fixed. Could anyone please do this (it is beyond my capabilities) and > sync it with the TeX Live source.development repository? My TeX > distribution and support for TeX on Mac OS X is stalled as long as > this has not been fixed. Does the following change make a difference? Index: klibtool =================================================================== RCS file: /usr/local/cvsroot/texk/texk/klibtool,v retrieving revision 1.10 diff -u -r1.10 klibtool --- klibtool 14 Jan 1999 18:56:54 -0000 1.10 +++ klibtool 23 Oct 2002 18:05:09 -0000 @@ -321,6 +321,10 @@ fi ;; + *-*-darwin*) + STATIC_postinstall='$STATIC_ranlib $libdir/$lib_basename' + ;; + *) echo "$0: $host_type not explicitly supported, using defaults." >&2 ;; > Thanks, > G > _______________________________________________ > tex-live mailing list > tex-live@tug.org > http://tug.org/mailman/listinfo/tex-live -- Olaf Weber (This space left blank for technical reasons.) From Sherlock@rna.nl Wed Oct 23 13:40:07 2002 From: Sherlock@rna.nl (Gerben Wierda) Date: Wed, 23 Oct 2002 14:40:07 +0200 Subject: [tex-k] Problem with klibtool and/or kpathsea install on Mac OS X Message-ID: <8F84048F-E684-11D6-85A6-0003930AD8A4@rna.nl> When klibtool installs libkpathsea in its libdir destination, the timestamp on the library file gets newer than the ranlib table of contents. As a result, a non-functional (linking against it will fail) libkpathsea.a is installed. As a result, a 'make extras' on TeX Live will always fail because this includes a kpathsea install and a reconfigure of ttf2pk, which checks for kpathsea (this while procedure is confused in itself, but let's not get into that) The kpathsea makefile sets the RANLIB variable, but this seems not to effect klibtool. To be able to install TeX Live on systems where the ranlib table of contents is checked against the file date, this needs to be fixed. Could anyone please do this (it is beyond my capabilities) and sync it with the TeX Live source.development repository? My TeX distribution and support for TeX on Mac OS X is stalled as long as this has not been fixed. Thanks, G From Sherlock@rna.nl Thu Oct 24 13:28:51 2002 From: Sherlock@rna.nl (Gerben Wierda) Date: Thu, 24 Oct 2002 14:28:51 +0200 Subject: [tex-k] Problem with kpathsea (in latest web2c 7.3.9) Message-ID: <2764E8F8-E74C-11D6-85A6-0003930AD8A4@rna.nl> On my system there are currently two TeX installations: /usr/local/TeX and /usr/local/teTeX. They are more or less identical. Important for my problem is the fact that both have a top-level texmf.cnf, which starts like this: % Our directory setup as explained in $SELFAUTOPARENT/share/README.macosx % TEXMFMAIN contains the main TEXMF tree TEXMFMAIN = $SELFAUTOPARENT/share/texmf % TEXMFOS contains Mac OS specific defaults and additions TEXMFOS = $SELFAUTOPARENT/share/texmf.os % TEXMFLOCAL contains any local system TeXadmin overrides TEXMFLOCAL = $SELFAUTOPARENT/share/texmf.local % $VARTEXMF is where texconfig writes its local settings VARTEXMF = $TEXMFLOCAL % User texmf trees can be catered for like this... HOMETEXMF = $HOME/Library/texmf I have a small perl file whith the following commands: system( "which kpsewhich"); system( "kpsewhich --format='web2c files' updmap.cfg"); Here is my problem. When the path is (never mind the reason why this path is like it is): /usr/local/teTeX/share/texmf/../../bin/powerpc-apple-darwin-current:/ usr/bin:/bin:/usr/sbin:/sbin:/Network/Users/gerben I get /usr/local/teTeX/share/texmf/../../bin/powerpc-apple-darwin-current/ kpsewhich /usr/local/TeX/share/texmf/web2c/updmap.cfg The second line is wrong (in fact what /usr/local/TeX is, is the prefix with which kpathsea has been compiled, it is the compiled-in fallback). It should be: /usr/local/teTeX/bin/powerpc-apple-darwin-current/kpsewhich /usr/local/teTeX/share/texmf.local/web2c/updmap.cfg which is what I get when the path is /usr/local/teTeX/bin/powerpc-apple-darwin-current:/usr/bin:/bin:/usr/ sbin:/sbin:/Network/Users/gerben In other words: does SELFAUTO... not work when I have stuff like ../.. in my PATH? G From te@dbs.uni-hannover.de Thu Oct 24 13:51:04 2002 From: te@dbs.uni-hannover.de (Thomas Esser) Date: Thu, 24 Oct 2002 14:51:04 +0200 Subject: [tex-k] Re: [tex-live] Problem with kpathsea (in latest web2c 7.3.9) Message-ID: <200210241251.g9OCp4Gn029835@gauss.informatik.uni-hannover.de> > In other words: does SELFAUTO... not work when I have stuff like ../.. > in my PATH? Yes, that's broken. A shorter example: $ export PATH=/software/oss/Text/teTeX-1.0/share/texmf/../../bin/i686-pc-linux-gnu:$PATH $ kpsewhich -expand-var=\$SELFAUTOLOC /software/oss/Text/teTeX-1.0/share/bin/i686-pc-linux-gnu That "share" should not be there... Thomas From olaf@infovore.xs4all.nl Thu Oct 24 17:42:11 2002 From: olaf@infovore.xs4all.nl (Olaf Weber) Date: 24 Oct 2002 18:42:11 +0200 Subject: [tex-k] Re: [tex-live] Problem with kpathsea (in latest web2c 7.3.9) In-Reply-To: <200210241251.g9OCp4Gn029835@gauss.informatik.uni-hannover.de> References: <200210241251.g9OCp4Gn029835@gauss.informatik.uni-hannover.de> Message-ID: <87wuo7n5zw.fsf@infovore.xs4all.nl> Thomas Esser writes: >> In other words: does SELFAUTO... not work when I have stuff like ../.. >> in my PATH? > Yes, that's broken. > A shorter example: > $ export PATH=/software/oss/Text/teTeX-1.0/share/texmf/../../bin/i686-pc-linux-gnu:$PATH > $ kpsewhich -expand-var=\$SELFAUTOLOC > /software/oss/Text/teTeX-1.0/share/bin/i686-pc-linux-gnu > That "share" should not be there... How urgent is it to fix this -- assuming it is (reasonably) fixable. -- Olaf Weber (This space left blank for technical reasons.) From te@dbs.uni-hannover.de Thu Oct 24 20:30:22 2002 From: te@dbs.uni-hannover.de (Thomas Esser) Date: Thu, 24 Oct 2002 21:30:22 +0200 Subject: [tex-k] Re: [tex-live] Problem with kpathsea (in latest web2c 7.3.9) Message-ID: <200210241930.g9OJUMb3016364@gauss.informatik.uni-hannover.de> > How urgent is it to fix this -- assuming it is (reasonably) fixable. How about the following: --- progname.c-orig Thu Oct 24 21:14:23 2002 +++ progname.c Thu Oct 24 21:29:06 2002 @@ -304,7 +304,7 @@ if (IS_DIR_SEP (ret[last - 1])) { /* If we have `/../', that's the same as `/'. */ if (last > 1) { - ret[last] = 0; + ret[last - 1] = 0; } break; } Thomas From olaf@infovore.xs4all.nl Thu Oct 24 21:15:21 2002 From: olaf@infovore.xs4all.nl (Olaf Weber) Date: 24 Oct 2002 22:15:21 +0200 Subject: [tex-k] Re: Problem with kpathsea (in latest web2c 7.3.9) In-Reply-To: <200210241930.g9OJUMb3016364@gauss.informatik.uni-hannover.de> References: <200210241930.g9OJUMb3016364@gauss.informatik.uni-hannover.de> Message-ID: <877kg7mw4m.fsf@infovore.xs4all.nl> Thomas Esser writes: >> How urgent is it to fix this -- assuming it is (reasonably) fixable. > How about the following: > --- progname.c-orig Thu Oct 24 21:14:23 2002 > +++ progname.c Thu Oct 24 21:29:06 2002 > @@ -304,7 +304,7 @@ > if (IS_DIR_SEP (ret[last - 1])) { > /* If we have `/../', that's the same as `/'. */ > if (last > 1) { > - ret[last] = 0; > + ret[last - 1] = 0; > } > break; > } It improves matters, though there is still at least one case that the code doesn't handle correctly (example /foo/../bar). -- Olaf Weber (This space left blank for technical reasons.) From karl@freefriends.org Thu Oct 24 21:26:33 2002 From: karl@freefriends.org (Karl Berry) Date: Thu, 24 Oct 2002 16:26:33 -0400 Subject: [tex-k] [john@cs.york.ac.uk: web2c and detex(1)] Message-ID: <200210242026.g9OKQXK05886@f7.net> Date: Thu, 24 Oct 2002 15:34:45 +0100 (BST) From: john@cs.york.ac.uk To: Karl Berry cc: John Murdie Subject: web2c and detex(1) [...] I've long installed teTeX (based on web2c, of course) and sometimes Sebastian Rahtz' TeXLive (based on teTeX!). I also add a few things of local interest. I've been reminded by one of my users here that the detex command I install for use with e.g. `detex | wc' or `detex | ispell' (see http://www.cs.purdue.edu/homes/trinkle/detex/) is not built with the kpathsea library, and therefore can't do recursive-descent searches. To use detex, either all one's .tex files must be in the same directory, or one must extend TEXINPUTS. Is there any chance that you could get together with Daniel Trinkle (of Purdue CS) to extend detex with kpathsea, and then persuade Thomas Esser to include the result in teTeX? -- John A. Murdie Experimental Officer (Software) Department of Computer Science University of York England From sebastian.rahtz@computing-services.ox.ac.uk Thu Oct 24 23:43:36 2002 From: sebastian.rahtz@computing-services.ox.ac.uk (Sebastian Rahtz) Date: 24 Oct 2002 23:43:36 +0100 Subject: [tex-k] [john@cs.york.ac.uk: web2c and detex(1)] In-Reply-To: <200210242026.g9OKQXK05886@f7.net> References: <200210242026.g9OKQXK05886@f7.net> Message-ID: <1035499416.1115.24.camel@spqr-dell> surely ispell reads .tex files natively? I am vaguely surprised to still hear of people wanting detex in this day and age :-} I'd be happy to include detex in TeXLive, if someone does the work. Not just the kpathseaing of it (which is quite straightforward, from memory), but the suite of autoconf stuff as well. Can you get someone at York to do it? You seem to have some noisy TeX users there.... -- Sebastian Rahtz OUCS Information Manager 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From reinhard@kammer.uni-hannover.de Fri Oct 25 00:09:45 2002 From: reinhard@kammer.uni-hannover.de (Reinhard Kotucha) Date: Fri, 25 Oct 2002 01:09:45 +0200 Subject: [tex-k] format files Message-ID: <15800.32185.637169.675778@kammer.uni-hannover.de> Hi, I have a metapost file that begins with "%&latex". I could process this file until teTeX-beta-20021013 (web2c-7.3.8). Now I have to use the commandline option --tex=latex. "%&latex" is ignored and plain TeX is used. Is this desired? I know that sth. like "%&latex" has been problematic in the past, but it worked for me the last few months even though latex was in fact elatex. A year ago that caused trouble, as far as I remember. BTW, it doesn't work now even with latex=latex. Another problem is that "tex \&latex myfile" doesn't work properly. I think that this is a real bug because Knuth said that it should work. Is it difficult to scan the commandline for a \& and, unless there is no --progname option, set --progname= implicitly? Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-27060390 Marschnerstr. 25 D-30167 Hannover mailto:reinhard@kammer.uni-hannover.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ---------------------------------------------------------------------------- From te@dbs.uni-hannover.de Fri Oct 25 00:29:32 2002 From: te@dbs.uni-hannover.de (Thomas Esser) Date: Fri, 25 Oct 2002 01:29:32 +0200 Subject: [tex-k] Re: format files Message-ID: <200210242329.g9ONTW34001529@gauss.informatik.uni-hannover.de> > I have a metapost file that begins with "%&latex". I could process > this file until teTeX-beta-20021013 (web2c-7.3.8). Now I have to use > the commandline option --tex=latex. "%&latex" is ignored and plain > TeX is used. Is this desired? texmf.cnf now has "parse_first_line = f" to ensure that TeX behaves 100% correct in the default setup. There are several ways to solve your problem: - you can set "parse_first_line = t" in your texmf.cnf - you can add "parse_first_line.mpost = t" in your texmf.cnf - you can invoke mpost with parse_first_line=t in the environment ... > 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 Thomas From reinhard@kammer.uni-hannover.de Fri Oct 25 00:38:23 2002 From: reinhard@kammer.uni-hannover.de (Reinhard Kotucha) Date: Fri, 25 Oct 2002 01:38:23 +0200 Subject: [tex-k] Re: format files In-Reply-To: <200210242329.g9ONTW34001529@gauss.informatik.uni-hannover.de> References: <200210242329.g9ONTW34001529@gauss.informatik.uni-hannover.de> Message-ID: <15800.33903.741191.360072@kammer.uni-hannover.de> >>>>> "Thomas" == Thomas Esser 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. Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-27060390 Marschnerstr. 25 D-30167 Hannover mailto:reinhard@kammer.uni-hannover.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ---------------------------------------------------------------------------- From jwe@bevo.che.wisc.edu Fri Oct 25 04:30:20 2002 From: jwe@bevo.che.wisc.edu (John W. Eaton) Date: Thu, 24 Oct 2002 22:30:20 -0500 Subject: [tex-k] kpathsearch and Octave Message-ID: <15800.47820.758526.249801@segfault.bogus.domain> Hi, [I sent this message to the list several months back but never saw any response so perhaps it was not posted. --jwe] I've been using the kpathsearch library to handle path expansion and searching for Octave (www.octave.org) for a number of years now. Even though the library has many TeX-specific features, it has also been quite useful to me as a general-purpose tool for searching for files in large directory trees. >From the time I started using kpathsearch with Octave, I've been distributing the sources in the same tar file as the Octave sources. Recently, people have started asking why this is so, since the library is availble as a separate package on most Linux systems, and they would like to avoid the duplication. I agree, it would be nice to avoid multiple copies of the same library, but there are several reasons why Octave still uses its own version of the libarary. First, Octave is interactive, and users may change the value of the path used for searching for functions at any time, so I need to be able to clear the directory cache and start fresh. The patch below adds a new function for this purpose. Second, when a user changes the search path, Octave needs to expand it again, prepending, appending, or inserting the default path, and this needs to be done in a way that can avoid memory leaks. The way kpse_expand_default is currently written, it is impossible to know whether it is safe to free the expansion that it returns. The patch below causes kpse_expand_default to always return newly allocated storage, which the caller is then responsible for deleting. Finally, there seems to be no independent distribution of the library outside the teTeX sources (please correct me if I'm wrong about that). If there is no separate distribution of just the path searching library, why not? It already seems self-contained -- after downloading teTex, I'm able to run configure and make in just the kpathsea directory without having to configure and build all of teTeX. It would be very helpful for me to be able to tell people who are not using Linux and/or who must build from source to go get the kpathsearch library from some web or ftp site instead of telling them to download all of teTeX. Thanks, jwe -- www.octave.org | Unfortunately we were hopelessly optimistic in 1954 www.che.wisc.edu/~jwe | about the problems of debugging FORTRAN programs. | -- J. Backus 2002-04-12 John W. Eaton * kdefault.c (kpse_expand_default): Always return newly allocated storage. * elt-dirs.c (kpse_clear_dir_cache): New function. * pathsearch.h: Provide declaration. --- kdefault.c.orig Sat Nov 17 15:18:49 2001 +++ kdefault.c Fri Apr 12 19:20:08 2002 @@ -32,18 +32,18 @@ kpse_expand_default P2C(const_string, path, const_string, fallback) { unsigned path_length; - string expansion; + string expansion = NULL; /* The default path better not be null. */ assert (fallback); if (path == NULL) - expansion = (string) fallback; + expansion = xstrdup (fallback); /* Solitary or leading :? */ else if (IS_ENV_SEP (*path)) { - expansion = path[1] == 0 ? (string) fallback : concat (fallback, path); + expansion = path[1] == 0 ? xstrdup (fallback) : concat (fallback, path); } /* Sorry about the assignment in the middle of the expression, but @@ -59,10 +59,7 @@ { const_string loc; - /* What we'll return if we find none. */ - expansion = (string) path; - - for (loc = path; *loc && expansion == path; loc++) + for (loc = path; *loc; loc++) { if (IS_ENV_SEP (loc[0]) && IS_ENV_SEP (loc[1])) { /* We have a doubled colon. */ @@ -75,8 +72,16 @@ /* Copy in FALLBACK, and then the rest of PATH. */ strcat (expansion, fallback); strcat (expansion, loc + 1); + + break; } } + + if (! expansion) + { + /* Doubled colon not found. */ + expansion = xstrdup (path); + } } return expansion; --- elt-dirs.c.orig Mon Oct 22 16:31:30 2001 +++ elt-dirs.c Fri Apr 12 18:59:03 2002 @@ -69,6 +69,35 @@ static cache_entry *the_cache = NULL; static unsigned cache_length = 0; +/* Clear the directory cache. */ +void +kpse_clear_dir_cache P1H(void) +{ + while (cache_length > 0) + { + str_llist_type elt = *the_cache[--cache_length].value; + + while (elt) + { + str_llist_type next = STR_LLIST_NEXT (*elt); + + string s = STR_LLIST (*elt); + + if (s) + free (s); + + free (elt); + + elt = next; + } + } + + if (the_cache) + free (the_cache); + + the_cache = NULL; +} + /* Associate KEY with VALUE. We implement the cache as a simple linear list, since it's unlikely to ever be more than a dozen or so elements --- pathsearch.h.orig Tue Oct 30 03:53:30 2001 +++ pathsearch.h Fri Apr 12 18:57:22 2002 @@ -80,5 +80,8 @@ extern KPSEDLL string *kpse_all_path_search P2H(const_string path, const_string name); +/* Clear the directory cache. */ +extern void kpse_clear_dir_cache P1H(void); + #endif /* not KPATHSEA_PATHSEARCH_H */ From john@cs.york.ac.uk Fri Oct 25 09:48:42 2002 From: john@cs.york.ac.uk (john@cs.york.ac.uk) Date: Fri, 25 Oct 2002 09:48:42 +0100 (BST) Subject: [tex-k] [john@cs.york.ac.uk: web2c and detex(1)] In-Reply-To: <1035499416.1115.24.camel@spqr-dell> Message-ID: On 24 Oct, Sebastian Rahtz wrote: > surely ispell reads .tex files natively? I am vaguely surprised > to still hear of people wanting detex in this day and age :-} > > I'd be happy to include detex in TeXLive, if someone > does the work. Not just the kpathseaing of it (which is > quite straightforward, from memory), but the suite of > autoconf stuff as well. Can you get someone at York to do it? > You seem to have some noisy TeX users there.... Yes, we have ispell - but there are other uses for detex than to prepare a TeX souce file for spell checking. I get asked about grammar checkers these days - I don't know of one which reads TeX source directly. Similarly word counting. Perhaps emacs offers all these facilities to its users - but not everyone here uses emacs. Besides, `detex |' is very much the Unix tools approach to things - I despair of the day when all programs are integrated monstrosities that I can't adapt to my own needs. And, yes, I know - if I want an autoconf-ed, kpathsea-ed, detex I should do it myself. It would be an interesting exercise, I admit. -- John A. Murdie Experimental Officer (Software) Department of Computer Science University of York England From sebastian.rahtz@computing-services.oxford.ac.uk Fri Oct 25 11:42:37 2002 From: sebastian.rahtz@computing-services.oxford.ac.uk (Sebastian Rahtz) Date: 25 Oct 2002 11:42:37 +0100 Subject: [tex-k] [john@cs.york.ac.uk: web2c and detex(1)] In-Reply-To: References: Message-ID: <1035542557.17927.22.camel@spqr.oucs.ox.ac.uk> On Fri, 2002-10-25 at 09:48, john@cs.york.ac.uk wrote: > Perhaps emacs offers all these facilities to > its users - but not everyone here uses emacs. gasp. can this be true???? > Besides, `detex |' is very > much the Unix tools approach to things sure, thats fine. but in that case, switch to XML! its a far far better language to work in the Unix paradigm. -- Sebastian Rahtz OUCS Information Manager 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From olaf@infovore.xs4all.nl Fri Oct 25 19:37:54 2002 From: olaf@infovore.xs4all.nl (Olaf Weber) Date: 25 Oct 2002 20:37:54 +0200 Subject: [tex-k] kpathsearch and Octave In-Reply-To: <15800.47820.758526.249801@segfault.bogus.domain> References: <15800.47820.758526.249801@segfault.bogus.domain> Message-ID: <873cqul5z1.fsf@infovore.xs4all.nl> John W Eaton writes: > First, Octave is interactive, and users may change the value of the > path used for searching for functions at any time, so I need to be > able to clear the directory cache and start fresh. The patch below > adds a new function for this purpose. Do you really need to clear the directory cache for this? I _think_ just picking a different search path should already work, but I may be completely off. (Unless the resulting "memory leak" is your concern.) > Second, when a user changes the search path, Octave needs to expand it > again, prepending, appending, or inserting the default path, and this > needs to be done in a way that can avoid memory leaks. The way > kpse_expand_default is currently written, it is impossible to know > whether it is safe to free the expansion that it returns. The patch > below causes kpse_expand_default to always return newly allocated > storage, which the caller is then responsible for deleting. That sounds reasonable. > Finally, there seems to be no independent distribution of the library > outside the teTeX sources (please correct me if I'm wrong about that). Outside of the web2c sources, to be precise. I do recognize this as a problem, but properly disentangling libkpathsea from web2c will take some effort. In particular, there are parts of the build system that I'm looking at and would like to change/clean up. I am also not happy with the library interface when looked at as a shared library interface, and I'm profoundly unhappy with the headers that have to be installed. At present, my first priority is to help Thomas get the next teTeX out. More ambitious stuff comes after that. -- Olaf Weber (This space left blank for technical reasons.) From olaf@infovore.xs4all.nl Fri Oct 25 20:26:47 2002 From: olaf@infovore.xs4all.nl (Olaf Weber) Date: 25 Oct 2002 21:26:47 +0200 Subject: [tex-k] Re: format files In-Reply-To: <15800.33903.741191.360072@kammer.uni-hannover.de> References: <200210242329.g9ONTW34001529@gauss.informatik.uni-hannover.de> <15800.33903.741191.360072@kammer.uni-hannover.de> Message-ID: <87wuo6jp54.fsf_-_@infovore.xs4all.nl> Reinhard Kotucha writes: >>>>>> "Thomas" == Thomas Esser 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 -0000 1.50 +++ tex.ch 25 Oct 2002 19:18:55 -0000 @@ -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.) From jwe@bevo.che.wisc.edu Fri Oct 25 20:28:26 2002 From: jwe@bevo.che.wisc.edu (John W. Eaton) Date: Fri, 25 Oct 2002 14:28:26 -0500 Subject: [tex-k] kpathsearch and Octave In-Reply-To: <873cqul5z1.fsf@infovore.xs4all.nl> References: <15800.47820.758526.249801@segfault.bogus.domain> <873cqul5z1.fsf@infovore.xs4all.nl> Message-ID: <15801.39770.530799.120080@segfault.bogus.domain> On 25-Oct-2002, Olaf Weber wrote: | John W Eaton writes: | | > First, Octave is interactive, and users may change the value of the | > path used for searching for functions at any time, so I need to be | > able to clear the directory cache and start fresh. The patch below | > adds a new function for this purpose. | | Do you really need to clear the directory cache for this? I _think_ | just picking a different search path should already work, but I may be | completely off. (Unless the resulting "memory leak" is your concern.) I don't see any code that removes directories from the cache. Suppose there are two directories /foo and /bar that contain the same file X. Then if the user starts out with /foo in the path and looks up X, they will find /foo/X, and that's fine. Now they change the path to /bar, and they should find /bar/X. Is that what will happen? What about if /foo/X exists and the user simply removes /foo from the path? Does it remain in the cache, so it will still be found, even though the user has removed /foo from the path? | Outside of the web2c sources, to be precise. I do recognize this as a | problem, but properly disentangling libkpathsea from web2c will take | some effort. In particular, there are parts of the build system that | I'm looking at and would like to change/clean up. I am also not happy | with the library interface when looked at as a shared library | interface, and I'm profoundly unhappy with the headers that have to be | installed. OK. I think that this library could have a lot of uses beyond TeX and web2c. It would be nice to extract the basic path searching stuff into a base library with a nice clean interface that could be used by lots of different projects, and then build the TeX-specific stuff on top of that. I'd be willing to help (as much as I can, given my limited time) make that happen if it is something that you agree would be useful. Thanks, jwe From olaf@infovore.xs4all.nl Fri Oct 25 20:44:12 2002 From: olaf@infovore.xs4all.nl (Olaf Weber) Date: 25 Oct 2002 21:44:12 +0200 Subject: [tex-k] Re: kpathsearch and Octave In-Reply-To: <15801.39770.530799.120080@segfault.bogus.domain> References: <15800.47820.758526.249801@segfault.bogus.domain> <873cqul5z1.fsf@infovore.xs4all.nl> <15801.39770.530799.120080@segfault.bogus.domain> Message-ID: <87r8eejoc3.fsf_-_@infovore.xs4all.nl> John W Eaton writes: > On 25-Oct-2002, Olaf Weber wrote: > | John W Eaton writes: > | > | > First, Octave is interactive, and users may change the value of the > | > path used for searching for functions at any time, so I need to be > | > able to clear the directory cache and start fresh. The patch below > | > adds a new function for this purpose. > | > | Do you really need to clear the directory cache for this? I _think_ > | just picking a different search path should already work, but I may be > | completely off. (Unless the resulting "memory leak" is your concern.) > I don't see any code that removes directories from the cache. That's because there is no such code at present. > Suppose there are two directories /foo and /bar that contain the same > file X. Then if the user starts out with /foo in the path and looks > up X, they will find /foo/X, and that's fine. Now they change the > path to /bar, and they should find /bar/X. Is that what will happen? Yes -- when you look for 'X', entries for /foo/X and /bar/X are both found in the hash table, and then matched to the given path. Only if it is actually on the search path will the entry be returned. The code relies on this in several ways -- for example, a few duplicate entries tend to be present in the default texmf tree, and therefore also in the database that is built from the ls-R. We use different search paths to ensure that we find one entry instead of another. > What about if /foo/X exists and the user simply removes /foo from the > path? Does it remain in the cache, so it will still be found, even > though the user has removed /foo from the path? The /foo/X entry is still in the database, but if someone searches for X along path that doesn't include /foo, it will not be found. > | Outside of the web2c sources, to be precise. I do recognize this as a > | problem, but properly disentangling libkpathsea from web2c will take > | some effort. In particular, there are parts of the build system that > | I'm looking at and would like to change/clean up. I am also not happy > | with the library interface when looked at as a shared library > | interface, and I'm profoundly unhappy with the headers that have to be > | installed. > OK. > I think that this library could have a lot of uses beyond TeX and > web2c. It would be nice to extract the basic path searching stuff > into a base library with a nice clean interface that could be used by > lots of different projects, and then build the TeX-specific stuff on > top of that. I'd be willing to help (as much as I can, given my > limited time) make that happen if it is something that you agree would > be useful. I may have questions for you later. By the way, this reminder of yours did come at a good moment, as we haven't quite frozen the code for the next web2c yet. -- Olaf Weber (This space left blank for technical reasons.) From te@dbs.uni-hannover.de Fri Oct 25 20:53:13 2002 From: te@dbs.uni-hannover.de (Thomas Esser) Date: Fri, 25 Oct 2002 21:53:13 +0200 Subject: [tex-k] Re: format files Message-ID: <200210251953.g9PJrDVR010868@gauss.informatik.uni-hannover.de> Olaf Weber wrote: > 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 does change the existing behaviour and users might already depend on it, e.g. LaTeX users who use the mylatex package: latex \&mylatex foo There is no TEXINPUTS.mylatex and users will get the default TEXINPUTS setting instead of TEXINPUTS.latex. > Thomas, WDYT? Before you do that change, get some other opinions. Thomas From jwe@bevo.che.wisc.edu Fri Oct 25 21:12:52 2002 From: jwe@bevo.che.wisc.edu (John W. Eaton) Date: Fri, 25 Oct 2002 15:12:52 -0500 Subject: [tex-k] Re: kpathsearch and Octave In-Reply-To: <87r8eejoc3.fsf_-_@infovore.xs4all.nl> References: <15800.47820.758526.249801@segfault.bogus.domain> <873cqul5z1.fsf@infovore.xs4all.nl> <15801.39770.530799.120080@segfault.bogus.domain> <87r8eejoc3.fsf_-_@infovore.xs4all.nl> Message-ID: <15801.42436.178754.595058@segfault.bogus.domain> On 25-Oct-2002, Olaf Weber wrote: | That's because there is no such code at present. | | > Suppose there are two directories /foo and /bar that contain the same | > file X. Then if the user starts out with /foo in the path and looks | > up X, they will find /foo/X, and that's fine. Now they change the | > path to /bar, and they should find /bar/X. Is that what will happen? | | Yes -- when you look for 'X', entries for /foo/X and /bar/X are both | found in the hash table, and then matched to the given path. Only if | it is actually on the search path will the entry be returned. The | code relies on this in several ways -- for example, a few duplicate | entries tend to be present in the default texmf tree, and therefore | also in the database that is built from the ls-R. We use different | search paths to ensure that we find one entry instead of another. | | > What about if /foo/X exists and the user simply removes /foo from the | > path? Does it remain in the cache, so it will still be found, even | > though the user has removed /foo from the path? | | The /foo/X entry is still in the database, but if someone searches for | X along path that doesn't include /foo, it will not be found. OK. I removed the call to my kpse_clear_dir_cache function from Octave and it still behaves correctly, so I don't think it is needed. Now, I wonder why I ever thought that it would be?! | By the way, this reminder of yours did come at a good moment, as we | haven't quite frozen the code for the next web2c yet. OK. If the memory leak fix goes in before the next release, then I think we (Octave) can start using unmodified sources for the libarary soon. Thanks, jwe From olaf@infovore.xs4all.nl Fri Oct 25 21:15:42 2002 From: olaf@infovore.xs4all.nl (Olaf Weber) Date: 25 Oct 2002 22:15:42 +0200 Subject: [tex-k] Re: format files In-Reply-To: <200210251953.g9PJrDVR010868@gauss.informatik.uni-hannover.de> References: <200210251953.g9PJrDVR010868@gauss.informatik.uni-hannover.de> Message-ID: <87n0p2jmvl.fsf@infovore.xs4all.nl> Thomas Esser writes: > Olaf Weber wrote: >> 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 does change the existing behaviour and users might already depend > on it, e.g. LaTeX users who use the mylatex package: > latex \&mylatex foo > There is no TEXINPUTS.mylatex and users will get the default TEXINPUTS > setting instead of TEXINPUTS.latex. Right. You'd have to somehow make the TEXINPUTS.latex path the fallback instead of the "normal" TEXINPUTS. However, are 'tex \&mylatex foo' and 'latex \&mylatex foo' supposed to have identical results -- it seems to me you're in for a surprise there anyway. >> Thomas, WDYT? > Before you do that change, get some other opinions. More opinions? Please? > Thomas -- Olaf Weber (This space left blank for technical reasons.) From olaf@infovore.xs4all.nl Fri Oct 25 21:21:33 2002 From: olaf@infovore.xs4all.nl (Olaf Weber) Date: 25 Oct 2002 22:21:33 +0200 Subject: [tex-k] Re: kpathsearch and Octave In-Reply-To: <15801.42436.178754.595058@segfault.bogus.domain> References: <15800.47820.758526.249801@segfault.bogus.domain> <873cqul5z1.fsf@infovore.xs4all.nl> <15801.39770.530799.120080@segfault.bogus.domain> <87r8eejoc3.fsf_-_@infovore.xs4all.nl> <200209121717.g8CHHRL1030878@gauss.informatik.uni-hannover.de> <15801.42436.178754.595058@segfault.bogus.domain> Message-ID: <87hefajmlu.fsf@infovore.xs4all.nl> John W Eaton writes: > | By the way, this reminder of yours did come at a good moment, as we > | haven't quite frozen the code for the next web2c yet. > OK. If the memory leak fix goes in before the next release, then I > think we (Octave) can start using unmodified sources for the libarary > soon. I've implemented a variant of your change which is a closer match to my way of "thinking C". -- Olaf Weber (This space left blank for technical reasons.) From karl@freefriends.org Fri Oct 25 22:00:43 2002 From: karl@freefriends.org (Karl Berry) Date: Fri, 25 Oct 2002 17:00:43 -0400 Subject: [tex-k] kpathsearch and Octave Message-ID: <200210252100.g9PL0hE13228@f7.net> It would be nice to extract the basic path searching stuff into a base library with a nice clean interface that could be used by lots of different projects This sounds great in theory and was what I started out to do when I wrote kpathsea. The problem that arose in practice was the number of features needed for texmf that would never ever arise for any other program; disentangling them in the source proved very difficult. I did my best to keep the generic source files separate texmf-specific ones but there was some inevitable (as far as I could see) leakage. After I realized this, I pretty much gave up on the idea of a separate kpathsea distribution. I completely agree with Olaf that if such a thing is done, the interface and the header files would need a lot of attention. Right now all the configuration stuff has to get installed. It would probably be best to use libtool, and start by looking at some other successful library -- perhaps what gettext does. Unfortunately good library installation in general remains very much a thorn in the side of programmers and sysadmins ... Good luck :). k From reinhard@kammer.uni-hannover.de Sat Oct 26 02:23:23 2002 From: reinhard@kammer.uni-hannover.de (Reinhard Kotucha) Date: Sat, 26 Oct 2002 03:23:23 +0200 Subject: [tex-k] parse_first_line Message-ID: <15801.61067.857881.796344@kammer.uni-hannover.de> Hi, I've put the line "parse_first_line = t" in texmf.cnf. But compiling a MetaPost file begining with "%&latex" I get: This is TeXk, Version 3.14159 (Web2C 7.3.9) (format=tex 2002.10.25) 26 OCT 2002 03:13 \write18 enabled. %&-line parsing enabled. **mpx13563.tex (./mpx13563.tex ! Undefined control sequence. l.1 \documentclass {article} Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-27060390 Marschnerstr. 25 D-30167 Hannover mailto:reinhard@kammer.uni-hannover.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ---------------------------------------------------------------------------- From edd@debian.org Sat Oct 26 00:18:17 2002 From: edd@debian.org (Dirk Eddelbuettel) Date: Fri, 25 Oct 2002 18:18:17 -0500 Subject: [tex-k] kpathsearch and Octave In-Reply-To: <200210252100.g9PL0hE13228@f7.net> References: <200210252100.g9PL0hE13228@f7.net> Message-ID: <20021025231816.GA32013@sonny.eddelbuettel.com> On Fri, Oct 25, 2002 at 05:00:43PM -0400, Karl Berry wrote: > It would be nice to extract the basic path searching stuff into a > base library with a nice clean interface that could be used by lots > of different projects > > This sounds great in theory and was what I started out to do when I > wrote kpathsea. The problem that arose in practice was the number of Also in at least some practice: Debian has long had a separate libkpathsea library, it is thus easy to see which other packages depend on it: edd@chibud:~> apt-cache showpkg libkpathsea3 Package: libkpathsea3 Versions: 1.0.7+20011202-8(/var/lib/apt/lists/ftp.us.debian.org_debian_dists_testing_main_binary-i386_Packages)(/var/lib/apt/lists/ftp.us.debian.org_debian_dists_unstable_main_binary-i386_Packages)(/var/lib/dpkg/status) Reverse Depends: dvipdfm-cjk,libkpathsea3 1.0.7+20011202-8 lilypond,libkpathsea3 1.0.7+20011202-8 libkpathsea-perl,libkpathsea3 1.0.7+20011202-7 dvipdfm,libkpathsea3 1.0.7+20011202-7 xgdvi,libkpathsea3 1.0.7+20011202-6 xdvik-ja,libkpathsea3 1.0.7+20001218-5 vflib3-bin,libkpathsea3 1.0.7+20011202-7 vflib3,libkpathsea3 1.0.7+20011202-7 ultrapoint,libkpathsea3 1.0.7+20011202-2 tkdvi,libkpathsea3 1.0.7+20001218-3 tex4ht,libkpathsea3 1.0.7+20011202-5 tex-guy,libkpathsea3 1.0.7+20011202-6 tetex-bin,libkpathsea3 1.0.7+20011202-1 spawx11,libkpathsea3 1.0.7+20011202-6 spawg,libkpathsea3 1.0.7+20011202-6 ptex-bin,libkpathsea3 1.0.7+20011202-7 multex-bin,libkpathsea3 1.0.7+20011202-5.1 lilypond,libkpathsea3 1.0.7+20011202-3.1 libkpathsea-perl,libkpathsea3 1.0.7+20011202-3 libkpathsea-dev,libkpathsea3 1.0.7+20011202-8 jtex-bin,libkpathsea3 1.0.7+20011202-5.1 jmpost,libkpathsea3 1.0.7+20011202-7 jbibtex-bin,libkpathsea3 1.0.7+20011202-7 freetype1-tools,libkpathsea3 1.0.7+20001218-6 dvisvga,libkpathsea3 1.0.7+20011202-3 dvipsk-ja,libkpathsea3 1.0.7+20011202-7 dvipdfm-cjk,libkpathsea3 1.0.7+20011202-7 dvipdfm,libkpathsea3 1.0.7+20000807-6 dvilx,libkpathsea3 1.0.7+20011202-3 dvilib2,libkpathsea3 1.0.7+20011202-6 dvifb,libkpathsea3 1.0.7+20011202-3 dvi2ps,libkpathsea3 1.0.7+20011202-2 dvi2dvi,libkpathsea3 1.0.7+20011202-3.1 cweb,libkpathsea3 1.0.7+20011202-5.1 ctie,libkpathsea3 1.0.7+20011202-3 catdvi,libkpathsea3 1.0.7+20011202-5 Dependencies: 1.0.7+20011202-8 - libc6 (2 2.2.5-13) tetex-lib (0 (null)) tetex-lib (0 (null)) Provides: 1.0.7+20011202-8 - tetex-lib Reverse Provides: Surely a good majority of these come from tetex, web2c and friends, but clearly not all. Imagine how much use you'd see once the interface is cleaned up and documented as Olaf outlined. Dirk -- Good judgement comes from experience; experience comes from bad judgement. -- Fred Brooks From olaf@infovore.xs4all.nl Sat Oct 26 10:03:47 2002 From: olaf@infovore.xs4all.nl (Olaf Weber) Date: 26 Oct 2002 11:03:47 +0200 Subject: [tex-k] parse_first_line In-Reply-To: <15801.61067.857881.796344@kammer.uni-hannover.de> References: <15801.61067.857881.796344@kammer.uni-hannover.de> Message-ID: <878z0lk1vw.fsf@infovore.xs4all.nl> Reinhard Kotucha writes: > Hi, > I've put the line "parse_first_line = t" in texmf.cnf. > But compiling a MetaPost file begining with "%&latex" I get: > This is TeXk, Version 3.14159 (Web2C 7.3.9) (format=tex 2002.10.25) 26 OCT 2002 > 03:13 > \write18 enabled. > %&-line parsing enabled. > **mpx13563.tex > (./mpx13563.tex > ! Undefined control sequence. > l.1 \documentclass > {article} What does the accompanying mpxerr.tex look like? Remember that the '%&latex' line should be the first line of the first verbatim section. Not the first line of the mp file. -- Olaf Weber (This space left blank for technical reasons.) From reinhard@kammer.uni-hannover.de Sat Oct 26 22:15:37 2002 From: reinhard@kammer.uni-hannover.de (Reinhard Kotucha) Date: Sat, 26 Oct 2002 23:15:37 +0200 Subject: [tex-k] parse_first_line In-Reply-To: <878z0lk1vw.fsf@infovore.xs4all.nl> References: <15801.61067.857881.796344@kammer.uni-hannover.de> <878z0lk1vw.fsf@infovore.xs4all.nl> Message-ID: <15803.1529.41096.200395@kammer.uni-hannover.de> >>>>> "Olaf" == Olaf Weber writes: > Remember that the '%&latex' line should be the first line of the > first verbatim section. Not the first line of the mp file. Yes, this was the problem. I accidently moved the line upwards last night, sorry. Thank you for the hint, to Julian as well. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-27060390 Marschnerstr. 25 D-30167 Hannover mailto:reinhard@kammer.uni-hannover.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ---------------------------------------------------------------------------- From acrook@ctr-sgi1.stanford.edu Tue Oct 29 00:53:10 2002 From: acrook@ctr-sgi1.stanford.edu (Andrew Crook) Date: Mon, 28 Oct 2002 16:53:10 -0800 Subject: [tex-k] Dvips 5.86 problem with jpeg Message-ID: <002201c27ee5$9f81f520$2b136381@griffon> This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C27EA2.7F62AC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I am new to the list, and I have a problem including jpeg and tiff files = in the final postscript output. I am running a newly installed version = of Redhat 8 and dvips(k) 5.86 and jpeg2ps 1.9. The latex file is as = follows: \documentclass[12pt]{report} \usepackage{graphicx} \begin{document} \DeclareGraphicsRule{.jpg}{eps}{.jpg.bb}{`jpeg2ps -r0 #1} \begin{figure}=20 \centering \includegraphics[width=3D\textwidth]{pics/test.jpg} \end{figure} \end{document} It compiles fine and I can issue the command jpeg2ps -r0 pics/test.jpg = and it works fine. However dvips gives me the message: dvips: failure to execute jpeg2ps -r0 pics/test.jpg; continuing. The = result is also the same if I try tiff2ps. It is as if dvips does not = know jpeg2ps is there. I put jpeg2ps in /usr/bin. Should it go in = another directory so that dvips can find it? I have seen a similar = problem in the archives but I could not find the solution if any that = was posted. Your help is greatly appreciated Andrew ------=_NextPart_000_001F_01C27EA2.7F62AC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
I am new to the list, and I have a = problem=20 including jpeg and tiff files in the final postscript output. I am = running a=20 newly installed version of Redhat 8 and dvips(k) 5.86 and jpeg2ps 1.9. = The latex=20 file is as follows:
 
\documentclass[12pt]{report}
\usepackage{graphicx}
\begin{document}
\DeclareGraphicsRule{.jpg}{eps}{.jpg.bb}{`jpeg2ps -r0=20 #1}
\begin{figure}
\centering
\includegraphics[width=3D\textwidth]{pics/test.jpg}
\end{figure}
\end{document}
 
It compiles fine and I can issue the command = jpeg2ps -r0=20 pics/test.jpg and it works fine. However dvips gives me the=20 message:
dvips: failure to execute jpeg2ps -r0 = pics/test.jpg;=20 continuing. The result is also the same if I try tiff2ps. It is as if = dvips does=20 not know jpeg2ps is there. I put jpeg2ps in /usr/bin. Should it go in = another=20 directory so that dvips can find it? I have seen a similar problem in = the=20 archives but I could not find the solution if any that was = posted.
 
Your help is greatly appreciated
Andrew
 
------=_NextPart_000_001F_01C27EA2.7F62AC50-- From rokicki@CS.Stanford.EDU Tue Oct 29 16:53:18 2002 From: rokicki@CS.Stanford.EDU (Tomas G. Rokicki) Date: Tue, 29 Oct 2002 08:53:18 -0800 Subject: [tex-k] Dvips 5.86 problem with jpeg Message-ID: First, try it with -R0 and see if that solves it. RedHat made some changes (I need to take a look at them) that, I believe, close some security holes by preventing such execution, but I think -R0 will say, I know what I'm doing, let it happen. I've got to spend some time working on this. By the way, you might want to go ahead and use something like \DeclareGraphicsRule{.jpg}{eps}{.jpg.bb}{`/usr/bin/jpeg2ps -r0 #1} because it will both make it certain that it's picking up the correct binary, and eliminate the path question you have. RedHat is mostly concerned about dvips as a print spooler, and I agree with their concerns, but if you invoke it from the command line, one would think it would be a little more flexible. -tom