From stefano@sif.it Thu Feb 1 10:10:59 2001 From: stefano@sif.it (Stefano Frabetti) Date: Thu, 01 Feb 2001 11:10:59 +0100 Subject: [tex-k] dvips premature end of file in binary section Message-ID: <200102011010.f11AAx608426@kaima.sif.it> Hello; we've had trouble with the adobe-photoshop--eps inclusion problem. I don't know if it is a solved problem (apart from -K): I didn't get much help from web searches. Anyway, we understand it (and solve it) this way: 1. it's a problem with %%BeginBinary/CRLF: photoshop saves the binary length counting 2 bytes per end-of-line; somewhere (perhaps while moving files between shared resources) the EOL are converted from dos to unix, CRLF->LF. Of course, the %%BeginBinary comment is not updated to reflect the change and dvips finds that he lacks bytes. 2. as a workaround, we now convert the eols back to dos in the figures that crash, so that the binary length in the comment matches the actual length. We didn't want to use -K and this works pretty well ---as a side note, I personally find it awkward to count 2 bytes for eol in a *text* file, even for an ms-dos application. Regards, Stefano Frabetti ps. i'm not subscribed, please keep the cc: if you want me to read. Ciao. From rokicki@CS.Stanford.EDU Thu Feb 1 18:03:00 2001 From: rokicki@CS.Stanford.EDU (Tomas G. Rokicki) Date: Thu, 1 Feb 2001 10:03:00 -0800 (PST) Subject: [tex-k] dvips premature end of file in binary section Message-ID: <200102011803.KAA05290@Xenon.Stanford.EDU> I'd say the problem is whatever is converting CRLF->LF. Are you moving the file across machines in text mode? I mean, by definition a file with %%BeginBinary is binary, not text . . . -tom From marina@nemas.com Thu Feb 1 23:19:07 2001 From: marina@nemas.com (Marina) Date: Fri, 2 Feb 2001 10:19:07 +1100 Subject: [tex-k] unsubscribe Message-ID: <001301c08ca5$605687f0$697821cb@ncom> This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C08D01.938FEA60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C08D01.9392F7A0" ------=_NextPart_001_0010_01C08D01.9392F7A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello! Can I ask you to remove me from mailing list? Thanks, Marina ------=_NextPart_001_0010_01C08D01.9392F7A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello!

Can I ask you to remove = me from=20 mailing list?

Thanks,

Marina

