[XeTeX] How to manually create the xelatex.fmt?

Zdenek Wagner zdenek.wagner at gmail.com
Fri Oct 21 10:39:48 CEST 2011


2011/10/21 Chris Travers <chris.travers at gmail.com>:
> On Thu, Oct 20, 2011 at 8:25 AM, Peter Dyballa <Peter_Dyballa at 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



More information about the XeTeX mailing list