Re: [XeTeX] How to manually create the xelatex.fmt?
Chris Travers wrote: If TexLive had been around in 2002 and was statically linking to zlib, it would have been affected too. TeX does not link against zlib but LaTeX and XeTeX do. Similarly, arbitrary code execution vulnerabilities have been found in 2005 in libjpeg (also linked to by LaTeX and XeTeX). Again these predate TexLive. Chris, these statements have to be wrong, at least in part : if TeX does not link against Zlib, then neither does LaTeX -- they are one and the same engine. -- ditto -- LibJpeg. Philip Taylor -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Philip TAYLOR (Webmaster, Ret'd) wrote: Chris, these statements have to be wrong, at least in part : if TeX does not link against Zlib, then neither does LaTeX -- they are one and the same engine. -- ditto -- LibJpeg. Mea culpa, mea culpa, mea maxima culpa : C:\Program Files\Microsoft.NET\SDK\v2.0tex This is TeX, Version 3.1415926 (Web2C 2010) **\end No pages of output. Transcript written on texput.log. C:\Program Files\Microsoft.NET\SDK\v2.0latex This is pdfTeX, Version 3.1415926-1.40.11 (Web2C 2010) **\end entering extended mode LaTeX2e 2009/09/24 Babel v3.8l and hyphenation patterns for english, dumylang, nohyphenation, ge rman-x-2009-06-19, ngerman-x-2009-06-19, afrikaans, ancientgreek, ibycus, arabi c, armenian, basque, bulgarian, catalan, pinyin, coptic, croatian, czech, danis h, dutch, ukenglish, usenglishmax, esperanto, estonian, ethiopic, farsi, finnis h, french, galician, german, ngerman, swissgerman, monogreek, greek, hungarian, icelandic, assamese, bengali, gujarati, hindi, kannada, malayalam, marathi, or iya, panjabi, tamil, telugu, indonesian, interlingua, irish, italian, kurmanji, lao, latin, latvian, lithuanian, mongolian, mongolianlmc, bokmal, nynorsk, pol ish, portuguese, romanian, russian, sanskrit, serbian, slovak, slovenian, spani sh, swedish, turkish, turkmen, ukrainian, uppersorbian, welsh, loaded. * so they are not the same binary. Sincere apologies, Chris. ** Phil. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Fri, Oct 21, 2011 at 12:22 AM, Philip TAYLOR (Webmaster, Ret'd) p.tay...@rhul.ac.uk wrote: Chris Travers wrote: If TexLive had been around in 2002 and was statically linking to zlib, it would have been affected too. TeX does not link against zlib but LaTeX and XeTeX do. Similarly, arbitrary code execution vulnerabilities have been found in 2005 in libjpeg (also linked to by LaTeX and XeTeX). Again these predate TexLive. Chris, these statements have to be wrong, at least in part : if TeX does not link against Zlib, then neither does LaTeX -- they are one and the same engine. -- ditto -- LibJpeg. Hmmm [chris@chris-dev2 ~]$ ldd /usr/bin/latex linux-gate.so.1 = (0x00232000) libpng12.so.0 = /usr/lib/libpng12.so.0 (0x003ae000) libz.so.1 = /lib/libz.so.1 (0x00d6b000) zlib: ^ libkpathsea.so.4 = /usr/lib/libkpathsea.so.4 (0x00d8) libpoppler.so.5 = /usr/lib/libpoppler.so.5 (0x04516000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x040c) libm.so.6 = /lib/libm.so.6 (0x00d1b000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x040a) libc.so.6 = /lib/libc.so.6 (0x00b8e000) liblcms.so.1 = /usr/lib/liblcms.so.1 (0x04ae1000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x0478e000) libjpeg: ^ libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x003d8000) libfontconfig.so.1 = /usr/lib/libfontconfig.so.1 (0x00485000) libopenjpeg.so.2 = /usr/lib/libopenjpeg.so.2 (0x005af000) /lib/ld-linux.so.2 (0x00b6c000) libexpat.so.1 = /lib/libexpat.so.1 (0x00384000) Wondering where these are coming from. similarly [chris@chris-dev2 ~]$ ldd /usr/bin/xetex linux-gate.so.1 = (0x00825000) libTECkit.so.0 = /usr/lib/libTECkit.so.0 (0x00be2000) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x003d8000) libz.so.1 = /lib/libz.so.1 (0x00d6b000) zlib: ^ libpng12.so.0 = /usr/lib/libpng12.so.0 (0x003ae000) libfontconfig.so.1 = /usr/lib/libfontconfig.so.1 (0x00485000) libpoppler.so.5 = /usr/lib/libpoppler.so.5 (0x04516000) libkpathsea.so.4 = /usr/lib/libkpathsea.so.4 (0x00d8) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x040c) libm.so.6 = /lib/libm.so.6 (0x00d1b000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x040a) libpthread.so.0 = /lib/libpthread.so.0 (0x00d47000) libc.so.6 = /lib/libc.so.6 (0x0064) libexpat.so.1 = /lib/libexpat.so.1 (0x00384000) liblcms.so.1 = /usr/lib/liblcms.so.1 (0x04ae1000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x0478e000) libjpeg: ^ libopenjpeg.so.2 = /usr/lib/libopenjpeg.so.2 (0x005af000) /lib/ld-linux.so.2 (0x00b6c000) Am I reading this wrong? Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Thu, Oct 20, 2011 at 09:30:29PM +0100, Philip TAYLOR (Webmaster, Ret'd) wrote: And to which package management suite would you suggest they delegate when offering TeX Live for Windows ? Perhaps there's not even need to change the package management texlive has. I do not know much about the package managers out there, but those I looked at incorporate the option to call a script to do at least after-installation stuff. So perhaps there might be the option to tell the distro's package manager with the help of this mechanism how to truely install and update texlive. If---I didn't check---texlive offers a way of installing/updating to a fixed versions (some command to 'install version number X' in contrast to 'install newest version'), then even the stability demands of long term stable distros can be fulfilled. As this would help mete out terribly outdated versions of texlive, thinking about such a mechanism might be worth the effort. Unfortunately I don't have enough time to offer my help to that at the moment. Susan Dittmar -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/21 Chris Travers chris.trav...@gmail.com: On Thu, Oct 20, 2011 at 8:25 AM, Peter Dyballa peter_dyba...@web.de wrote: Am 20.10.2011 um 16:54 schrieb Chris Travers: One of the other commentors talks about documents that don't render on all versions of TexLive. If a client of mine is depending on this working, upgrading the various stuff from CTAN in order to get a security fix in an underlying program is a non-starter because it may break things, just as it breaks other documents. You wrote: You're mixing up things! TeX is a set of a few binaries, some of them are the TeX engines (pdfTeX, XeTeX, LuaTeX, conTeXt). The majority of the TeX software are text files. If a change in a library is breaking the TeX engine, then the change itself is faulty. If you're using a TeX function (library call) of a future version of that software, then something has to fail. If you're using an old function (library call) that has been changed, then you can't assume something useful will happen to come out. My reply: I'm not the one mixing things up. What I am saying is perhaps a bit different. If you are tying the .sty upgrades to binary upgrades, then an upgrade in a binary requires .sty upgrades, and these can break document generation systems. No! Binaries define the TeX primitives as \hbox, \relax, \vskip etc. The .sty file define macros that are base on other macros in the format and all this is based on primitives. Binary update improve efficiencies, may fix some bugs but _never_ change the primitives, thus binary updates never break .sty files. It was different with luatex. It was clearly announced at its beginning that everything is experimental and any lua feature can be changed. Such changes not only break .sty files but even your .tex files. Think about it this way. Suppose you are doing magazine layout in LaTeX. You start with open ended problems. You can pursue all sorts of courses in solving them. You want up to date packages which have as few bugs that other people have run into as possible. I think we all agree on that. However, suppose you have a piece of software that generates documents in LaTeX. This design is done once and thereafter it is run in a predictable fashion. Once you have done your testing, you can assume that barring unexpected and invalid inputs on the part of a user, it will function correctly forever. Note the user here isn't writing LaTeX documents. The user is just doing data entry, so all input can be sanitized of LaTeX commands. Consequently, predictability is key here, and the last thing you want done is to change the behavior under the program just because another more important upgrade needs it. The needs in this environment are completely different from the needs of the LaTeX user. In such a cas do not rely on someone else's packages that are out of your control. Write your own package based on LaTeX kernel macros or even on plain TeX. That's what I do even for a series of books that started in 1992 and new books in these series are published till now and will be published a few more years. I started with emTeX in MS-DOS, continued with emTeX in OS/2, now I do the job with TeX Live in Linux. I have made improvements to make my work easier but occasionally I have to reprocess 18 years old document (prepared in emTeX) using the latest TeX Live and i have never found any problem. My macros still work. So what sorts of fixes does the latter environment need? Well, let me make up a hypthetical security vulnerability-- keep in mind this software is not running on the user's system. Suppose a vulnerability is found where if a user sends in a specific UTF-16 string and the software expects UTF-8, that it causes a buffer overflow somewhere (this can happen because UTF-16 strings sometimes contain null bytes while UTF-8 can still use null bytes as string terminators), and this allows an attacker to now run arbitrary code on the server. Let's say furthermore that the problem isn't with LaTeX but with some other library it is linked to. Now, if you are a LaTeX user, and on a workstation, then this is an important security fix, and there is little harm in updating everything in TexLive. But if you are doing stuff on a server, this is a critical fix, and you definitely don't want to be updating unrelated stuff at the same time. Hope this helps, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Oct 20, 2011, at 9:36 PM, Ross Moore wrote: Hi Herb, On 21/10/2011, at 6:47 AM, Herbert Schulz wrote: If TexLive had been around in 2002 and was statically linking to zlib, it would have been affected too. TeX does not link against zlib but LaTeX and XeTeX do. ... Howdy, Also, you say ``TeX does not link against zlib but LaTeX and XeTeX do'' and I don't understand that since LaTeX is simply a macro package that sits on top of TeX and isn't linked to anything like zlib as far as I know. XeTeX is an engine but I don't know what it's linked to. The binary called 'latex' is actually a (hard or soft) link to the underlying binary named 'pdftex'. This is what is statically linked to 'zlib'. It is a different binary to 'xetex', so his statements make perfect sense, from this (very pragmatic) point of view. But yes, I had to think about it a bit, before being confident about what was being said. Howdy, So its the binary, pdflatex, that is linked to zlib. That makes perfect sense. Ok. Good Luck, Herb Schulz (herbs at wideopenwest dot com) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 21.10.2011 um 00:51 schrieb Chris Travers: I'm not the one mixing things up. What I am saying is perhaps a bit different. If you are tying the .sty upgrades to binary upgrades, then an upgrade in a binary requires .sty upgrades, and these can break document generation systems. Neither me nor other TeX users are doing this. TeX is not producing more functions, eTeX, kind on an 8-bit extension of TeX, is stable, XeTeX the same. Only LuaTeX is in rapid development. And the macro (STY or CLS) text files. Suppose a vulnerability is found where if a user sends in a specific UTF-16 string and the software expects UTF-8, that it causes a buffer overflow somewhere (this can happen because UTF-16 strings sometimes contain null bytes while UTF-8 can still use null bytes as string terminators), and this allows an attacker to now run arbitrary code on the server. In that case I'd use reasonable hardware. For example PowerPC based. Its stack is not executable. Or AMD hardware. Using a particular switch makes the stack unexec. I seem to remember that modern, maybe less stable versions of GCC allow this as well. They allow it in that very special case when *all* used dynamic libraries are compiled that way. (Is there any Linux offering this feature?) So also a little utility to check whether some eMail has arrived on my private IMAP or POP server would have to be compiled like this. Or I'd use a reasonable OS, one with role based access control and without an almighty super-user. This means that would have to be a modern OS from this millennium. Let's say furthermore that the problem isn't with LaTeX but with some other library it is linked to. Now, if you are a LaTeX user, and on a workstation, then this is an important security fix, and there is little harm in updating everything in TexLive. But if you are doing stuff on a server, this is a critical fix, and you definitely don't want to be updating unrelated stuff at the same time. Here you can see how good it is that TeX, that not packaged by Linux distributors, uses static libraries and is self-contained. (Ex)Changing it has no impact on the system. It can continue to use the shared libraries with all the critical securities holes. Hope this helps, I hope the same. BTW, it's usually possible to keep private copies of TeX in one's private area. Not the binaries, there really is no need doing so, only a few text files, some font files I bought, their MAP file fragments, and my MAP files. The search algorithm of TeX first looks into that private area, then it starts, if necessary, searching the system. And it does not search the system at once, it first looks whether there is a local preference, then it looks, if still necessary, into the chosen year's edition of TeX Live. That's the sane behaviour of TeX Live, similar the PATH variable of UNIX shells. I don't know how packaged Linux TeX works, whether it's possible to edit texmf.cnf files to alter this TeX's behaviour. -- Greetings Pete November, n.: The eleventh twelfth of a weariness. – Ambrose Bierce, The Devil's Dictionary -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 21.10.2011 um 01:42 schrieb Chris Travers: At the time a large portion of the industry was writing software statically linked against zlib I think it wasn't zlib, it was versions of zlib, presumingly dozens. If TexLive had been around in 2002 and was statically linking to zlib, it would have been affected too. Again: what is the effort or danger of overwriting 50 MB of non-system files? In TeX Live we had even larger updates of its infrastructure (there was a famous bug in pdfTeX). Similarly, arbitrary code execution vulnerabilities have been found in 2005 in libjpeg (also linked to by LaTeX and XeTeX). Again these predate TexLive. And they only can be exploited in old Linux systems with executable stacks and without role based access control. I wouldn't care for such half-baked vulnerabilities. I'd classify them as marketing talk. So my answer is that TexLive binaries, distributed as they currently are, are simply too young to have hit the major cases of these problems so far. If my old memory serves me well, then I must have met my first TeX binaries and libraries 25 (?) years ago. Too late? However, the library dependencies are anything but trivial-- ldd gives me 17 libraries that xetex is linked against and 15 that latex is linked against. It seems for those of us with a longer memory, extensive static linking is asking for trouble Therefore you should go pro and use TeX Live with its statically linked binaries! Absolutely no trouble with 15 or 17 shared libraries the system might find somewhere or somewhere else (where it has been substituted with a carefully crafted one) or not at all. -- Greetings Pete Debugging? Klingons do not debug! Our software does not coddle the weak. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 21.10.2011 um 09:40 schrieb Chris Travers: Am I reading this wrong? No, but you you're choosing the wrong candidates, those from the old and smelling Linux packages. -- Greetings Pete Build a man a fire and he'll be warm for a night, but set a man on fire and he'll be warm for the rest of his life. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/21 Chris Travers chris.trav...@gmail.com: If TexLive had been around in 2002 and was statically linking to zlib, it would have been affected too. It was and it was and it was. :-( So it was till we dropped libtiff from pdfTeX and till we dropped xpdf from XeTeX and LuaTeX (pdfTeX still uses it). Best Martin -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Chris, you are *not* alone in your need for stability in the sense of everything that worked up to now still has to work with the new version. I have the same requirement, and quite a lot of the professional typesetters on this list do, too. So even if it does not look like that to you---I know I was one of those asking you to update---there *is* interest in that same thing here. I think the problem here arises because most of the people on this list are TeX users themselves, not TeX service providers. Quoting Herbert Schulz (he...@wideopenwest.com): On Oct 19, 2011, at 9:09 AM, Chris Travers wrote: I think stable in terms of you can safely use this to render your documents and stable in terms of no unnecessary changed so we know the software using this clearly and predictably works every time are different senses of the word stable. I need the latter once the software is installed, you are talking the former. Of course there is another sense of ``stable'': we're not going to change anything even if it doesn't work and has bugs because it's better to know your enemy than to find an ew enemy or friend. You are right, and that's the danger whenever you need a system in the second listed sense of stable. A danger Chris, and others with his needs, is very aware of. I think it's quite well that this point is being discussed here again. Perhaps it serves to remind package writers how important backwards compatibility is, and what a hell they create for their users whenever backwards compatibility is broken. Susan -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On 18 October 2011 15:39, Chris Travers chris.trav...@gmail.com wrote: Here's a breakdown of OS support for TexLive versions for anyone interested: Debian Lenny: TexLive 2007 Debian Squeeze: TexLive 2009 Debian Sid: TexLive 2009 Ubuntu 10.04 LTS: TexLive 2009 Red Hat Enterprise 6: TexLive 2007 That means that the most recent versions of CentOS and Scientific Linux also use 2007. For what it's worth, there is a current effort to get more recent TexLive packages created for Fedora (which will eventually feed into RHEL, CentOS, etc.). The big issue as I understand it is licensing ... More details here: http://fedoraproject.org/wiki/Features/TeXLive I've been running the unofficial TL 2011 packages for a while now with few issues. MEF -- Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/ Interaction Lab -- http://www.macs.hw.ac.uk/InteractionLab School of Mathematical and Computer Sciences, Heriot-Watt University Heriot-Watt University is a Scottish charity registered under charity number SC000278 -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Tue, Oct 18, 2011 at 03:14:56PM +0200, Ulrike Fischer wrote: Am Tue, 18 Oct 2011 05:43:57 -0700 schrieb Chris Travers: This has all been very helpful. At least I have things narrowed down a bit here: # fmtutil-sys --byfmt xelatex ! LaTeX source files more than 5 years old!. l.545 ...aTeX source files more than 5 years old!} Any idea of what I do about this? The best is to get and install a new TeXLive 2011 with newer latex sources. You can also try to fool latex by changing your pc date. No, it is actually the worst thing to do. Most Linux distributions have their own packaging system and using alien blob (like the TeXLive) has all the disadvantages it can: possbily breaking compatibility if some system library is updated, not upgrading this blob using system tools if securty vulnerabilities are found can lead to serious security problems, etc... That's why I always compiled XeTeX from the SVN, but even that is broken since about 2 years :-/ P.T. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Tue, Oct 18, 2011 at 05:16:12PM +0200, Peter Dyballa wrote: Am 18.10.2011 um 16:39 schrieb Chris Travers: Here's a breakdown of OS support for TexLive versions for anyone interested: Debian Lenny: TexLive 2007 Debian Squeeze: TexLive 2009 Debian Sid: TexLive 2009 Ubuntu 10.04 LTS: TexLive 2009 Red Hat Enterprise 6: TexLive 2007 That means that the most recent versions of CentOS and Scientific Linux also use 2007. Forget these RPM or DEB based re-packings! (The support from their distributors/repackagers can be a bit less than optimal.) Install TeX Live 2005, 2006, 2007, 2008, 2009, 2010, 2011! This is the best way to hell. Native packages should be used and not some stupid external blob! P.T. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/20 Petr Tomasek toma...@etf.cuni.cz: On Tue, Oct 18, 2011 at 05:16:12PM +0200, Peter Dyballa wrote: Am 18.10.2011 um 16:39 schrieb Chris Travers: Here's a breakdown of OS support for TexLive versions for anyone interested: Debian Lenny: TexLive 2007 Debian Squeeze: TexLive 2009 Debian Sid: TexLive 2009 Ubuntu 10.04 LTS: TexLive 2009 Red Hat Enterprise 6: TexLive 2007 That means that the most recent versions of CentOS and Scientific Linux also use 2007. Forget these RPM or DEB based re-packings! (The support from their distributors/repackagers can be a bit less than optimal.) Install TeX Live 2005, 2006, 2007, 2008, 2009, 2010, 2011! This is the best way to hell. Native packages should be used and not some stupid external blob! It would be a good way if the native packages were up-to-date and if they allowed me to install not only the current version but even older versions. As a matter of fact, I first verify that everything works and after that I switch PATH. Twice I needed to test a document with an old TL because I found that it does not work with the current version. This is the greatest benefit of TL. I know what I am writing. It happend several times that the native package of Octave included an incompatible change. Two such upgrades were so nasty that each of them forced me to spend two weeks of work just to make my code running. P.T. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 20.10.2011 um 12:32 schrieb Petr Tomasek: This is the best way to hell. Native packages should be used and not some stupid external blob! Can it be that you see stupidity because you can't see tlmgr and that the blob is similar to any Linux distribution? What keeps you from installing TeX Live temporarily in /tmp and converting it into a native package? -- Greetings Pete Imbecility, n.: A kind of divine inspiration, or sacred fire affecting censorious critics of this dictionary. – Ambrose Bierce: _The Devil's Dictionary_ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/20 Zdenek Wagner zdenek.wag...@gmail.com: 2011/10/20 Petr Tomasek toma...@etf.cuni.cz: On Tue, Oct 18, 2011 at 03:14:56PM +0200, Ulrike Fischer wrote: Am Tue, 18 Oct 2011 05:43:57 -0700 schrieb Chris Travers: This has all been very helpful. At least I have things narrowed down a bit here: # fmtutil-sys --byfmt xelatex ! LaTeX source files more than 5 years old!. l.545 ...aTeX source files more than 5 years old!} Any idea of what I do about this? The best is to get and install a new TeXLive 2011 with newer latex sources. You can also try to fool latex by changing your pc date. No, it is actually the worst thing to do. Most Linux distributions have their own packaging system and using alien blob (like the TeXLive) has all the disadvantages it can: possbily breaking compatibility if some system library is updated, not upgrading this blob using system tools if securty vulnerabilities are found can lead to serious security problems, etc... That's why TL is linked statically with the exception of tools dependent on fontconfig (xetex, luatex, xdvipdfmx). I think Petr overstates the case a bit. I can think of plenty of disadvantages that using a blob doesn't have. But it has enough that for software that needs to be stable, it's worth avoiding. However, statically linking things strikes me as even worse from a stability/security perspective (which is what is critical with server software). It means that if there is a bug in any of the libraries you have possibly linked to, you have to upgrade everything. I am remembering a certain double free bug in zlib a number of years ago that resulted in security advisories and patches for a huge swath of software because everything had statically linked to zlib and derivatives. Certainly something like isn't a reason to update everything in CTAN.. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Wed, Oct 19, 2011 at 01:45:29PM +0200, Ulrike Fischer wrote: Am Wed, 19 Oct 2011 03:19:48 -0700 schrieb Chris Travers: And obviously this puts a lot us in bad positions. If RHEL 6 (released about a year ago) is sticking to TeXLive 2007, we all have problems. The question is what the community can reasonably do, and what developers can be expected to do navigating these issues. Well I'm a windows user so actually I'm not really affected. But imho the linux distros should rethink their installation methods and installation advices. It is absurd that 10 or more distros invest a lot of main power in making packages when they lack the main power to keep them up-to-date. Actually, with most of free software this is hardly a problem as most of it is nowaday written properly and packaging a new version usually means putting a tarball of the new version into a specific location a increasing the version number in the .spec file (for .rpms) and maybe adding a changelog entry. The only problem is with software that tries to be more clever and do things which should be left for to the underlying system... P.T. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Wed, Oct 19, 2011 at 03:20:15PM +0200, Ulrike Fischer wrote: Am Wed, 19 Oct 2011 05:59:16 -0700 schrieb Chris Travers: This matches my needs very well. If my clients are running accounting systems, the last thing I want is an upgrade of TexLive to break their ability to generate invoices. Normally you get more problems if you can't update ;-) If there are bugs in older versions, I can work around those bugs, but the problem of getting a document that will only render with one version or another is not acceptable to my application. Then you shouldn't rely on an external TeXLive installation. That's why external TeXLive intallation are GENERALLY a bad idea. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Thu, Oct 20, 2011 at 4:05 AM, Peter Dyballa peter_dyba...@web.de wrote: Am 20.10.2011 um 12:53 schrieb Chris Travers: However, statically linking things strikes me as even worse from a stability/security perspective (which is what is critical with server software). It means that if there is a bug in any of the libraries you have possibly linked to, you have to upgrade everything. This is what the TeX Live package manager performs. The providers of TeX Live do the whole job. I think you miss the point. When something went wrong with zlib in 2002, software from the Apache Web Server to Microsoft Office required security patches. Now, I take it you figure that TexLive 2007, 2008, 2009, 2010, will not get such security patches So that means if such a problem affected you, everyone would have to upgrade to the latest version, possibly breaking any automated document generation in the process, *just to get the security fix.* This is why external TexLive distributions are bad ideas on server systems, though they are great for workstations, and why many of us then end up working with the distro-supplied packages, as they are not statically linked. [root@chris-dev2 ledgersmb_1.3]# ldd /usr/bin/latex linux-gate.so.1 = (0x00f3a000) libpng12.so.0 = /usr/lib/libpng12.so.0 (0x003ae000) libz.so.1 = /lib/libz.so.1 (0x00d6b000) libkpathsea.so.4 = /usr/lib/libkpathsea.so.4 (0x00d8) libpoppler.so.5 = /usr/lib/libpoppler.so.5 (0x04516000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x040c) libm.so.6 = /lib/libm.so.6 (0x00d1b000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x040a) libc.so.6 = /lib/libc.so.6 (0x00b8e000) liblcms.so.1 = /usr/lib/liblcms.so.1 (0x04ae1000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x0478e000) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x003d8000) libfontconfig.so.1 = /usr/lib/libfontconfig.so.1 (0x00485000) libopenjpeg.so.2 = /usr/lib/libopenjpeg.so.2 (0x005af000) /lib/ld-linux.so.2 (0x00b6c000) libexpat.so.1 = /lib/libexpat.so.1 (0x00384000) So if libz needs a security update, I can get it without replacing everything else Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/20 Chris Travers chris.trav...@gmail.com: 2011/10/20 Zdenek Wagner zdenek.wag...@gmail.com: It would be a good way if the native packages were up-to-date and if they allowed me to install not only the current version but even older versions. As a matter of fact, I first verify that everything works and after that I switch PATH. Twice I needed to test a document with an old TL because I found that it does not work with the current version. This is the greatest benefit of TL. I know what I am writing. It happend several times that the native package of Octave included an incompatible change. Two such upgrades were so nasty that each of them forced me to spend two weeks of work just to make my code running. BTW, that's *exactly* why you don't want to update existing important systems once they are shown to be working without extensive testing and staging, and why staying on older versions for working systems that automatically generate documents is usually the wise course of action. There are two big reasons for update: 1. The new hardware is not supported by the old Linux distro 2. The necessary SW is not available as a package for the old distro and cannot be compiled from SourceForge sources because glibc in the distro is obsolete Of course, I never update anything in a middle of an important task. That's why I still have CentOS 4 on one of my computers. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/20 Chris Travers chris.trav...@gmail.com: The general point is that where one is doing server-side document generation, there are sufficient reasons *not* to use external binary blobs with it's own package manager that doesn't talk to or integrate with anything else, which has a short support cycle, and which is statically linked to all its dependencies. Use of distro packages may not be perfect, but the only two options are that or compiling from source, realistically. I have server side applications based on TL. I use them from time to time (none of them is currently active). The remote user cannot write the document, it is always prepared by some SW tool (PHP, XSLT, ...). And \write18 is disabled for such applications. On the other hand, there are servers providing TL and users can type their documents directly, see http://tex.mendelu.cz/ for instance. If the current version of TL is 2011 but the native packaged version in a Linux distro is 2007, are you sure that there are not bugs and security holes? Do you know how \write18 is handled? Are you sure that they do not allow \input /etc/passwd and \input /etc/shadow? It is disabled by me in my TL based server side applications. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Quoting Zdenek Wagner (zdenek.wag...@gmail.com): Of course, I never update anything in a middle of an important task. That's why I still have CentOS 4 on one of my computers. Well, in the middle of an important task is valid in a production system every single minute. With this policy you will never update on such a system. And that's why there are so many old systems out there, and why Chris ran into the problem that created this thread. Susan -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Quoting Peter Dyballa (peter_dyba...@web.de): What keeps you from installing TeX Live temporarily in /tmp and converting it into a native package? Me personally? I never did that before and would have to delve into how to create a native package. I had a look at this some time ago and decided my need was not big enough for the effort it seemed to take. Could you tell me how to do that for openSUSE from the top of your head? If it was easy, I'm sure an up to date TeX were included in this distribution (and all the others). I have some friends who use Linux at home. Although intelligent people, information technologies cannot hold their interest, and thus they are nearly computer-illiterate. I taught them enough so they can make the necessary updates using the distribution's packager. Do I really want to have to teach them a different way of updating for every tiny program they use? Admitted, TeXlive is not a tiny thing. Still it is just one program suite among a lot of others. Helping users with the day-to-day administrational work was the main reason why linux distributions have been invented. To demand that users do their updates on a per-program base and by hand means a big step backwards in this respect... I really love tlmgr. I do use it extensively. And I am tremendously grateful for all the effort put into that. But please rather think about supporting distros so they package up to date TeX (or even trigger tlgmr) instead of demanding that the end user uses yet another updating tool. Susan -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Wed, Oct 19, 2011 at 03:10:19PM +0200, Peter Dyballa wrote: Am 19.10.2011 um 12:19 schrieb Chris Travers: If RHEL 6 (released about a year ago) is sticking to TeXLive 2007, we all have problems. The only problem is that of understanding. It's like the fifth wheel or the tool to change wheels that come with new car. They're not really usable, they're more kind of alibis. And that's the situation of TeX in Linux. Because it's not necessary to build a second rail of distribution via DEB or RPM packages. TeX Live comes with its own package manager and in packages and in meta-packages. Use this opportunity! An opportunity to make chaos in the system? No, thanks! (P.S. The best would be to make some convertor which would convert the TeX-Live packages into native ones. Anything else is a problem...) P.T. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/20 Zdenek Wagner zdenek.wag...@gmail.com: I have server side applications based on TL. I use them from time to time (none of them is currently active). The remote user cannot write the document, it is always prepared by some SW tool (PHP, XSLT, ...). And \write18 is disabled for such applications. On the other hand, there are servers providing TL and users can type their documents directly, see http://tex.mendelu.cz/ for instance. If the current version of TL is 2011 but the native packaged version in a Linux distro is 2007, are you sure that there are not bugs and security holes? Do you know how \write18 is handled? Are you sure that they do not allow \input /etc/passwd and \input /etc/shadow? It is disabled by me in my TL based server side applications. Ok, two quick points I can't help but pass up. 1) Any server programmer worth his salt is going to properly sanitize user input before putting it into a template. I am not 100% confident that we do a perfect job, but I can tell you that if \write18 or \input /etc/passwd ended up in an invoice it would be the sysadmin, or a third party developer contracted to build templates, and not the user who put it there. We do the same for HTML because we don't want nasty little things like cross-site scripting. If you allow users to input arbitrary code into your templates, you get what you deserve.* * There is a caveat here in that the software does allow a subset of users to edit the templates, including the latex commands, but this is disabled by default on the filesystem level and for good reason. There are few users who find this is worth the inherent security risks, but there are a few. 2) If your accounting system has access to /etc/shadow, I think the fact that it could be input into a LaTeX document is the least of your worries. Seriously. there is something to be said about server software running with restrained permissions (which is why the Apache worker processes run with limited permissions, why PostgreSQL refuses to run as root, etc). We started LedgerSMB because we were focused on security and the project we forked from was not. This means restricted permissions, input sanitation, and the whole bit. Heck the most recent version of our software doesn't even have permission to access the database if a user isn't logged in, and then it only has the permissions granted to that user (meaning that SQL injection issues, if they exist, are suddenly a lot less interesting). As your examples demonstrate, without input sanitation, and restrained permissions, the ways in which a programming language can be abused are just too difficult to prevent. The solutions are banning *all* escape sequences, and running with no more permissions than absolutely necessary. Then these problems go away. The nastier bugs (and ones that other libraries may have a role to play in addressing) occur when invalid data is sent to the template and this causes processing errors, such as buffer overflows, stack overflows, and the like. In these cases, it could be possible to attack such a system without passing in LaTeX commands. Replacing the underlying faulty library fixes the problem, which of course is impossible when everything is statically linked. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Thu, Oct 20, 2011 at 5:24 AM, Petr Tomasek toma...@etf.cuni.cz wrote: An opportunity to make chaos in the system? No, thanks! (P.S. The best would be to make some convertor which would convert the TeX-Live packages into native ones. Anything else is a problem...) Just to offer a counter-point here. If I was doing a lot of heavy-duty design work (as it is, the design work I do is lighter-weight, even with my own books etc), I'd probably keep an up-to-date TeX-Live installation installed. I don't think this is always a bad idea. In fact I there is an important role for such a tool. The thing is, though, just because it's a good tool for some environments doesn't mean it's a good tool for everything. Not everything is a nail, and not even all nails need the same kinds of hammers.. Best wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am Thu, 20 Oct 2011 13:32:00 +0200 schrieb Susan Dittmar: Helping users with the day-to-day administrational work was the main reason why linux distributions have been invented. Well this may have been the reason. And this is also the reason why package managers like the one from miktex has been invented (and I like the ease with which I can install packages today.) But looking at the discussion here *now* package managers in Linux distros are meant to prevent users to do fatal damage to their system, to avoid dramatic security problems, to avert chaos. They are no longer mainly a help, they are a mean of control. It looks as if windows and linux have changed their roles: Long time windows users were the ones which were supposed to be so dump that they could only use applications which could be installed by simple click on a setup.exe and who must be protected from more complicated tasks. And everybody feared that windows would gain to much control over the applications installed on the user pc (microsoft got attacked when it dared to bundle a user application like the internet explorer with the OS). But now it looks as if the users of the so-called open and free OS Linux are tying themselves to their disto manufacturer and their installation tools in a way no windows user has ever been tyed to a windows OS. -- Ulrike Fischer -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Thu, Oct 20, 2011 at 6:16 AM, Ulrike Fischer ne...@nililand.de wrote: Am Thu, 20 Oct 2011 13:32:00 +0200 schrieb Susan Dittmar: Helping users with the day-to-day administrational work was the main reason why linux distributions have been invented. Well this may have been the reason. And this is also the reason why package managers like the one from miktex has been invented (and I like the ease with which I can install packages today.) Package managers have their roles to play. They are important for some users, less so for others. But looking at the discussion here *now* package managers in Linux distros are meant to prevent users to do fatal damage to their system, to avoid dramatic security problems, to avert chaos. They are no longer mainly a help, they are a mean of control. And in some environments that is a win. But keep in mind that none of these package managers are synonymous with repositories. I understand there are TexLive 2011 repos for my distro of Fedora but I can't develop on them because those are not available for RHEL 6. I don't know anyone who sticks with only the stock repositories. However, when a piece of software also may handle credit card data (which LedgerSMB sometimes does), the rules change very quickly. The credit card industry makes certain demands in exchange for the privilege to process cards, and one of these is to stick with software which gets security fixes from a vendor, and to stay current with all security updates. Saying that one should just install a new TexLive distro every year might not even meet those demands, esp. when everything is statically linked. It looks as if windows and linux have changed their roles: Long time windows users were the ones which were supposed to be so dump that they could only use applications which could be installed by simple click on a setup.exe and who must be protected from more complicated tasks. And everybody feared that windows would gain to much control over the applications installed on the user pc (microsoft got attacked when it dared to bundle a user application like the internet explorer with the OS). But now it looks as if the users of the so-called open and free OS Linux are tying themselves to their disto manufacturer and their installation tools in a way no windows user has ever been tyed to a windows OS. You know, above, I think I said that there are only two really acceptable ways to install lInux software: 1) Via the distro's package manager (whether from the distro's repo, from a third party repo, or third party download) or 2) Compiling from source. There are a lot of times when #2 makes more sense. However it makes PCI-DSS compliance quite a bit harder and more burdensome. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
I do not think, it makes any difference. -jobname=STRING set the job name to STRING -progname=STRINGset program (and fmt) name to STRING On Tue, Oct 18, 2011 at 9:18 PM, Philip TAYLOR (Webmaster, Ret'd) p.tay...@rhul.ac.uk wrote: Vafa Khalighi wrote: There are two ways to create xelatex.fmt: 1) xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini What does this accomplish that xetex -ini -etex xelatex.ini does not ? Philip Taylor -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 20.10.2011 um 13:24 schrieb Chris Travers: So if libz needs a security update, I can get it without replacing everything else What do you gain with that? What is the difference between overwriting 5 MB or 50 MB of disk space? -- Greetings Pete Bake pizza not war! -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
I do not think, it makes any difference. -jobname=STRING set the job name to STRING -progname=STRINGset program (and fmt) name to STRING -jobname doesn't make any difference because it's set from the base name of the first input (in that case, xelatex.ini), but -progname may make a difference to kpathsea (although it would really be far-fetched if it caused XeTeX to load a different latex.ltx -- but you never know...) Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/20 Chris Travers chris.trav...@gmail.com: On Thu, Oct 20, 2011 at 6:16 AM, Ulrike Fischer ne...@nililand.de wrote: Am Thu, 20 Oct 2011 13:32:00 +0200 schrieb Susan Dittmar: Helping users with the day-to-day administrational work was the main reason why linux distributions have been invented. Well this may have been the reason. And this is also the reason why package managers like the one from miktex has been invented (and I like the ease with which I can install packages today.) Package managers have their roles to play. They are important for some users, less so for others. Package managers are important. A few years ago I was accutomed to compiling SW from sources. It is easy for simple programs. However, try to compile a complex program as eg Gnome Subtitles. It is a very hard task. That's why I like package managers because I need not bother with complex dependencies. Or to be not so extremistic, perl-tk from CPAN does not work on RHEL distros because it is too new. You have to install older version of perl-tk by yum which works fine. It is quite normal in RHEL distros that there are additional repositories (EPEL, rpmfusion, ...). So why should we be fierced by TeX Live as another external system? But looking at the discussion here *now* package managers in Linux distros are meant to prevent users to do fatal damage to their system, to avoid dramatic security problems, to avert chaos. They are no longer mainly a help, they are a mean of control. And in some environments that is a win. But keep in mind that none of these package managers are synonymous with repositories. I understand there are TexLive 2011 repos for my distro of Fedora but I can't develop on them because those are not available for RHEL 6. I don't know anyone who sticks with only the stock repositories. However, when a piece of software also may handle credit card data (which LedgerSMB sometimes does), the rules change very quickly. The credit card industry makes certain demands in exchange for the privilege to process cards, and one of these is to stick with software which gets security fixes from a vendor, and to stay current with all security updates. Saying that one should just install a new TexLive distro every year might not even meet those demands, esp. when everything is statically linked. It looks as if windows and linux have changed their roles: Long time windows users were the ones which were supposed to be so dump that they could only use applications which could be installed by simple click on a setup.exe and who must be protected from more complicated tasks. And everybody feared that windows would gain to much control over the applications installed on the user pc (microsoft got attacked when it dared to bundle a user application like the internet explorer with the OS). But now it looks as if the users of the so-called open and free OS Linux are tying themselves to their disto manufacturer and their installation tools in a way no windows user has ever been tyed to a windows OS. You know, above, I think I said that there are only two really acceptable ways to install lInux software: 1) Via the distro's package manager (whether from the distro's repo, from a third party repo, or third party download) or 2) Compiling from source. There are a lot of times when #2 makes more sense. However it makes PCI-DSS compliance quite a bit harder and more burdensome. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 20.10.2011 um 13:32 schrieb Susan Dittmar: Could you tell me how to do that for openSUSE from the top of your head? No. I never created the specification for an RPM or DEB package in Linux (I think I edited a few of them). Once it's created the package manager will build the package and put it somewhere in the file system. Then you can use the same package package manager to install the package at the specified place in the file system. This sounds easy. (I'm performing a bit of DEB packaging in Mac OS X for the Fink package manager.) -- Greetings Pete Behold the warranty … the bold print giveth and the fine print taketh away. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Thu, Oct 20, 2011 at 6:55 AM, Peter Dyballa peter_dyba...@web.de wrote: Am 20.10.2011 um 13:24 schrieb Chris Travers: So if libz needs a security update, I can get it without replacing everything else What do you gain with that? What is the difference between overwriting 5 MB or 50 MB of disk space? U Not disturbing other dependencies that production software depends on. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 20.10.2011 um 16:12 schrieb Chris Travers: Not disturbing other dependencies that production software depends on. It can't. It does not carry shared libraries, DLLs, or such, that make ld_config or such go mad. TeX Live is like the universe: it's self-contained. And expanding... -- Greetings Pete I hope to die before I *have* to use Microsoft Word. - Donald E. Knuth, 2001-10-02 in Tübingen -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Thu, Oct 20, 2011 at 7:24 AM, Peter Dyballa peter_dyba...@web.de wrote: Am 20.10.2011 um 16:12 schrieb Chris Travers: Not disturbing other dependencies that production software depends on. It can't. It does not carry shared libraries, DLLs, or such, that make ld_config or such go mad. TeX Live is like the universe: it's self-contained. And expanding... One of the other commentors talks about documents that don't render on all versions of TexLive. If a client of mine is depending on this working, upgrading the various stuff from CTAN in order to get a security fix in an underlying program is a non-starter because it may break things, just as it breaks other documents. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Thu, Oct 20, 2011 at 04:24:47PM +0200, Peter Dyballa wrote: Am 20.10.2011 um 16:12 schrieb Chris Travers: Not disturbing other dependencies that production software depends on. It can't. It does not carry shared libraries, DLLs, or such, that make ld_config or such go mad. TeX Live is like the universe: it's self-contained. And expanding... And that's exactly what's wrong and what needs to be changed... -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am Thu, 20 Oct 2011 07:54:52 -0700 schrieb Chris Travers: It can't. It does not carry shared libraries, DLLs, or such, that make ld_config or such go mad. TeX Live is like the universe: it's self-contained. And expanding... One of the other commentors talks about documents that don't render on all versions of TexLive. If a client of mine is depending on this working, upgrading the various stuff from CTAN in order to get a security fix in an underlying program is a non-starter because it may break things, just as it breaks other documents. This scenario is very rare. I actually can remember only two cases when engine changes affected fatally documents: 1. When the TeXSystems changed from tex to pdftex as underlying engine some documents with faulty \ifpdf-test broke. 2. When for security settings writing access to parent/absolute pathes were restricted some document broke too. In both cases only badly written documents had problems. Beside this: If there is a security hole and if fixing it affects documents it doesn't matter who makes the fix: you get the problem anyway - the only way to avoid it is not to fix the security issue. Do you really suggest that users continue to work with a system which has a known security hole only to avoid trouble with some documents? -- Ulrike Fischer -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 20.10.2011 um 16:54 schrieb Chris Travers: One of the other commentors talks about documents that don't render on all versions of TexLive. If a client of mine is depending on this working, upgrading the various stuff from CTAN in order to get a security fix in an underlying program is a non-starter because it may break things, just as it breaks other documents. You're mixing up things! TeX is a set of a few binaries, some of them are the TeX engines (pdfTeX, XeTeX, LuaTeX, conTeXt). The majority of the TeX software are text files. If a change in a library is breaking the TeX engine, then the change itself is faulty. If you're using a TeX function (library call) of a future version of that software, then something has to fail. If you're using an old function (library call) that has been changed, then you can't assume something useful will happen to come out. -- Greetings Pete Life is the only flaw in an otherwise perfect nonexistence – Schopenhauer -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 20.10.2011 um 17:08 schrieb Petr Tomasek: And that's exactly what's wrong and what needs to be changed... Yes, I wouldn't stand the pain when the big rip will happen. This will feel like the middle ages. Before this we will get very bloated, which should hurt as well. I also prefer the big crash. -- Greetings Pete Debugging? Klingons do not debug! Our software does not coddle the weak. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
ConTeXt is not an engine but that is a format just like LaTeٓ is. On Fri, Oct 21, 2011 at 2:25 AM, Peter Dyballa peter_dyba...@web.de wrote: Am 20.10.2011 um 16:54 schrieb Chris Travers: One of the other commentors talks about documents that don't render on all versions of TexLive. If a client of mine is depending on this working, upgrading the various stuff from CTAN in order to get a security fix in an underlying program is a non-starter because it may break things, just as it breaks other documents. You're mixing up things! TeX is a set of a few binaries, some of them are the TeX engines (pdfTeX, XeTeX, LuaTeX, conTeXt). The majority of the TeX software are text files. If a change in a library is breaking the TeX engine, then the change itself is faulty. If you're using a TeX function (library call) of a future version of that software, then something has to fail. If you're using an old function (library call) that has been changed, then you can't assume something useful will happen to come out. -- Greetings Pete Life is the only flaw in an otherwise perfect nonexistence – Schopenhauer -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/20 Petr Tomasek toma...@etf.cuni.cz: On Thu, Oct 20, 2011 at 04:24:47PM +0200, Peter Dyballa wrote: Am 20.10.2011 um 16:12 schrieb Chris Travers: Not disturbing other dependencies that production software depends on. It can't. It does not carry shared libraries, DLLs, or such, that make ld_config or such go mad. TeX Live is like the universe: it's self-contained. And expanding... And that's exactly what's wrong and what needs to be changed... If expansion is wrong that all SW is wrong. But seriously, I remember situation when documents that compiled on MiKTeX in Windows and on emTeX in OS/2 did not compile on teTeX in Linux because a lot of packages were missing. A Linux user was forced to download them from CTAN and install. There was no update mechanism, users were force to follow ctan-ann and install new versions themselves. The situation has not improved much. TeX documents are said to compile on any platform but it is not true. You can compile documents on Windows, on Mac, on OS/2 but if you stick with TeX from a Linux distro, you may have problems that packages will be missing or obsolete or buggy and not fixed although the new version was released years ago. If RHEL user reports me that my package does not work with natbib, what should I advice? It was fixed in 2008 but he uses an obsolete version. TeX Live offers a stable multiplatform solution. I would not believe that in each distro they develop their own kernel, their own HW drivers, their own GTK, their own TCP/IP stack, their own web browsers. I have never heard of Debian/Mozilla, Fedora/Mozilla, Mandriva/Mozilla etc. So why linux distros cannot incorporate TeX Live? Why everybody wants to repeat the job his/her own way but terribly delayed? I know it should be reported on the distros bugzillas, not here... -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
... offers a stable multiplatform solution. I would not believe that in each distro they develop their own kernel, their own HW drivers, their own GTK, their own TCP/IP stack, their own web browsers. I have never heard of Debian/Mozilla, Fedora/Mozilla, Mandriva/Mozilla etc. So why linux distros cannot incorporate TeX Live? The reason is exactly that TeX-Live is (Linux-)distros unfriendly as it is not easily to package it for a particular Linux distribution (and the main reason is that it tries to duplicate things that should be done on system level - like the package management). Why everybody wants to repeat the job his/her own way but terribly delayed? I know it should be reported on the distros bugzillas, not here... -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Petr Tomasek wrote: The reason is exactly that TeX-Live is (Linux-)distros unfriendly as it is not easily to package it for a particular Linux distribution (and the main reason is that it tries to duplicate things that should be done on system level - like the package management). And to which package management suite would you suggest they delegate when offering TeX Live for Windows ? Philip Taylor -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Thu, Oct 20, 2011 at 09:30:29PM +0100, Philip TAYLOR (Webmaster, Ret'd) wrote: Petr Tomasek wrote: The reason is exactly that TeX-Live is (Linux-)distros unfriendly as it is not easily to package it for a particular Linux distribution (and the main reason is that it tries to duplicate things that should be done on system level - like the package management). And to which package management suite would you suggest they delegate when offering TeX Live for Windows ? Philip Taylor Frankly, I don't care. But it shouldn't it be too hard to make a build system which would generate native packages for the more developed systems having a good package management system themselves (like various Linux distributions ;-) and shiping own package management for the dummier OSes ;-) P.T. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/20 Petr Tomasek toma...@etf.cuni.cz: ... offers a stable multiplatform solution. I would not believe that in each distro they develop their own kernel, their own HW drivers, their own GTK, their own TCP/IP stack, their own web browsers. I have never heard of Debian/Mozilla, Fedora/Mozilla, Mandriva/Mozilla etc. So why linux distros cannot incorporate TeX Live? The reason is exactly that TeX-Live is (Linux-)distros unfriendly as it is not easily to package it for a particular Linux distribution (and the main reason is that it tries to duplicate things that should be done on system level - like the package management). TeX Live fills the gap. Now it seems that up-to-date packages may be available for Fedora but before TL there was no systematic packaging for Linux distros although TeX exists for decades, CTAN exists, if I remember it well, for almost 20 years. Yet the Linux distributers did not create packaging scheme, teTeX was just a small subset. The userscould install the basic system and then were forced to grab packages from CTAN, without any packaging, without any manager being aware of the users do, and moreover the dependencies were unknown so that users were forced to grab packages by trials and errors. TeX Live is an external tool but it _does_ provide packaging, updates etc. Why everybody wants to repeat the job his/her own way but terribly delayed? I know it should be reported on the distros bugzillas, not here... -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
the universe: it's self-contained. And expanding... And that's exactly what's wrong and what needs to be changed... It will be hard to stop the universe expanding. We might try to get the UN Security Council vote on that, though. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Please don't be so dogmatic, Petr. TeXlive works just fine for many people, including myself. In fact, much better than any Linux distribution's TeX packages would. For many others it might be the other way round. Jan Foniok -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Thu, Oct 20, 2011 at 8:25 AM, Peter Dyballa peter_dyba...@web.de wrote: Am 20.10.2011 um 16:54 schrieb Chris Travers: One of the other commentors talks about documents that don't render on all versions of TexLive. If a client of mine is depending on this working, upgrading the various stuff from CTAN in order to get a security fix in an underlying program is a non-starter because it may break things, just as it breaks other documents. You wrote: You're mixing up things! TeX is a set of a few binaries, some of them are the TeX engines (pdfTeX, XeTeX, LuaTeX, conTeXt). The majority of the TeX software are text files. If a change in a library is breaking the TeX engine, then the change itself is faulty. If you're using a TeX function (library call) of a future version of that software, then something has to fail. If you're using an old function (library call) that has been changed, then you can't assume something useful will happen to come out. My reply: I'm not the one mixing things up. What I am saying is perhaps a bit different. If you are tying the .sty upgrades to binary upgrades, then an upgrade in a binary requires .sty upgrades, and these can break document generation systems. Think about it this way. Suppose you are doing magazine layout in LaTeX. You start with open ended problems. You can pursue all sorts of courses in solving them. You want up to date packages which have as few bugs that other people have run into as possible. I think we all agree on that. However, suppose you have a piece of software that generates documents in LaTeX. This design is done once and thereafter it is run in a predictable fashion. Once you have done your testing, you can assume that barring unexpected and invalid inputs on the part of a user, it will function correctly forever. Note the user here isn't writing LaTeX documents. The user is just doing data entry, so all input can be sanitized of LaTeX commands. Consequently, predictability is key here, and the last thing you want done is to change the behavior under the program just because another more important upgrade needs it. The needs in this environment are completely different from the needs of the LaTeX user. So what sorts of fixes does the latter environment need? Well, let me make up a hypthetical security vulnerability-- keep in mind this software is not running on the user's system. Suppose a vulnerability is found where if a user sends in a specific UTF-16 string and the software expects UTF-8, that it causes a buffer overflow somewhere (this can happen because UTF-16 strings sometimes contain null bytes while UTF-8 can still use null bytes as string terminators), and this allows an attacker to now run arbitrary code on the server. Let's say furthermore that the problem isn't with LaTeX but with some other library it is linked to. Now, if you are a LaTeX user, and on a workstation, then this is an important security fix, and there is little harm in updating everything in TexLive. But if you are doing stuff on a server, this is a critical fix, and you definitely don't want to be updating unrelated stuff at the same time. Hope this helps, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Oct 20, 2011, at 5:51 PM, Chris Travers wrote: On Thu, Oct 20, 2011 at 8:25 AM, Peter Dyballa peter_dyba...@web.de wrote: Am 20.10.2011 um 16:54 schrieb Chris Travers: One of the other commentors talks about documents that don't render on all versions of TexLive. If a client of mine is depending on this working, upgrading the various stuff from CTAN in order to get a security fix in an underlying program is a non-starter because it may break things, just as it breaks other documents. You wrote: You're mixing up things! TeX is a set of a few binaries, some of them are the TeX engines (pdfTeX, XeTeX, LuaTeX, conTeXt). The majority of the TeX software are text files. If a change in a library is breaking the TeX engine, then the change itself is faulty. If you're using a TeX function (library call) of a future version of that software, then something has to fail. If you're using an old function (library call) that has been changed, then you can't assume something useful will happen to come out. My reply: I'm not the one mixing things up. What I am saying is perhaps a bit different. If you are tying the .sty upgrades to binary upgrades, then an upgrade in a binary requires .sty upgrades, and these can break document generation systems. Think about it this way. Suppose you are doing magazine layout in LaTeX. You start with open ended problems. You can pursue all sorts of courses in solving them. You want up to date packages which have as few bugs that other people have run into as possible. I think we all agree on that. However, suppose you have a piece of software that generates documents in LaTeX. This design is done once and thereafter it is run in a predictable fashion. Once you have done your testing, you can assume that barring unexpected and invalid inputs on the part of a user, it will function correctly forever. Note the user here isn't writing LaTeX documents. The user is just doing data entry, so all input can be sanitized of LaTeX commands. Consequently, predictability is key here, and the last thing you want done is to change the behavior under the program just because another more important upgrade needs it. The needs in this environment are completely different from the needs of the LaTeX user. So what sorts of fixes does the latter environment need? Well, let me make up a hypthetical security vulnerability-- keep in mind this software is not running on the user's system. Suppose a vulnerability is found where if a user sends in a specific UTF-16 string and the software expects UTF-8, that it causes a buffer overflow somewhere (this can happen because UTF-16 strings sometimes contain null bytes while UTF-8 can still use null bytes as string terminators), and this allows an attacker to now run arbitrary code on the server. Let's say furthermore that the problem isn't with LaTeX but with some other library it is linked to. Now, if you are a LaTeX user, and on a workstation, then this is an important security fix, and there is little harm in updating everything in TexLive. But if you are doing stuff on a server, this is a critical fix, and you definitely don't want to be updating unrelated stuff at the same time. Hope this helps, Chris Travers Howdy, I'm not at all sure I understand what you're getting at but I'm interested in understanding it. Can you give an example where something like what you hypothesize in the last paragraph has happened with the binaries or packages supplied with TeX Live? Another thing I don't is that you refer to LaTeX as library that one links to while I've always just considered it as a macro packages that builds upon the ~300 or so built-in low level commands supplied by TeX (and other engines that pass the trip test) to build a higher level language closer to the way people deal with documents. Good Luck, Herb Schulz (herbs at wideopenwest dot com) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Thu, Oct 20, 2011 at 4:07 PM, Herbert Schulz he...@wideopenwest.com wrote: Howdy, I'm not at all sure I understand what you're getting at but I'm interested in understanding it. Can you give an example where something like what you hypothesize in the last paragraph has happened with the binaries or packages supplied with TeX Live? Another thing I don't is that you refer to LaTeX as library that one links to while I've always just considered it as a macro packages that builds upon the ~300 or so built-in low level commands supplied by TeX (and other engines that pass the trip test) to build a higher level language closer to the way people deal with documents. TexLive isn't old enough for the major vulnerabilities in dependencies that come to mind to affect it. So it hasn't happened yet. But something similar would have affected the statically linked binaries if TexLive was available in 2001-2002. What happened then is a cautionary tale about the evils of static linking. At the time a large portion of the industry was writing software statically linked against zlib (which btw, LaTeX and XeTeX both link against, so if the TexLive stuff is statically linked, it would be in the same category), which is used for a number of compression and decompression routines. Nobody thought anything of it. The code was believed to be secure, and to perform better when statically linked, so everybody did it. Then a vulnerability was discovered (http://www.cert.org/advisories/CA-2002-07.html). It seemed that if certain improper data was fed to zlib, one could tamper with proper allocation and de-allocation of memory, causing programs to crash or, at least in theory, insert arbitrary executable commands into a running program on a binary level. Now *everybody* had to issue security patches. Because so much was statically linked to zlib, however, it wasn't enough to just update the library. One had to install patched versions of the software. If you were on Linux, it was surprising the number of packages that had to be updated, all because of a glitch in *one* library. If you were on Windows, you weren't spared either. A lot of Microsoft software was statically linked to the library, meaning Windows Update went crazy (I was working at Microsoft's Product Support Services at the time and I remember this distinctly). If TexLive had been around in 2002 and was statically linking to zlib, it would have been affected too. TeX does not link against zlib but LaTeX and XeTeX do. Similarly, arbitrary code execution vulnerabilities have been found in 2005 in libjpeg (also linked to by LaTeX and XeTeX). Again these predate TexLive. So my answer is that TexLive binaries, distributed as they currently are, are simply too young to have hit the major cases of these problems so far. However, the library dependencies are anything but trivial-- ldd gives me 17 libraries that xetex is linked against and 15 that latex is linked against. It seems for those of us with a longer memory, extensive static linking is asking for trouble Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Oct 20, 2011, at 6:42 PM, Chris Travers wrote: On Thu, Oct 20, 2011 at 4:07 PM, Herbert Schulz he...@wideopenwest.com wrote: Howdy, I'm not at all sure I understand what you're getting at but I'm interested in understanding it. Can you give an example where something like what you hypothesize in the last paragraph has happened with the binaries or packages supplied with TeX Live? Another thing I don't is that you refer to LaTeX as library that one links to while I've always just considered it as a macro packages that builds upon the ~300 or so built-in low level commands supplied by TeX (and other engines that pass the trip test) to build a higher level language closer to the way people deal with documents. TexLive isn't old enough for the major vulnerabilities in dependencies that come to mind to affect it. So it hasn't happened yet. But something similar would have affected the statically linked binaries if TexLive was available in 2001-2002. What happened then is a cautionary tale about the evils of static linking. At the time a large portion of the industry was writing software statically linked against zlib (which btw, LaTeX and XeTeX both link against, so if the TexLive stuff is statically linked, it would be in the same category), which is used for a number of compression and decompression routines. Nobody thought anything of it. The code was believed to be secure, and to perform better when statically linked, so everybody did it. Then a vulnerability was discovered (http://www.cert.org/advisories/CA-2002-07.html). It seemed that if certain improper data was fed to zlib, one could tamper with proper allocation and de-allocation of memory, causing programs to crash or, at least in theory, insert arbitrary executable commands into a running program on a binary level. Now *everybody* had to issue security patches. Because so much was statically linked to zlib, however, it wasn't enough to just update the library. One had to install patched versions of the software. If you were on Linux, it was surprising the number of packages that had to be updated, all because of a glitch in *one* library. If you were on Windows, you weren't spared either. A lot of Microsoft software was statically linked to the library, meaning Windows Update went crazy (I was working at Microsoft's Product Support Services at the time and I remember this distinctly). If TexLive had been around in 2002 and was statically linking to zlib, it would have been affected too. TeX does not link against zlib but LaTeX and XeTeX do. ... Howdy, Of course the reverse could just as likely happen. Some binary is statically linked to a perfectly stable zlib and along comes a new zlib that turns out, unknowingly for a long time, to have vulnerabilities so all binaries that are dynamically linked to zlib are now, unknowingly, vulnerable. Also, you say ``TeX does not link against zlib but LaTeX and XeTeX do'' and I don't understand that since LaTeX is simply a macro package that sits on top of TeX and isn't linked to anything like zlib as far as I know. XeTeX is an engine but I don't know what it's linked to. Good Luck, Herb Schulz (herbs at wideopenwest dot com) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Hi Herb, On 21/10/2011, at 6:47 AM, Herbert Schulz wrote: If TexLive had been around in 2002 and was statically linking to zlib, it would have been affected too. TeX does not link against zlib but LaTeX and XeTeX do. ... Howdy, Also, you say ``TeX does not link against zlib but LaTeX and XeTeX do'' and I don't understand that since LaTeX is simply a macro package that sits on top of TeX and isn't linked to anything like zlib as far as I know. XeTeX is an engine but I don't know what it's linked to. The binary called 'latex' is actually a (hard or soft) link to the underlying binary named 'pdftex'. This is what is statically linked to 'zlib'. It is a different binary to 'xetex', so his statements make perfect sense, from this (very pragmatic) point of view. But yes, I had to think about it a bit, before being confident about what was being said. Good Luck, Herb Schulz (herbs at wideopenwest dot com) Cheers from Kerala. Ross Ross Moore ross.mo...@mq.edu.au Mathematics Department office: E7A-419 Macquarie University tel: +61 (0)2 9850 8955 Sydney, Australia 2109 fax: +61 (0)2 9850 8114 -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am Tue, 18 Oct 2011 07:39:06 -0700 schrieb Chris Travers:
So the limit is five years (but only for the latex kernel).
The version date of my (current) latex.ltx ist
\edef\fmtversion{2011/06/27}
Or is XeTeX not intended to be used in these environments?
I would say that if your latex is more than five years old, your
xetex binaries and packages aren't up-to-date either. And as xetex
is rather young this can be quite a problem. Regardless if you want
to ship out only xetex documents or xetex documents + binaries: You
should be aware that other people can have up-to-date systems and so
you should make tests on such systems too (and just in case you
don't know: you can't use a fmt generated by one xetex version with
another xetex version).
Of course. I don't expect .fmt files to be portable. What is helpful
is to know how to resolve the issue so I can put a faq entry in and
direct people to it when they ask on the mailing list. (And if they
can't get it, charge for support.) I believe I have gotten that, so I
am satisfied with the resolution.
However, so that there are no misunderstandings The issue here
is being forced to choose between supporting XeTeX on many platforms
and being able to support the platform's package manager. I don't see
anyone here suggesting a way around that. For developers distributing
software, that's kind of an issue.
The problem is that there seems to a mounting number on Linux users
which are reluctant to install software without using there package
manager. And there seems to be a mounting number of maintainers of
linux distros (there just was a quite heated discussion in d.c.t.t.)
which enforce this reluctance by telling people that they set their
system at risk if they install e.g. a new TeXLive without using the
disto package manager.
On the other side the linux distros seems to be either unwilling or
unable to update the packages they support. Your list is quite
impressing in this respect:
Debian Lenny: TexLive 2007
Debian Squeeze: TexLive 2009
Debian Sid: TexLive 2009
Ubuntu 10.04 LTS: TexLive 2009
Red Hat Enterprise 6: TexLive 2007
That means that the most recent versions of CentOS and Scientific
Linux also use 2007.
This is all (partly horribly) outdated. The current TeXLive version
is 2011 and they are currently working on 2012.
As the maintainer of the KOMA-packages pointed out this makes
support rather difficult: He constantly gets reports about bugs
which have been resolved years ago.
What would you think of a linux distro which would force you to use
a virus protection software with signature files five years old?
However, the software project has contributors on both TexLive 2007
and 2009, and so our coverage in terms of testing is pretty good
there.
2009 is outdated. As you could see from the answers here quite a lot
people did install texlive 2011.
--
Ulrike Fischer
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/19 Ulrike Fischer ne...@nililand.de:
Am Tue, 18 Oct 2011 07:39:06 -0700 schrieb Chris Travers:
So the limit is five years (but only for the latex kernel).
The version date of my (current) latex.ltx ist
\edef\fmtversion{2011/06/27}
Or is XeTeX not intended to be used in these environments?
I would say that if your latex is more than five years old, your
xetex binaries and packages aren't up-to-date either. And as xetex
is rather young this can be quite a problem. Regardless if you want
to ship out only xetex documents or xetex documents + binaries: You
should be aware that other people can have up-to-date systems and so
you should make tests on such systems too (and just in case you
don't know: you can't use a fmt generated by one xetex version with
another xetex version).
Of course. I don't expect .fmt files to be portable. What is helpful
is to know how to resolve the issue so I can put a faq entry in and
direct people to it when they ask on the mailing list. (And if they
can't get it, charge for support.) I believe I have gotten that, so I
am satisfied with the resolution.
However, so that there are no misunderstandings The issue here
is being forced to choose between supporting XeTeX on many platforms
and being able to support the platform's package manager. I don't see
anyone here suggesting a way around that. For developers distributing
software, that's kind of an issue.
The problem is that there seems to a mounting number on Linux users
which are reluctant to install software without using there package
manager. And there seems to be a mounting number of maintainers of
linux distros (there just was a quite heated discussion in d.c.t.t.)
which enforce this reluctance by telling people that they set their
system at risk if they install e.g. a new TeXLive without using the
disto package manager.
On the other side the linux distros seems to be either unwilling or
unable to update the packages they support. Your list is quite
impressing in this respect:
Debian Lenny: TexLive 2007
Debian Squeeze: TexLive 2009
Debian Sid: TexLive 2009
Ubuntu 10.04 LTS: TexLive 2009
Red Hat Enterprise 6: TexLive 2007
That means that the most recent versions of CentOS and Scientific
Linux also use 2007.
This is all (partly horribly) outdated. The current TeXLive version
is 2011 and they are currently working on 2012.
As the maintainer of the KOMA-packages pointed out this makes
support rather difficult: He constantly gets reports about bugs
which have been resolved years ago.
What would you think of a linux distro which would force you to use
a virus protection software with signature files five years old?
This is not only a question of TeX. Years ago I found and reported a
bug in Ghostscript. This bug was triggered mainly by the PS files
created by dvips. The bug was quickly fixed yet RHEL based distros for
a few more years distributed that old buggy version.
The problem with old TeX distro is apparent if I receive a document
prepared originally by MiKTeX. MiKTeX is updated regularly and if it
makes use of a rapidly evolving package as TikZ, it cannot be
processed by an old TeX. TL 2009 is definitely outdated and unusable
for such documents. TeX Live 2010 is still quite new and can be used
for most tasks. For serious work with colleagues using other platforms
up-to-date TeX Live is important.
However, the software project has contributors on both TexLive 2007
and 2009, and so our coverage in terms of testing is pretty good
there.
2009 is outdated. As you could see from the answers here quite a lot
people did install texlive 2011.
--
Ulrike Fischer
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
--
Zdeněk Wagner
http://hroch486.icpf.cas.cz/wagner/
http://icebearsoft.euweb.cz
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
A few thoughts here as to where I think solutions lie. On Wed, Oct 19, 2011 at 12:53 AM, Ulrike Fischer ne...@nililand.de wrote: The problem is that there seems to a mounting number on Linux users which are reluctant to install software without using there package manager. And there seems to be a mounting number of maintainers of linux distros (there just was a quite heated discussion in d.c.t.t.) which enforce this reluctance by telling people that they set their system at risk if they install e.g. a new TeXLive without using the disto package manager. On the other side the linux distros seems to be either unwilling or unable to update the packages they support. Your list is quite impressing in this respect: Debian Lenny: TexLive 2007 Debian Squeeze: TexLive 2009 Debian Sid: TexLive 2009 Ubuntu 10.04 LTS: TexLive 2009 Red Hat Enterprise 6: TexLive 2007 That means that the most recent versions of CentOS and Scientific Linux also use 2007. This is all (partly horribly) outdated. The current TeXLive version is 2011 and they are currently working on 2012. And obviously this puts a lot us in bad positions. If RHEL 6 (released about a year ago) is sticking to TeXLive 2007, we all have problems. The question is what the community can reasonably do, and what developers can be expected to do navigating these issues. Obviously developers who want to accommodate the users who are unwilling to install software outside their package manager will need to make some choices in order to do so. On the other a very short support cycle doesn't give sufficient time for packages to make it through the packaging and testing processes and thus be considered in time, so I think this means some compromises on all sides to some extent. So here are some expectations on all sides that I think are reasonable, that I suspect perhaps with some modifications, might help us all out. 1) Package maintainers for distros should be the point of contact for bug reports for their packages. Even in the best of circumstances there is a lag between the release of a bug fix and when it gets into a repo. I know I have filed my share of bug reports for Fedora packages (including Fedora TeXLive packages). 2) Developers of higher-stack applications who use distro packages (like myself) are going to have to content ourselves with stable subsets of functionality. There are no two ways about it. The templates LedgerSMB ships with are not going to be fancy.Bugs will be expected to be worked around rather than reported to the developers, and if they are reported it's to the package managers. 3) Finally, I don't think it's too much to ask that time-based warnings (as I ran into) trigger warnings in the software rather than disabling it. This isn't a bug report yet btw because I haven't been able to verify it against up to date versions yet. I also think a reasonable response to many issues is this has been fixed in more recent versions, here's a work around if people care to volunteer. As the maintainer of the KOMA-packages pointed out this makes support rather difficult: He constantly gets reports about bugs which have been resolved years ago. Heck, I get that with LedgerSMB :-P. What would you think of a linux distro which would force you to use a virus protection software with signature files five years old? I wouldn't think much of a linux distro that asked me to use virus protection software. So maybe not the best example. And moreover we aren't talking about the signature files are we, here? We're talking about core utilities which are essentially disabled after five years. If I verify it on TeXLive 2011, I'll report it as a bug. Until then it's a serious annoyance with an older version. However, the software project has contributors on both TexLive 2007 and 2009, and so our coverage in terms of testing is pretty good there. 2009 is outdated. As you could see from the answers here quite a lot people did install texlive 2011. Maybe, but these are the two that most distros probably are going to come with. Yes, it's possible to update to 2011 on Fedora using RPMs but generally accounting software we like to put on long term support versions, which means Debian Stable, Ubuntu LTS, and RHEL (and friends). Generally speaking many of my clients may have requirements that their operating systems are currently supported (for example, due to credit card security requirements, such as the PCI-DSS), and the like. Ensuring that things are running supported versions is a concern and something that frequently is easiest to demonstrate when using a long-term support distro and the package manager. So... Where does that leave everything? With a big mess, naturally. However, it's perfectly reasonable that Debian Stable will be out of date by a few years, as it is with every other LTS distro out there. I think you have to figure that by the time the distro is released, it will be
Re: [XeTeX] How to manually create the xelatex.fmt?
Am Wed, 19 Oct 2011 03:19:48 -0700 schrieb Chris Travers: And obviously this puts a lot us in bad positions. If RHEL 6 (released about a year ago) is sticking to TeXLive 2007, we all have problems. The question is what the community can reasonably do, and what developers can be expected to do navigating these issues. Well I'm a windows user so actually I'm not really affected. But imho the linux distros should rethink their installation methods and installation advices. It is absurd that 10 or more distros invest a lot of main power in making packages when they lack the main power to keep them up-to-date. What would you think of a linux distro which would force you to use a virus protection software with signature files five years old? And moreover we aren't talking about the signature files are we, here? We're talking about core utilities which are essentially disabled after five years. No I really meant signature files. You don't have a problems with the binaries but only with the (text)-files of the latex kernel. Probably you only need a new latex.ltx, perhaps also a small number of other files from latex/base (the unpackaged files are in ftp://dante.ctan.org/tex-archive/macros/latex/unpacked/) -- Ulrike Fischer -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Wed, Oct 19, 2011 at 4:45 AM, Ulrike Fischer ne...@nililand.de wrote: Well I'm a windows user so actually I'm not really affected. But imho the linux distros should rethink their installation methods and installation advices. It is absurd that 10 or more distros invest a lot of main power in making packages when they lack the main power to keep them up-to-date. Actually, for being a long-term support distro, Debian (using TexLive 2009) is about as up to date as you will find. Here's the reason for this. You may not agree with it but for those of us who do server programming it makes a *tremendous* amount of sense on the server side. The basic thing is that servers generally require stability because an introduced bug can affect large numbers of users simultaneously. Consequently, the way Debian does this is by running unstable versions, that graduate to testing version, which graduate to stable versions, often over a period of a couple several years. This gives early adopters an opportunity to shake out issues, and then by the time folks are deploying critical servers, the issues, limitations, etc. are well known, tested and documented, and they're not going to introduce new bugs by upgrading out from under the applications. This is important in this environment. Long term support distros (Ubuntu LTS, RHEL, Debian) tend to backport fixes for critical bugs to earlier versions where required so the software is still supported. This is one reason why which distro of TexLive is being used can be misleading. One doesn't really know what's been backported or not. This matches my needs very well. If my clients are running accounting systems, the last thing I want is an upgrade of TexLive to break their ability to generate invoices. If there are bugs in older versions, I can work around those bugs, but the problem of getting a document that will only render with one version or another is not acceptable to my application. Consequently I stick with older, solid packages, avoid cutting edge ones (exception currently being XeTeX for a subset of users, and that's only due to issues of i18n in the invoice templates, which generally causes pdflatex to croak). So this is where I am coming from. I am happy with workarounds. Not happy with you must upgrade every couple years. Upgrades must, under no circumstances, break the accounting software, and if that means many bugs go unfixed, that's what that means. Generally speaking that means that bugs get fixed only if the maintainers conclude that the fix is backwards compatible, and that the bugfix is sufficiently non-intrusive that the chance of introducing new problems is minimal. I have already heard that this is anything but the policy of Texlive (which has other advantages, but not for the environments I work in). As a Windows user, I suspect you are thinking of desktop needs. That's fine. A lot of people use the Tex stuff as essentially desktop publishing. But there are others of us who build fairly critical systems using this and we have greatly increased needs for stability. It's one thing if a magazine, a school paper, or a book won't render because of an upgrade. It's a very different thing when a weekly batch of checks you promised your clients would be mailed out *that day* fails at 1pm in the afternoon because something changed in one of the Tex packages you use to generate the checks and now someone has to fix it in time to mail them out. The way you guarantee that is by making sure it works and not touching the underlying dependencies unless you absolutely must. The fact that they are outdated makes no difference. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am Wed, 19 Oct 2011 05:59:16 -0700 schrieb Chris Travers: This matches my needs very well. If my clients are running accounting systems, the last thing I want is an upgrade of TexLive to break their ability to generate invoices. Normally you get more problems if you can't update ;-) If there are bugs in older versions, I can work around those bugs, but the problem of getting a document that will only render with one version or another is not acceptable to my application. Then you shouldn't rely on an external TeXLive installation. You have absolutly no control on the status of the TeXLive installations of your users. You don't know if the fedora user installed the fedora-TeXLive or the newest shapshot from the svn. You also have no control about the package versions installed by the users. fontspec e.g. can be an old version, the current version on CTAN or the unstable version from Github. -- Ulrike Fischer -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 19.10.2011 um 12:19 schrieb Chris Travers: If RHEL 6 (released about a year ago) is sticking to TeXLive 2007, we all have problems. The only problem is that of understanding. It's like the fifth wheel or the tool to change wheels that come with new car. They're not really usable, they're more kind of alibis. And that's the situation of TeX in Linux. Because it's not necessary to build a second rail of distribution via DEB or RPM packages. TeX Live comes with its own package manager and in packages and in meta-packages. Use this opportunity! In Mac OS X, Solaris, MS Windows we have the freedom to use third parties as suppliers of software packages. It's time that Linux grows up to that level. Even when it becomes complicated for the users and administrators to send bug reports to a thousand authors of TeX Live packages. Have you thought of keeping exactly one (maybe only virtual) alibi server with long-term support software? In case someone asks you have something to present... (and when it's virtual you can easily add some CPU power and/or disk space, if needed) BTW, the packages supplied by CTAN are *stable* packages. (It's also possible to get preliminary test software.) -- Greetings Pete Hard Disk, n.: A device that allows users to delete vast quantities of data with simple mnemonic commands. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Wed, Oct 19, 2011 at 6:20 AM, Ulrike Fischer ne...@nililand.de wrote: Am Wed, 19 Oct 2011 05:59:16 -0700 schrieb Chris Travers: This matches my needs very well. If my clients are running accounting systems, the last thing I want is an upgrade of TexLive to break their ability to generate invoices. Normally you get more problems if you can't update ;-) You get more problems with things suddenly and unexpectedly breaking if you don't change them? On what theory? At least if you don't include deliberate breakage of programs over a certain age.. If there are bugs in older versions, I can work around those bugs, but the problem of getting a document that will only render with one version or another is not acceptable to my application. Then you shouldn't rely on an external TeXLive installation. You have absolutly no control on the status of the TeXLive installations of your users. You don't know if the fedora user installed the fedora-TeXLive or the newest shapshot from the svn. You also have no control about the package versions installed by the users. fontspec e.g. can be an old version, the current version on CTAN or the unstable version from Github. I think you may misunderstand how this works. We have some (relatively basic) demo templates. They are tested on TeXLive 2007 and 2009 at present and known to render properly. They don't use a whole lot of packages (I think mostly longtable, geometry, and a few others). These are designed to give people a sense of what they can do but not necessarily provide exactly what they need. The client then can contract with me or others to write templates in the environment of their choice. That may be TeTeX (RHEL 5), TexLive 2007 (RHEL 6 and friends), TexLive (Debian Stable and friends), it could be a shiney new TexLive. It could be MikTeX. It could be whatever. These documents are then tested on these environments and verified to work reliably and predictably. The software then plugs text into the templates and runs them. These then run reliably as long as nothing changes. If someone is going to upgrade TexLive, the templates have to be tested again, against the new version. That usually means a staging server is updated first, the templates tested, and then the update rolled out to production when it is verified not to cause problems. This is a very slow, deliberate process, as it should be. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/19 Chris Travers chris.trav...@gmail.com: On Wed, Oct 19, 2011 at 4:45 AM, Ulrike Fischer ne...@nililand.de wrote: Well I'm a windows user so actually I'm not really affected. But imho the linux distros should rethink their installation methods and installation advices. It is absurd that 10 or more distros invest a lot of main power in making packages when they lack the main power to keep them up-to-date. Actually, for being a long-term support distro, Debian (using TexLive 2009) is about as up to date as you will find. Here's the reason for this. You may not agree with it but for those of us who do server programming it makes a *tremendous* amount of sense on the server side. The basic thing is that servers generally require stability because an introduced bug can affect large numbers of users simultaneously. Consequently, the way Debian does this is by running unstable versions, that graduate to testing version, which graduate to stable versions, often over a period of a couple several years. This gives early adopters an opportunity to shake out issues, and then by the time folks are deploying critical servers, the issues, limitations, etc. are well known, tested and documented, and they're not going to introduce new bugs by upgrading out from under the applications. This is important in this environment. Long term support distros (Ubuntu LTS, RHEL, Debian) tend to backport fixes for critical bugs to earlier versions where required so the software is still supported. This is one reason why which distro of TexLive is being used can be misleading. One doesn't really know what's been backported or not. This matches my needs very well. If my clients are running accounting systems, the last thing I want is an upgrade of TexLive to break their ability to generate invoices. If there are bugs in older versions, I can work around those bugs, but the problem of getting a document that will only render with one version or another is not acceptable to my application. Consequently I stick with older, solid packages, avoid cutting edge ones (exception currently being XeTeX for a subset of users, and that's only due to issues of i18n in the invoice templates, which generally causes pdflatex to croak). I need stability and I cannot affoard if TL upgrade breaks my documents. That's why I use as few packages as possible. I write my own macros, my own packages. I will guarantee that eg zwpagelayout will always be backward compatible (otherwise my documents will cease to work) but due to conflicts with some packages I will soon released and improved version that will need at least TL2008. XeTeX depends on the platform fonts. Once I cooperated with a man working on Mac. The document was written in XeLaTeX and used DejaVu fonts. Mac had a different version of DejaVu fonts and the result was that the document was one page shorter on Linux than on Mac. Thus you may have different results on different Linux distros. So this is where I am coming from. I am happy with workarounds. Not happy with you must upgrade every couple years. Upgrades must, under no circumstances, break the accounting software, and if that means many bugs go unfixed, that's what that means. Generally speaking that means that bugs get fixed only if the maintainers conclude that the fix is backwards compatible, and that the bugfix is sufficiently non-intrusive that the chance of introducing new problems is minimal. I have already heard that this is anything but the policy of Texlive (which has other advantages, but not for the environments I work in). TeX Live packages what is available on CTAN. Anyway, if you need a stable version of a package no matter whether in is upgraded on TL or not, you can install it in another directory (not known to TL) and you accounting SW can set TEXINPUT so that TeX running from it will first look there and then to the TL tree. That's what I do in my accounting SW. As a Windows user, I suspect you are thinking of desktop needs. That's fine. A lot of people use the Tex stuff as essentially desktop publishing. But there are others of us who build fairly critical systems using this and we have greatly increased needs for stability. It's one thing if a magazine, a school paper, or a book won't render because of an upgrade. It's a very different thing when a weekly batch of checks you promised your clients would be mailed out *that day* fails at 1pm in the afternoon because something changed in one of the Tex packages you use to generate the checks and now someone has to fix it in time to mail them out. The way you guarantee that is by making sure it works and not touching the underlying dependencies unless you absolutely must. The fact that they are outdated makes no difference. The solution is to use as few packages as possible and make your own copies of important packages if you are afraid that an upgrade may do any harm. Best
Re: [XeTeX] How to manually create the xelatex.fmt?
On 19/10/2011 14:53, Chris Travers wrote: You get more problems with things suddenly and unexpectedly breaking if you don't change them? On what theory? At least if you don't include deliberate breakage of programs over a certain age.. The 'expiry date' in LaTeX2e was there for good reasons, and reflected a desire to avoid buggy and out-of-date software remaining 'in use' for too long. However, the situation has changed more recently, as updates to LaTeX2e have become very rare and the 'expiry date' was no longer appropriate. The latest LaTeX2e release no longer includes an expiry date. Clearly, there is not much that can be done directly about the older version: if you have it, your options are to update at least that file (latex.ltx), or has been suggested earlier to temporarily 'mess about' with your system date. -- Joseph Wright -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Wed, Oct 19, 2011 at 6:10 AM, Peter Dyballa peter_dyba...@web.de wrote: Am 19.10.2011 um 12:19 schrieb Chris Travers: If RHEL 6 (released about a year ago) is sticking to TeXLive 2007, we all have problems. The only problem is that of understanding. It's like the fifth wheel or the tool to change wheels that come with new car. They're not really usable, they're more kind of alibis. And that's the situation of TeX in Linux. U Not necessarily. Anyway, aside from the xelatex.fmt issue, which I have found (and documented) a workaround for, it's working well enough for me, and it's certainly working well enough to predictably generate invoices in an accounting system. Hint: Maybe if that hammer isn't useful it's a crescent wrench instead? Because it's not necessary to build a second rail of distribution via DEB or RPM packages. TeX Live comes with its own package manager and in packages and in meta-packages. Use this opportunity! But if you do that, you lose the ability to tie the application built in Perl to its own dependencies in a package manager. So you have a package manager, Perl has a package manager, and the OS has a package manager and none of them talk to eachother. The result becomes a dependency tracking nightmare. In Mac OS X, Solaris, MS Windows we have the freedom to use third parties as suppliers of software packages. It's time that Linux grows up to that level. Even when it becomes complicated for the users and administrators to send bug reports to a thousand authors of TeX Live packages. You know, that's kind of unnecessary. I could just as easily point out that I came here looking for help on what I felt is an important development on LaTeX, but now feel like it's pretty clear that XeTeX hasn't outgrown it's shiny-new-iMac roots, or that it's time for XeTeX to realize that real productivity occurs in the area of server-side document processing where stability is far more important than folks here seem to want to acknowledge. To be honest, I am pretty discouraged here. I've long used LaTeX for document processing because it is a stable technology and unlikely to change out from under my documents.I understand that XeTeX hasn't reached that level of maturity yet and may never. However, it seems to me that this community here doesn't really care about the kinds of environments where this sort of document processing occurs. Have you thought of keeping exactly one (maybe only virtual) alibi server with long-term support software? In case someone asks you have something to present... (and when it's virtual you can easily add some CPU power and/or disk space, if needed) Not really an option. The goal is to get people up and running fast, with their package managers if they prefer. That's not negotiable. BTW, the packages supplied by CTAN are *stable* packages. (It's also possible to get preliminary test software.) I think stable in terms of you can safely use this to render your documents and stable in terms of no unnecessary changed so we know the software using this clearly and predictably works every time are different senses of the word stable. I need the latter once the software is installed, you are talking the former. The point is that changing upgrading software underneath fairly critical systems just because there is a newer version out with bug fixes that don't affect you will *always* cause more harm than good. Best wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/19 Chris Travers chris.trav...@gmail.com: On Wed, Oct 19, 2011 at 6:20 AM, Ulrike Fischer ne...@nililand.de wrote: Am Wed, 19 Oct 2011 05:59:16 -0700 schrieb Chris Travers: This matches my needs very well. If my clients are running accounting systems, the last thing I want is an upgrade of TexLive to break their ability to generate invoices. Normally you get more problems if you can't update ;-) You get more problems with things suddenly and unexpectedly breaking if you don't change them? On what theory? At least if you don't include deliberate breakage of programs over a certain age.. If there are bugs in older versions, I can work around those bugs, but the problem of getting a document that will only render with one version or another is not acceptable to my application. Then you shouldn't rely on an external TeXLive installation. You have absolutly no control on the status of the TeXLive installations of your users. You don't know if the fedora user installed the fedora-TeXLive or the newest shapshot from the svn. You also have no control about the package versions installed by the users. fontspec e.g. can be an old version, the current version on CTAN or the unstable version from Github. I think you may misunderstand how this works. We have some (relatively basic) demo templates. They are tested on TeXLive 2007 and 2009 at present and known to render properly. They don't use a whole lot of packages (I think mostly longtable, geometry, and a few others). These are designed to give people a sense of what they can do but not necessarily provide exactly what they need. The client then can contract with me or others to write templates in the environment of their choice. That may be TeTeX (RHEL 5), TexLive 2007 (RHEL 6 and friends), TexLive (Debian Stable and friends), it could be a shiney new TexLive. It could be MikTeX. It could be whatever. These documents are then tested on these environments and verified to work reliably and predictably. The software then plugs text into the templates and runs them. These then run reliably as long as nothing changes. If someone is going to upgrade TexLive, the templates have to be tested again, against the new version. That usually means a staging server is updated first, the templates tested, and then the update rolled out to production when it is verified not to cause problems. This is a very slow, deliberate process, as it should be. I have documents as old as 18 years that still render almost without problems. The problem is that they rely on proprietary fonts and emTeX in OS/2 required them in a different directory than TL in TeX Live. It even does not matter that the documents are prepared in CP852 and now my locale is UTF-8, I can still work in CP852. It's because the documents rely on my own macros and packages that are backward compatible. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Wed, Oct 19, 2011 at 7:13 AM, Chris Travers chris.trav...@gmail.com wrote: On Wed, Oct 19, 2011 at 7:09 AM, Joseph Wright joseph.wri...@morningstar2.co.uk wrote: The 'expiry date' in LaTeX2e was there for good reasons, and reflected a desire to avoid buggy and out-of-date software remaining 'in use' for too long. However, the situation has changed more recently, as updates to LaTeX2e have become very rare and the 'expiry date' was no longer appropriate. The latest LaTeX2e release no longer includes an expiry date. Clearly, there is not much that can be done directly about the older version: if you have it, your options are to update at least that file (latex.ltx), or has been suggested earlier to temporarily 'mess about' with your system date. Thank you for the explanation. It saves me trying the new version to determine if there is a bug to report. I see there is not. Anyway, I have a workaround and that's what is important. Best Wishes, Chris Travers Just for the record, my workaround is: cd to appropriate directory in /usr/var/texmf/ xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini I can document it. It will do the job. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Chris Travers wrote: xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini I asked Vafa, there was no reply. I will now ask you, Chris : What does this accomplish that xetex -ini -etex xelatex.ini does not ? Philip Taylor -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Oct 19, 2011, at 9:09 AM, Chris Travers wrote: ... I think stable in terms of you can safely use this to render your documents and stable in terms of no unnecessary changed so we know the software using this clearly and predictably works every time are different senses of the word stable. I need the latter once the software is installed, you are talking the former. The point is that changing upgrading software underneath fairly critical systems just because there is a newer version out with bug fixes that don't affect you will *always* cause more harm than good. Best wishes, Chris Travers Howdy, Of course there is another sense of ``stable'': we're not going to change anything even if it doesn't work and has bugs because it's better to know your enemy than to find an ew enemy or friend. I don't think packages in updated TeX Live installations are changed arbitrarily but rather in response to bug fixes that others, and possibly not all users, have observed. A TeX Distribution is a very complicated organism. Good Luck, Herb Schulz (herbs at wideopenwest dot com) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am Wed, 19 Oct 2011 07:15:56 -0700 schrieb Chris Travers: Just for the record, my workaround is: cd to appropriate directory in /usr/var/texmf/ xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini I can document it. It will do the job. Hm. I don't understand how this can be a general usable work-around. What actually is the appropriate directory here? Do you have a newer/local version of latex.ltx in this directory? If yes why doesn't simply work fmtutil --byfmt xelatex (instead of fmtutil-sys)? -- Ulrike Fischer -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 19.10.2011 um 16:09 schrieb Chris Travers: However, it seems to me that this community here doesn't really care about the kinds of environments where this sort of document processing occurs. Or this community knows how to get back to functioning state. Or uses test or development areas to check first. (I, for example, let the Mac users test a newly released Mac OS X at least one, recently better two years, before I think of upgrading. Since downgrading can be a bit complicated. This is different with TeX Live. There is no real risk of updating too early.) -- Greetings Pete A mathematician is a device for turning coffee into theorems. – Erdős Pál -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 19.10.2011 um 16:21 schrieb Herbert Schulz: I don't think packages in updated TeX Live installations are changed arbitrarily but rather in response to bug fixes that others, and possibly not all users, have observed. Indeed! Usually new (possibly bugful) features enter stage when a new TeX Distribution is pre-released for testing. Then many bugs get fixed, then the distribution is released. -- Greetings Pete The light at the end of the tunnel has been turned off due to budget cuts. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Peter, I sort of resent this message, since a) To uninstall TeX Live, use the Finder’s GO menu, go to /usr/local/texlive/2011 and drag it to the trash, inputting your admin password when asked b) As I have said countless times, MacTeX installs TeX Live. Pure and simple. No changes. c) We went to a lot of trouble to add a Preference Pane making it possible to switch between different versions of TeX Live with a single button click, which automatically switches all GUI programs and all command line programs. Dick Koch On Oct 19, 2011, at 7:47 AM, Peter Dyballa wrote: (I, for example, let the Mac users test a newly released Mac OS X at least one, recently better two years, before I think of upgrading. Since downgrading can be a bit complicated. This is different with TeX Live. There is no real risk of updating too early.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Hm. I don't understand how this can be a general usable work-around.
What actually is the appropriate directory here? Do you have a
newer/local version of latex.ltx in this directory?
Actually, if you look at a latex.ltx that has that check (the one from
stock TeX Live 2011 still has code for the expiry date, for example),
you can see that all LaTeX does is to issue an \errmessage, which you
can simply ignore when running xetex -ini in interactive mode; the
format will still be built. However, fmtutil aborts by default on
error, if memory serves. Hence, it may be that Chris did actually see
the error and simply typed Enter; or maybe it's something else, but
clearly there's more to it than the two-line instructions he sent.
For the record, the relevant bits from the LaTeX kernel are:
\edef\fmtversion{2011/06/27}
\iffalse
\def\reserved@a#1/#2/#3\@nil{%
\count@\year
\advance\count@-#1\relax
\multiply\count@ by 12\relax
\advance\count@\month
\advance\count@-#2\relax}
\expandafter\reserved@a\fmtversion\@nil
\ifnum\count@65
\typeout{^^J%
!!^^J%
! You are attempting to make a LaTeX format from a source file^^J%
! That is more than five years old.^^J%
!^^J%
! If you enter return to scroll past this message then the format^^J%
! will be built, but please consider obtaining newer source files^^J%
! before continuing to build LaTeX.^^J%
!!^^J%
}
\errhelp{To avoid this error message, obtain new LaTeX sources.}
\errmessage{LaTeX source files more than 5 years old!}
\fi
\let\reserved@a\relax
\fi
As you can see, the check is surrounded by \iffalse ... \fi and is
hence never actually run.
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/19 Arthur Reutenauer arthur.reutena...@normalesup.org:
Hm. I don't understand how this can be a general usable work-around.
What actually is the appropriate directory here? Do you have a
newer/local version of latex.ltx in this directory?
Actually, if you look at a latex.ltx that has that check (the one from
stock TeX Live 2011 still has code for the expiry date, for example),
you can see that all LaTeX does is to issue an \errmessage, which you
can simply ignore when running xetex -ini in interactive mode; the
format will still be built. However, fmtutil aborts by default on
error, if memory serves. Hence, it may be that Chris did actually see
the error and simply typed Enter; or maybe it's something else, but
clearly there's more to it than the two-line instructions he sent.
Or you can make file xelatex.my containing
\batchmode
\input xelatex.ini
Then create the format from this file.
For the record, the relevant bits from the LaTeX kernel are:
\edef\fmtversion{2011/06/27}
\iffalse
\def\reserved@a#1/#2/#3\@nil{%
\count@\year
\advance\count@-#1\relax
\multiply\count@ by 12\relax
\advance\count@\month
\advance\count@-#2\relax}
\expandafter\reserved@a\fmtversion\@nil
\ifnum\count@65
\typeout{^^J%
!!^^J%
! You are attempting to make a LaTeX format from a source file^^J%
! That is more than five years old.^^J%
!^^J%
! If you enter return to scroll past this message then the
format^^J%
! will be built, but please consider obtaining newer source files^^J%
! before continuing to build LaTeX.^^J%
!!^^J%
}
\errhelp{To avoid this error message, obtain new LaTeX sources.}
\errmessage{LaTeX source files more than 5 years old!}
\fi
\let\reserved@a\relax
\fi
As you can see, the check is surrounded by \iffalse ... \fi and is
hence never actually run.
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
--
Zdeněk Wagner
http://hroch486.icpf.cas.cz/wagner/
http://icebearsoft.euweb.cz
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Peter Dyballa, I replied to Will Adam's comment as soon as I read it, apologizing to you. Then I incorrectly the reply to Will rather than to the list. I'm not going to reply to (or even read) mailing lists the rest of today. Dick Koch On Oct 19, 2011, at 8:35 AM, Richard Koch wrote: Peter, My apologies. I reread. William Adams is correct. My face is red. Dick Koch On Oct 19, 2011, at 8:31 AM, William Adams wrote: I think you may want to take a moment to relax and then re-read Peter's message. I believe you conflated his caution re upgrading to new versions of Mac OS X w/ MacTeX. William -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
2011/10/18 Chris Travers chris.trav...@gmail.com: Hi all; I need to generate the xelatex.fmt file. Apparently Fedora doesn't create these files. It is not a new issue, I have had issues with the latex.fmt files not created in the past. Is there any way to manually create this file? Certainly there is but it would rather be a question for Fedora forum. Although I use Fedora myself, I do not use its TeX but I install TeX Live. That's why I do not know how it is packaged in Fedora. Does Fedora contain fmtutil and fmtutil-sys? Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 18.10.2011 um 10:30 schrieb Chris Travers: Is there any way to manually create this file? TeX Live comes with a utility, fmtutil-sys. It allows to create FMT files for the *system*. Private FMT files can be created with fmtutil. The former is kind of a wrapper for the latter, so the only man page exists for the latter. The script also gives some hints when invoked with --help. It's also possible to create a local patch file for the fmtutil configure file, /usr/local/texlive/texmf-local/web2c/fmtutil-local.cnf. To apply that patch you'll need to run tlmgr and make it regenerate the configure files. This procedure is described in some top level TeX Live documentation, maybe doc.html. -- Greetings Pete No man was ever taken to hell by a woman unless he already had a ticket in his pocket, or at least had been fooling around with timetables. – Archie Goodwin -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
There are two ways to create xelatex.fmt: 1) xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini 2) fmtutil --byfmt xelatex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Vafa Khalighi wrote: There are two ways to create xelatex.fmt: 1) xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini What does this accomplish that xetex -ini -etex xelatex.ini does not ? Philip Taylor -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
This has all been very helpful. At least I have things narrowed down a bit here: # fmtutil-sys --byfmt xelatex Defining UNIX/DOS style filename parser. catcodes, registers, compatibility for TeX 2, parameters, !! ! You are attempting to make a LaTeX format from a source file ! That is more than five years old. ! ! If you enter return to scroll past this message then the format ! will be built, but please consider obtaining newer source files ! before continuing to build LaTeX. !! ! LaTeX source files more than 5 years old!. l.545 ...aTeX source files more than 5 years old!} ? ! Emergency stop. l.545 ...aTeX source files more than 5 years old!} No pages of output. Transcript written on xelatex.log. Error: `xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini' failed ### fmtutil: Error! Not all formats have been built successfully. Visit the log files in directory /var/lib/texmf/web2c for details. ### This is a summary of all `failed' messages and warnings: `xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini' failed Any idea of what I do about this? Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Quoting Chris Travers (chris.trav...@gmail.com): ! LaTeX source files more than 5 years old!. Any idea of what I do about this? I did not follow the thread closely. Are you the administrator of the system? If so, I'd advise to de-install fedora's TeX-suite and install texlive instead. That at least is what I did with my openSUSE boxes. Hope that helps, Susan -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Tue, Oct 18, 2011 at 6:07 AM, Susan Dittmar susan.ditt...@gmx.de wrote: Quoting Chris Travers (chris.trav...@gmail.com): ! LaTeX source files more than 5 years old!. Any idea of what I do about this? I did not follow the thread closely. Are you the administrator of the system? If so, I'd advise to de-install fedora's TeX-suite and install texlive instead. That at least is what I did with my openSUSE boxes. I am the administrator on this system but the software is that uses this (an open source accounting program) is to be shipped out ideally in .rpm and .deb format. It would really help if I don't require most users who want to generate PDF invoices in multiple languages to go download large external dependencies. This current version is supposed to support, for example RHEL 5 and higher, among other distros. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am Tue, 18 Oct 2011 05:43:57 -0700 schrieb Chris Travers: This has all been very helpful. At least I have things narrowed down a bit here: # fmtutil-sys --byfmt xelatex ! LaTeX source files more than 5 years old!. l.545 ...aTeX source files more than 5 years old!} Any idea of what I do about this? The best is to get and install a new TeXLive 2011 with newer latex sources. You can also try to fool latex by changing your pc date. -- Ulrike Fischer -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Hi. I appear to have solved this by running xelatex -ini manually and then copying the ..fmt file to the appropriate directory. Thanks for everyone's help. As a note, I am really restricted to supporting TexLive versions that ship on stable long-term-support (and supported) distros We can argue about whether these distros are too shy about upgrades, but users don't like to hear that their shiny rpm or .deb requires that they also track down large dependencies from external sources not in any repository for their distro. Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Tue, Oct 18, 2011 at 10:24 AM, Chris Travers chris.trav...@gmail.com wrote: Hi. I appear to have solved this by running xelatex -ini manually and then copying the ..fmt file to the appropriate directory. Thanks for everyone's help. As a note, I am really restricted to supporting TexLive versions that ship on stable long-term-support (and supported) distros We can argue about whether these distros are too shy about upgrades, but users don't like to hear that their shiny rpm or .deb requires that they also track down large dependencies from external sources not in any repository for their distro. Users also don't like to discover that the publishers' LaTeX format they need won't work with the distro TeX, or that a document that formats correctly on a co-author's Mac or Windows system won't format on their linux system. The TeX ecosystem needs some reasonable limits on how long old versions should be supported. If users can't get adequate support from their distro there are better supported alternatives. -- George N. White III aa...@chebucto.ns.ca Head of St. Margarets Bay, Nova Scotia -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Users also don't like to discover that the publishers' LaTeX format they need won't work with the distro TeX, or that a document that formats correctly on a co-author's Mac or Windows system won't format on their linux system. The TeX ecosystem needs some reasonable limits on how long old versions should be supported. If users can't get adequate support from their distro there are better supported alternatives. Given that server software that I work with usually has at least a five year support cycle, what are those reasonable limits? Or is XeTeX not intended to be used in these environments? Best Wishes, Chris Travers -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am Tue, 18 Oct 2011 06:43:59 -0700 schrieb Chris Travers:
Users also don't like to discover that the publishers' LaTeX
format they need won't work with the distro TeX, or that a
document that formats correctly on a co-author's Mac or Windows
system won't format on their linux system. The TeX ecosystem
needs some reasonable limits on how long old versions should be
supported. If users can't get adequate support from their
distro there are better supported alternatives.
Given that server software that I work with usually has at least a
five year support cycle, what are those reasonable limits?
Well you error message said
! LaTeX source files more than 5 years old!.
So the limit is five years (but only for the latex kernel).
The version date of my (current) latex.ltx ist
\edef\fmtversion{2011/06/27}
Or is XeTeX not intended to be used in these environments?
I would say that if your latex is more than five years old, your
xetex binaries and packages aren't up-to-date either. And as xetex
is rather young this can be quite a problem. Regardless if you want
to ship out only xetex documents or xetex documents + binaries: You
should be aware that other people can have up-to-date systems and so
you should make tests on such systems too (and just in case you
don't know: you can't use a fmt generated by one xetex version with
another xetex version).
--
Ulrike Fischer
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Tue, Oct 18, 2011 at 10:53 AM, msk...@ansuz.sooke.bc.ca wrote: On Tue, 18 Oct 2011, George N. White III wrote: Users also don't like to discover that the publishers' LaTeX format they need won't work with the distro TeX, or that a document that formats correctly on a co-author's Mac or Windows system won't format on their linux system. That seems to me to be a reason to *continue* support for older versions, not a reason to *end* it. I don't understand how you got from the above to the next thing you wrote: No -- newer versions have to deal with changes to external interfaces (fonts, image formats, library versions, etc.) so end up adding extra code to check for old versions and work around limitations, or do without some desirable features that can't be implemented on the older version. It takes real work to support older versions and the options to make improvements are constrained. Compromises are needed to live within the hardware limitations of baseline systems at the time the design is fixed. This thinking would still have TeX configurations that could run in 16-bit memory address limits. Even if you think that would be useful, the people who do the heavy lifting tend to use current or even leading edge hardware and are going to be more interested in the new capabilities they can get by taking advantage of the latest hardware developments than minimizing memory footprints. Ultimately, the decisions are made by the people who write the code. The TeX ecosystem needs some reasonable limits on how long old versions should be supported. If users can't get adequate support from their -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- George N. White III aa...@chebucto.ns.ca Head of St. Margarets Bay, Nova Scotia -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Tue, Oct 18, 2011 at 10:43 AM, Chris Travers chris.trav...@gmail.com wrote: Users also don't like to discover that the publishers' LaTeX format they need won't work with the distro TeX, or that a document that formats correctly on a co-author's Mac or Windows system won't format on their linux system. The TeX ecosystem needs some reasonable limits on how long old versions should be supported. If users can't get adequate support from their distro there are better supported alternatives. Given that server software that I work with usually has at least a five year support cycle, what are those reasonable limits? Five years seems to be a common support period. If you sell a distro with 5-year support then you should know that some packages you provide will expire before the 5 years is up and be prepared to provide updates. Or is XeTeX not intended to be used in these environments? The 5 year limit is in LaTeX, not xetex. -- George N. White III aa...@chebucto.ns.ca Head of St. Margarets Bay, Nova Scotia -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
On Tue, Oct 18, 2011 at 7:09 AM, Ulrike Fischer ne...@nililand.de wrote:
So the limit is five years (but only for the latex kernel).
The version date of my (current) latex.ltx ist
\edef\fmtversion{2011/06/27}
Or is XeTeX not intended to be used in these environments?
I would say that if your latex is more than five years old, your
xetex binaries and packages aren't up-to-date either. And as xetex
is rather young this can be quite a problem. Regardless if you want
to ship out only xetex documents or xetex documents + binaries: You
should be aware that other people can have up-to-date systems and so
you should make tests on such systems too (and just in case you
don't know: you can't use a fmt generated by one xetex version with
another xetex version).
Of course. I don't expect .fmt files to be portable. What is helpful
is to know how to resolve the issue so I can put a faq entry in and
direct people to it when they ask on the mailing list. (And if they
can't get it, charge for support.) I believe I have gotten that, so I
am satisfied with the resolution.
However, so that there are no misunderstandings The issue here
is being forced to choose between supporting XeTeX on many platforms
and being able to support the platform's package manager. I don't see
anyone here suggesting a way around that. For developers distributing
software, that's kind of an issue.
Here's a breakdown of OS support for TexLive versions for anyone interested:
Debian Lenny: TexLive 2007
Debian Squeeze: TexLive 2009
Debian Sid: TexLive 2009
Ubuntu 10.04 LTS: TexLive 2009
Red Hat Enterprise 6: TexLive 2007
That means that the most recent versions of CentOS and Scientific
Linux also use 2007.
To be clear, I am not saying every issue has to be resolved. And I
did get enough info to solve my problem off this list (and for that I
am grateful). I am however saying that some comments on this list
seem more aimed at end users than folks trying to build tools which
integrate with a TeX environment.
However, the software project has contributors on both TexLive 2007
and 2009, and so our coverage in terms of testing is pretty good
there.
I also understand George's point that ensuring backwards compatibility
isn't always either desirable or possible. I am not asking for that
either. Quite frankly if I can get documentation about what needs to
change for documents to render I can supply alternate copies of
templates, avoid trouble spots, etc.. I also understand that
these things are usually most unstable for young software. My own
package, LedgerSMB, is going through similar issues. I don't know
anyone that ensures absolute backwards compatibility. That way
madness lies-- it locks you into bad decisions that you make before
the full scope of the problem becomes known.
I am not asking for any of that. However, this argument is going on
because I was told that upgrading was the solution, I said it wasn't a
possibility for me and outlined why, and folks decided to push the
issue. What I don't understand is what is to be gained by pushing the
issue.
Best Wishes,
Chris Travers
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 18.10.2011 um 15:43 schrieb Chris Travers: Given that server software that I work with usually has at least a five year support cycle, what are those reasonable limits? For TeX I'd think in decades. And support in the way TeX understands this term is constant development and constant updating. TeX is alive. Or is XeTeX not intended to be used in these environments? XeTeX is likely to stop in development, maybe before reaching version 1.0, because of the lack of active developers (and because of improving alternatives like LuaTeX). So soon you'll have a software that will last longer than your hardware and won't need updating. BTW, XeTeX from five years ago was a bit away from perfection and quite a few bugs richer. Particularly the xdvipdfmx convertor was heavily improved. -- Greetings Pete The best way to accelerate a PC is 9.8 m/s² -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How to manually create the xelatex.fmt?
Am 18.10.2011 um 16:39 schrieb Chris Travers: Here's a breakdown of OS support for TexLive versions for anyone interested: Debian Lenny: TexLive 2007 Debian Squeeze: TexLive 2009 Debian Sid: TexLive 2009 Ubuntu 10.04 LTS: TexLive 2009 Red Hat Enterprise 6: TexLive 2007 That means that the most recent versions of CentOS and Scientific Linux also use 2007. Forget these RPM or DEB based re-packings! (The support from their distributors/repackagers can be a bit less than optimal.) Install TeX Live 2005, 2006, 2007, 2008, 2009, 2010, 2011! Then every user will have a choice. Because setting PATH and MANPATH makes any of these installations active and working. And you can use the TeX Live Manager, tlmgr, of each of these installations to support (setup, changes, updates) any of these. And when you start lacking some disk space you can use utilities like dupmerge to hard-link files from the stable distributions (all but that from this year) that many invariant files become unique on disk. I think it should even be possible to have one external disk (NAS or such) that also carries the 32-bit and 64-bit binaries for all the different Linux clients. (Because the TeX binaries are statically linked and therefore do not depend on subtle variations in systems' shared libraries.) -- Greetings Pete No man was ever taken to hell by a woman unless he already had a ticket in his pocket, or at least had been fooling around with timetables. – Archie Goodwin -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