------=_NextPart_001_0010_01C08D01.9392F7A0-- ------=_NextPart_000_000F_01C08D01.938FEA60 Content-Type: text/x-vcard; name="Marina.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Marina.vcf" BEGIN:VCARD VERSION:2.1 N:;Marina FN:Marina EMAIL;PREF;INTERNET:marina@nemas.com REV:20010201T231907Z END:VCARD ------=_NextPart_000_000F_01C08D01.938FEA60-- From tjk@ams.org Fri Feb 2 00:17:22 2001 From: tjk@ams.org (Tom Kacvinsky) Date: Thu, 1 Feb 2001 19:17:22 -0500 (EST) Subject: [tex-k] Re: dvips premature end of file in binary section In-Reply-To: <200102011803.KAA05290@Xenon.Stanford.EDU> Message-ID: Hi Tom, On Thu, 1 Feb 2001, Tomas G. Rokicki wrote: > I'd say the problem is whatever is converting CRLF->LF. Are you > moving the file across machines in text mode? I mean, by definition > a file with %%BeginBinary is binary, not text . . . > Unfortunately, this is not the case. Photoshop ASCII EPS files (i.e., the data following the image operator is in hexadecimal rather than binary) have the image data (along with the image operator) wrapped in a %%BeginBinary and %%EndBinary pair. Using -K is not always feasible option because sometimes EPS files use %% in the data stream. Illustrator, for example, writes out PS code that will dynamically strip out certain PS code (for instance, non-imaging things like patterns, palettes, etc... that Illustrator uses when the file is opened, but is never used in imaging). And this code stripping is keyed off of lines that start with `%' ! From this, one can see that problems will arise if this code stripping is ever based on %%. I have never seen an example of this, but I am sure something can be cooked up with ASCII85 encoded data, etc... Tom From rokicki@CS.Stanford.EDU Fri Feb 2 01:42:31 2001 From: rokicki@CS.Stanford.EDU (Tomas G. Rokicki) Date: Thu, 1 Feb 2001 17:42:31 -0800 (PST) Subject: [tex-k] Re: dvips premature end of file in binary section Message-ID: <200102020142.RAA04089@Xenon.Stanford.EDU> Well, what I'm saying is, if the DSC comment is %%BeginBinary, we have to respect the binary nature of the file and skip so many characters without interpretation. So the file must not be subjected to any sort of line terminator modification. This in turn means that the file must be treated as binary, even if every character in it is within seven-bit ASCII. -K is a bad idea in general, so it is turned off by default and not recommended. So my position remains; if a file contains %%BeginBinary, it must be treated with all the respect due a binary file, just like a .jpg or .gif, and not transferred in ASCII mode or otherwise munged, just so that the byte counts remain consistent. But perhaps I'm misunderstanding your reply or the original problem. -tom From tjk@ams.org Fri Feb 2 04:06:16 2001 From: tjk@ams.org (Tom Kacvinsky) Date: Thu, 1 Feb 2001 23:06:16 -0500 (EST) Subject: [tex-k] Re: dvips premature end of file in binary section In-Reply-To: <200102020142.RAA04089@Xenon.Stanford.EDU> Message-ID: I think that you are right on, Tom. The problem is that the EPS files usually see more action than just inclusion into a "master" PS file via dvips. The problem is that the EPS file is usally included via, say, \includegraphics, and then latex (TeX) has to parse the EPS file for the BBox (not everyone uses the .bb file option). So, if a Mac EPS file gets transferred in binary mode to a UNIX/wintel box, TeX will think the EPS file is one LONG line because the EOLs are not UNIX/DOS EOLs. Oops! Tom On Thu, 1 Feb 2001, Tomas G. Rokicki wrote: > Well, what I'm saying is, if the DSC comment is %%BeginBinary, we > have to respect the binary nature of the file and skip so many > characters without interpretation. So the file must not be subjected > to any sort of line terminator modification. This in turn means that > the file must be treated as binary, even if every character in it is > within seven-bit ASCII. > > -K is a bad idea in general, so it is turned off by default and not > recommended. > > So my position remains; if a file contains %%BeginBinary, it must be > treated with all the respect due a binary file, just like a .jpg or > .gif, and not transferred in ASCII mode or otherwise munged, just > so that the byte counts remain consistent. > > But perhaps I'm misunderstanding your reply or the original problem. > > -tom > From rokicki@CS.Stanford.EDU Fri Feb 2 06:07:59 2001 From: rokicki@CS.Stanford.EDU (Tomas G. Rokicki) Date: Thu, 1 Feb 2001 22:07:59 -0800 (PST) Subject: [tex-k] Re: dvips premature end of file in binary section Message-ID: <200102020607.WAA26605@Xenon.Stanford.EDU> Wow, that's tough! Darn line endings. I could write a Perl script to `fix' such files by recognizing the %%BeginBinary/%%EndBinary, doing the line translations for all other lines, but leaving those sections alone. This of course would only help if the BoundingBox is at the top of the file . . . -tom From mackay@cs.washington.edu Fri Feb 2 22:59:00 2001 From: mackay@cs.washington.edu (Pierre MacKay) Date: Fri, 2 Feb 2001 14:59:00 -0800 (PST) Subject: [tex-k] Re: dvips premature end of file in binary section In-Reply-To: <200102020607.WAA26605@Xenon.Stanford.EDU> Message-ID: <200102022259.f12Mx0a82227@june.cs.washington.edu> Further to my last message about %%BeginBinary and %%EndBinary, I note with some interest and resignation that Adobe has deplored the use of this pair of comments since at least 1990. Email: mackay@cs.washington.edu Pierre A. MacKay Smail: Department of Classics Emeritus Druid for 218 Denny Hall, Box 353110 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-2268 (Message recorder) From mackay@cs.washington.edu Fri Feb 2 22:50:54 2001 From: mackay@cs.washington.edu (Pierre MacKay) Date: Fri, 2 Feb 2001 14:50:54 -0800 (PST) Subject: [tex-k] Re: dvips premature end of file in binary section In-Reply-To: Message-ID: <200102022250.f12MosS81749@june.cs.washington.edu> > I think that you are right on, Tom. The problem is that the EPS files usually > see more action than just inclusion into a "master" PS file via dvips. > > The problem is that the EPS file is usally included via, say, \includegraphics, > and then latex (TeX) has to parse the EPS file for the BBox (not everyone uses > the .bb file option). So, if a Mac EPS file gets transferred in binary mode to > a UNIX/wintel box, TeX will think the EPS file is one LONG line because > the EOLs are not UNIX/DOS EOLs. Oops! This is a problem that can only get worse, because binary passages in PS files are bound to become ever more bloated. The Macintosh -> UNIX/Windows problem can be solved in all sorts of messy but simple ways, (I use tr) but the long binary problem is going to be a lot worse. No matter how large the TeX input line buffer is made, some application is going to produce a binary even longer. Moreover, any binary is likely to include an \012 or \015 character somewhere in it, and TeX is, not surprisingly, going to breathe a sigh of relief and regard that buffer as terminated. I suspect that TR is looking at the only workable solution, which is to recode the Binary passage into Hex, or something similar which permits lines of a reasonable length. I presume---I certainly hope---that a passage translated from binary to ASCIIHex or ASCII85 will be successfully be retranslated by any competent PostScript interpreter. Since %%BeginBinary and %%EndBinary are not likely to have anything else nested between them, a Perl translation ought to be not too complicated. (No, I am afraid I am not volunteering. I do Perl, but not nearly well enough to expose my programming style to public scrutiny.) Email: mackay@cs.washington.edu Pierre A. MacKay Smail: Department of Classics Emeritus Druid for 218 Denny Hall, Box 353110 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-2268 (Message recorder) From tjk@ams.org Fri Feb 2 23:44:04 2001 From: tjk@ams.org (Tom Kacvinsky) Date: Fri, 2 Feb 2001 18:44:04 -0500 (EST) Subject: [tex-k] Re: dvips premature end of file in binary section In-Reply-To: <200102022259.f12Mx0a82227@june.cs.washington.edu> Message-ID: Interesting. Photoshop 6.0 still uses them! Tom On Fri, 2 Feb 2001, Pierre MacKay wrote: > Further to my last message about %%BeginBinary and %%EndBinary, > I note with some interest and resignation that Adobe has deplored > the use of this pair of comments since at least 1990. > From Fabrice.Popineau@supelec.fr Fri Feb 2 12:21:16 2001 From: Fabrice.Popineau@supelec.fr (Fabrice Popineau) Date: 02 Feb 2001 13:21:16 +0100 Subject: [tex-k] Re: dvips premature end of file in binary section In-Reply-To: <200102020607.WAA26605@Xenon.Stanford.EDU> References: <200102020607.WAA26605@Xenon.Stanford.EDU> Message-ID: <8znpgts3.fsf@supelec.fr> I miss something there. I thought that this was solved for dvipsk by Eli Zaretskii quite long ago in the days of web2c-7. Or is it just one more way to fool the readline() mechanism ? -- Fabrice Popineau From salzer@logic.at Wed Feb 21 13:25:01 2001 From: salzer@logic.at (Gernot Salzer) Date: Wed, 21 Feb 2001 14:25:01 +0100 Subject: [tex-k] Portable PS and PDF files Message-ID: <200102211325.f1LDP1i30572@alpha.logic.tuwien.ac.at> Hi, what is the right way to produce portable and resolution independent PS and PDF files from TeX that can be both viewed and printed on many/all platforms? I tried to use the TT1 verions of CM as well as pdflatex, but some people still have problems viewing them with acrobat or printing them. Sometimes tiny 700kB pdf files explode to 60MB ps file when printed from acrobat. Thanks for any hints, e.g. for a pointer to the correct place where to ask Gernot Details: * tetex-1.0. * PS files with TT1 fonts are produces with dvips -Ppdf The output shows no more occurrences of the string "Bitmap", so I think dvips finds the correct fonts. * To obtain PDF files, I tried two methods: - dvips -Ppdf; ps2pdf - pdflatex Especially the latter tend to explode when printed from acrobat to PS. >From my own experience and from talking with colleagues I've got the impression that PDF is very much like Java: designed to be portable and platform independent, but in practice everything else than that. I really would appreciate if someone could prove me wrong. From JGMBenoit@wanadoo.fr Wed Feb 21 14:49:14 2001 From: JGMBenoit@wanadoo.fr (Jerome BENOIT) Date: Wed, 21 Feb 2001 15:49:14 +0100 Subject: [tex-k] Portable PS and PDF files References: <200102211325.f1LDP1i30572@alpha.logic.tuwien.ac.at> Message-ID: <3A93D56A.5BCE0360@Wanadoo.fr> Gernot Salzer wrote: > > Hi, > > what is the right way to produce portable and resolution independent > PS and PDF files from TeX that can be both viewed and printed on many/all > platforms? I guess that `pdf[la]tex' using `pfb' font files distributed by AMS and Bluesky (freely available on CTAN) is a good start: nevertheless one must write a correct `pdffonts.map' and use correct options inside [la]tex source or write correct `cfg' file (particularly when using ams package). > > I tried to use the TT1 verions of CM as well as pdflatex, > but some people still have problems viewing them with acrobat or > printing them. Sometimes tiny 700kB pdf files explode to 60MB > ps file when printed from acrobat. > > Thanks for any hints, e.g. for a pointer to the correct place > where to ask > > Gernot > > Details: > > * tetex-1.0. > > * PS files with TT1 fonts are produces with > dvips -Ppdf > The output shows no more occurrences of the string "Bitmap", > so I think dvips finds the correct fonts. > > * To obtain PDF files, I tried two methods: > - dvips -Ppdf; ps2pdf > - pdflatex > Especially the latter tend to explode when printed from > acrobat to PS. > > > >From my own experience and from talking with colleagues I've got > the impression that PDF is very much like Java: designed to be > portable and platform independent, but in practice everything > else than that. I really would appreciate if someone could prove > me wrong. > > > _______________________________________________ > tex-k mailing list > tex-k@tug.org > http://tug.org/mailman/listinfo/tex-k From salzer@logic.at Wed Feb 21 13:14:45 2001 From: salzer@logic.at (Gernot Salzer) Date: Wed, 21 Feb 2001 14:14:45 +0100 Subject: [tex-k] Portable PS and PDF files Message-ID: <200102211314.f1LDEji30354@alpha.logic.tuwien.ac.at> Hi, what is the right way to produce portable and resolution independent PS and PDF files from TeX that can be both viewed and printed on many/all platforms? I tried to use the TT1 verions of CM as well as pdflatex, but some people still have problems viewing them with acrobat or printing them. Sometimes tiny 700kB pdf files explode to 60MB ps file when printed from acrobat. Thanks for any hints, e.g. for a pointer to the correct place where to ask Gernot Details: * tetex-1.0. * PS files with TT1 fonts are produces with dvips -Ppdf The output shows no more occurrences of the string "Bitmap", so I think dvips finds the correct fonts. * To obtain PDF files, I tried two methods: - dvips -Ppdf; ps2pdf - pdflatex Especially the latter tend to explode when printed from acrobat to PS. >From my own experience and from talking with colleagues I've got the impression that PDF is very much like Java: designed to be portable and platform independent, but in practice everything else than that. I really would appreciate if someone could prove me wrong. From moguilny@ipgp.jussieu.fr Wed Feb 21 15:56:55 2001 From: moguilny@ipgp.jussieu.fr ( MOGUILNY Genevieve) Date: Wed, 21 Feb 2001 16:56:55 +0100 (MET) Subject: [tex-k] dvips 5.86d Message-ID: <200102211556.QAA05116@elrond.ipgp.jussieu.fr> Hello, We have 2 latex distributions on our site. The GUTenberg distrib and the TeX Live 5c (with TeTeX 1.0). The last one, TeX Live 5c, has - dvips 5.86d on Digital Unix and Linux - dvips 5.58f on Solaris The problem is that with dvips 5.86d, the inclusion of compressed postscript doesn't work : dvips: Failure to execute gunzip -c `kpsewhich -n latex tex IPGP.eps.gz`; continuing ] I try to add to my source code these lines : \documentclass[dvips]{article} ... \DeclareGraphicsRule{.eps.gz}{eps}{.eps.bb}% {`/usr/bin/gunzip -c `kpsewhich -n latex tex #1`} But the problem is still the same. Can you help me please ? (excuse my very bad english)... Genevieve Moguilny DMPN - IPGP Case 89 - Tour 24 4 place Jussieu 75252 Paris cedex 05 Tel. 01 44 27 24 15 Fax 01 44 27 38 94 moguilny@ipgp.jussieu.fr From dan@math.uiuc.edu Thu Feb 22 22:44:49 2001 From: dan@math.uiuc.edu (Daniel R. Grayson) Date: Thu, 22 Feb 2001 16:44:49 -0600 (CST) Subject: [tex-k] dvipsk Message-ID: <200102222244.f1MMin817419@u00.math.uiuc.edu> [Forwarding --karl] in T1part.c version 1.59 beta Copyright (C)1994, 1996 the following patch diff -ur /usr/local/src/jupiter/src/teTeX-1.0.7/texk/dvipsk/t1part.c dvipsk/t1part.c --- /usr/local/src/jupiter/src/teTeX-1.0.7/texk/dvipsk/t1part.c Sat Mar 6 14:26:26 1999 +++ dvipsk/t1part.c Thu Feb 22 16:34:33 2001 @@ -175,7 +175,7 @@ typetemp _HUGE *end_of_scan; unsigned char *line; unsigned char *tmpline; -unsigned char token[64]; +unsigned char token[4096]; unsigned char notdef[]="/.notdef"; #ifdef Omega unsigned char grid[65536]; fixes a problem in GetToken -- there is not checking for overflow, and it could crash (and does) on a large token in an input file. But there should be a better fix. From jpetit@lsi.upc.es Sat Feb 24 14:38:08 2001 From: jpetit@lsi.upc.es (Jordi Petit i Silvestre) Date: Sat, 24 Feb 2001 15:38:08 +0100 Subject: [tex-k] Bug report Message-ID: <200102241438.PAA07797@tarkus.lsi.upc.es> Dear developpers, I am surprised to see that bibtex breaks lines at 80 columns. This never has been a problem for me untill I found tham a Latex command has been broken between lines: \bibitem{Alvarez:2000:CTP} C.~{\`A}lvarez, J.~D\'{\i}az, R.~Cases, J.~Petit, and M.~Serna. \newblock Communication tree problems. \newblock Technical report, Universitat Polit�cnica de Catalunya, Departament de Llenguatges i Sistemes Inform�tics, \wwww{http://www.lsi.upc.es/~jpetit/Publications}{http://www.lsi.upc.es/$\si% m$jpetit/Publications}, 2000. As you can see, in the bbl file \sim is broken between lines, resulting in a compilation error latter, in latex. It seems to me that it should be some option to not allow line breaks, but this is not documented in the -h option. I will write a simple script to correct that for me, but I thought you would be interested in hearing about this problem. Best regards, Jordi Petit i Silvestre From uwe.koloska@mailbox.tu-dresden.de Sat Feb 24 20:49:41 2001 From: uwe.koloska@mailbox.tu-dresden.de (Uwe Koloska) Date: Sat, 24 Feb 2001 21:49:41 +0100 Subject: [tex-k] updated texnansi encoding from YandY Message-ID: <01022421494101.00647@bilbo> Hello, /texmf/dvips/base (as included in the newes teTeX beta) has an outdated texnansi.enc. From their website I have downloaded a new one that has the Euro currncy sign included: http://www.yandy.com/download/texnansi.enc There also is a variant named texnansx.enc that lacks all double glyphs (glyphs that are placed in different slots) -- but this is problematic if the texnans[ix].enc encoded font is used directly without a virtual font. (ConTeXt for example uses some of the glyphs in slots that are emptied from texnansx.enc) Hope that information helps Uwe -- mailto:koloska@rcs.urz.tu-dresden.de http://rcswww.urz.tu-dresden.de/~koloska/ -- -- right now the web page is in german only but this will change as time goes by ;-) From janneke@gnu.org Sun Feb 25 12:12:13 2001 From: janneke@gnu.org (Jan Nieuwenhuizen) Date: 25 Feb 2001 13:12:13 +0100 Subject: [tex-k] kpsewhich symlink bug Message-ID: Hi, Here's a bug that bit me in lilypond-1.3.131, mostly because of a badly autogenerated TEXINPUTS path, containing the `magic' `//'. Greetings, Jan. 13:02:07 appel ~/tmp$ mkdir -p foo/bar 13:02:17 appel ~/tmp$ cd foo 13:02:17 appel ~/tmp/foo$ ln -s . foo 13:02:17 appel ~/tmp/foo$ kpsewhich --version kpathsea version 3.3.1 Copyright (C) 1997 K. Berry. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. 13:02:34 appel ~/tmp/foo$ export TEXINPUTS=.// 13:02:52 appel ~/tmp/foo$ kpsewhich --debug foo bar ^C 13:02:58 appel ~/tmp/foo$ kpsewhich --debug=1 foo bar kdebug:dir_links(./bar) => 2 kdebug:dir_links(./foo) => 3 kdebug:dir_links(./foo/bar) => 2 kdebug:dir_links(./foo/foo) => 3 kdebug:dir_links(./foo/foo/bar) => 2 kdebug:dir_links(./foo/foo/foo) => 3 kdebug:dir_links(./foo/foo/foo/bar) => 2 kdebug:dir_links(./foo/foo/foo/foo) => 3 kdebug:dir_links(./foo/foo/foo/foo/bar) => 2 kdebug:dir_links(./foo/foo/foo/foo/foo) => 3 kdebug:dir_links(./foo/foo/foo/foo/foo/bar) => 2 kdebug:dir_links(./foo/foo/foo/foo/foo/foo) => 3 kdebug:dir_links(./foo/foo/foo/foo/foo/foo/bar) => 2 ^C -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org