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] ascii to unicode map for Hebrew
Yes, they have a mapping for their legacy Hebrew fonts, but I was hoping to find a mapping for the ascii input used by hebtex, or arabtex. I am not a scholar of Hebrew, so I would not be the right person to write such a map file. Nathan On 11/10/18 5:48, Andy Lin wrote: An easy way is to define a TECkit map. Such maps for Devanagari are available in xetex-devanagari package, very elaborate solution for Arabic scripts is in ArabXeTeX. It should be quite easy to prepare such a map for Hebrew. Such a map might already exist in the TECkit package from SIL. IIRC, they have mapping for all of their legacy (non-Unicode) fonts. -Andy -- 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] Polyglossia update
On Sat, Oct 15, 2011 at 02:23:29PM -0500, Neal Delmonico wrote: One thing still bothers me about that whole affair. I am working on several books involving Sanskrit and English and requiring hyphenation in both. None of the other books had that problem, as far as I know. I wonder what was different about that book. It may be just chance: the wrong hyphenations such as n-ear, s-mall, b-lissful that you mention in your mail from late September (http://tug.org/pipermail/xetex/2011-September/021399.html) happened because of the combination of three reasons: 1. they are allowed by the hyphenation patterns for English; 2. they were allowed then because \lefthyphenmin was (incorrectly) set to 1; and 3. TeX's line-breaking algorithm just happened to find that breaking the line right there was the best choice in the context of the paragraph (as hyphenation was legal because of reasons 1 2). Changing one single word in a paragraph can completely change the shape of the whole paragraph (remember, TeX always considers paragraphs in their entirery before deciding where to break lines); hence it's very hard to predict whether 3 will happen at all (short of actually typesetting the text with TeX, of course). It may thus be that you didn't observe such incorrect hyphenations because 3 never occurred. However, if you were typesetting long texts it's indeed odd that you never saw anything like that, hence if you'd like to investigate the matter more closely you can send other documents. Arthur (who knows the need to understand why things work when they do, just as much as why they don't when they don't :-) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] traditional to simplified Chinese character conversion utility or data base
On Tue, Oct 18, 2011 at 05:49:28AM +0800, Daniel Greenhoe wrote: Does anyone know of any data base with a traditional to simplified character mapping such that I could maybe write the utility myself? Unicode has that in the Unihan database: look up Unihan_Variants.txt in Unihan.zip (latest version http://www.unicode.org/Public/6.1.0/ucd/Unihan-6.1.0d1.zip ) Arthur -- 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] traditional to simplified Chinese character conversion utility or data base
Hi Arthur, On Thu, Oct 20, 2011 at 1:02 AM, Arthur Reutenauer arthur.reutena...@normalesup.org wrote: Unicode has that in the Unihan database: look up Unihan_Variants.txt in Unihan.zip (latest version http://www.unicode.org/Public/6.1.0/ucd/Unihan-6.1.0d1.zip ) It looks like I can extract everything I need from Unihan_Variants.txt. Thank you so much for your help! I appreciate it very much. Dan On Thu, Oct 20, 2011 at 1:02 AM, Arthur Reutenauer arthur.reutena...@normalesup.org wrote: On Tue, Oct 18, 2011 at 05:49:28AM +0800, Daniel Greenhoe wrote: Does anyone know of any data base with a traditional to simplified character mapping such that I could maybe write the utility myself? Unicode has that in the Unihan database: look up Unihan_Variants.txt in Unihan.zip (latest version http://www.unicode.org/Public/6.1.0/ucd/Unihan-6.1.0d1.zip ) Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
