Andrew Komornicki | 7 Oct 23:49 2014

Re: speed of kpsewhich to get value of TEXMFLOCAL


would it not be simpler to just define these variables in your
environment so that your makefile can pick them up at will.  You would
not have to invoke kpsewhich and incur the execution penalty.  Karl most
probably has the most insight into execution bottlenecks with his
routine. just a thought.


 Andrew Komornicki
 Department of Chemistry
 Stanford University

On 10/7/2014 1:01 AM, jfbu wrote:
> Hi,
> in a Makefile I am currently testing I have something like this
> TEXMF_LOCAL = $(shell kpsewhich -var-value TEXMFLOCAL)
> TEXMF_HOME  = $(shell kpsewhich -var-value TEXMFHOME)
> however evaluation of each variable is very slow, of the order
> of half a second on my mac os x mavericks with TL2014
> ======Makefile:
> # TEXMF_LOCAL = `kpsewhich -var-value TEXMFLOCAL`
> TEXMF_LOCAL = $(shell kpsewhich -var-value TEXMFLOCAL)
(Continue reading)

Herbert Voss | 2 Oct 20:35 2014

PSTricks and xdvipdfmx

Hello all,

the following works fine with tex->dvips-ps2pdf
but with xetex it fails, more or less no output.

\input pst-node

\rput(1,0){\rnode{A}{Stuff A}}%
\rput(0,1){\rnode{B}{Stuff b}}


If you comment the line with \ncline the two text boxes
appear. I suppose a problem with the underlying coordinate
system but I cannot see any problem in the xdvipdfmx.cfg
of PSTricks.

I run up-to-date TL 2014


Stephan Hennig | 1 Oct 18:06 2014

ligatures and explicit kerns


in the TeXbook, the answer to exercise 5.1 (the shelfful exercise)
contains a sentence

  Appendix H points out that ligatures are put into a hyphenated
  word that contains no “explicit kerns,” and an italic correction
  is an explicit kern.

I didn't find the place in appendix H the quote refers to, so pointers
would be appreciated.

Anyway, as I understand the quote, ligatures won't be inserted in words
that do contain explicit kerns.  That is, to suppress multiple ligatures
within a word, it should be enough to insert just /one/ italic
correction (between two of the ligature candidates).  Though, a test
turns out that this is not the case.


outputs the word with two separate letters f but the fi ligature
applied.  Could anybody please shed some light on the quote above?

Best regards,
Stephan Hennig

张民康 | 5 Sep 04:20 2014

Fwd: Wanting debug for the texdoctk

---------- Forwarded message ----------
From: 张民康 <zoengmickong@...>
Date: 2014-09-05 10:09 GMT+08:00
Subject: Wanting debug for the texdoctk
To: tr@...

Mr. Thomas Ruedas.
  I have a problem when use with texdoctk which is installed from the
texlive2014.iso in Windows 7. It seems that the texdoctk.exe can't
read the document file path whose string include space,for which the
shell can't open a file correctly. Thus, I find out the problem in the
source file in which the 454th line
> system("$viewer $slcdoc");

The statement work well if modified as follow
> system("$viewer \"$slcdoc\"");.

  So I expect to modified the Perl file then convert to exe file which
easy for use in windows. However I don't know how convert it into exe
file. It seems awful to convert it  into Perl.
  Please tell me what should I do if want to use the modified texdoctk.exe.
Sincerely Yours

Denis Bitouzé | 23 Jun 11:41 2014

Bug with color \specials?


a bug with latest xetex:

  XeTeX, Version 3.14159265-2.6-0.99991 (preloaded format=xelatex 2014.6.19)

occurs, probably related to color \specials: in the following MWE (say
`test.tex') compiled with xelatex, the text after the tcolorbox
environment on page 2 is colored in white.

--8<---------------cut here---------------start------------->8---
--8<---------------cut here---------------end--------------->8---

If compiled with:

(Continue reading)

Fischer, William M | 16 Jun 20:45 2014

epstopdf patch (% in filenames)

# $Id: 30419 2013-05-12 17:55:50Z karl $

epstopdf fails if there is a '%' character in the filename.  Patch and testfile attached.


Will Fischer

tel: 505-665-4149
fax: 505-665-3493

Group T-6, Theoretical Biology
MS K710, Drop Point 03041003U
Los Alamos National Laboratory
Los Alamos, NM 87545

Attachment (epstopdf.filename.patch): application/octet-stream, 418 bytes
Seth Gilchrist | 7 May 06:24 2014

epstopdf crashes with malloc error

I'm using epstopdf as part of LaTeX. The latex compilation fails on a epstopdf error that can be reproduced on the command line:

$ epstopdf --outfile=NeckFractues-eps-converted-to.pdf NeckFractues.eps 
gs: malloc.c:3524: _int_malloc: Assertion `(bck->bk->size & 0x4) == 0' failed.

The eps file can be downloaded  from

Please let me know if you need more information.

System Info:

$ epstopdf --version
epstopdf ($Id: 32701 2014-01-17 18:09:54Z karl $) 2.21

$ uname -a
Linux computer01 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04 LTS
Release: 14.04
Codename: trusty

$ /lib/x86_64-linux-gnu/ 
GNU C Library (Ubuntu EGLIBC 2.19-0ubuntu6) stable release version 2.19, by Roland McGrath et al.
Compiled by GNU CC version 4.8.2.
Compiled on a Linux 3.13.9 system on 2014-04-12.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al

Chris Hanning | 5 Mar 00:08 2014

5 Memory Objects Still Allocated


As the Subject heading states, I have received a memory allocation
warning with my version of Latex.

I am running Texmaker under xubuntu_12.04 from the Ubuntu repositories
and have only noticed this warning at compile time since yesterday when
I attempted to compile the example sheet for the psvectorian package.

I apologize in advance for the paucity of information provided. If you
so desire I could furnish you with further details if instructed.


Chris Hanning

mario chiari | 27 Feb 19:00 2014

kpathsea and compilation by a web server


my first post on this list.  I hope it is the proper forum to ask help
for my problem.

I have been a LaTeX user for some time, but with a very basic knowledge
on how it works.

On my local web server Apache (Linux platform), I create and compile a
number of .tex file calling some php script from a web client. This has
been working without main issues. 

For a recent job, I need to output some cyrillic text. I am able to do
so, if a compile a myfile.tex file from my shell (or from within an
editor as Kile) as the root user.
However, if a call from a web client a php script with instructions

`/usr/local/texlive/2013/bin/i386-linux/latex  --interaction batchmode

compilation partially fails, in particular cyrillic letters are not

I have tried to execute my php script from a shell as the apache user,
and I got the following error
LaTeX Font Warning: Font shape `T2A/wncyr/m/n' undefined
(Font)              using `T2A/cmr/m/n' instead on input line 2.

kpathsea: Running mktextfm larm1728
mkdir: cannot create directory `././var/www/.texlive2013': Permission
mktextfm: mktexdir /var/www/.texlive2013/texmf-var/fonts/tfm/lh/lh-t2a
kpathsea: Appending font creation commands to missfont.log.
! Font T2A/cmr/m/n/17.28=larm1728 at 17.28pt not loadable: Metric (TFM)

However, by setting

chown apache:apache /var/www/

i get instead
LaTeX Font Warning: Font shape `T2A/wncyr/m/n' undefined
(Font)              using `T2A/cmr/m/n' instead on input line 2.
kpathsea: Running mktextfm larm1728
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1;
nonstopmode; input larm1728
This is METAFONT, Version 2.718281 (TeX Live 2013)
kpathsea: Running mktexmf larm1728
mktexmf: /var/www/.texlive2013/texmf-var/fonts/source/lh/lh-t2a/ successfully generated.
and eventually I get a fine output. 

The bad news is that is not good enough, compilation still fails if I
call the same php script from my web client. 

What I note is that mktexmf creates within /var/www/, where
instead my DocumentRoot is /var/www/html/ (i can not chenge that) 

I suspect the/a issue is
that .texlive2013/texmf-var/fonts/source/lh/lh-t2a/ should be
somewhere else within my DocumentRoot, as to be available to the web

However, I do not see where exactly and how to force mktexmf to create
it there.
I appreciate your advise.


Maggie McLoughlin | 16 Jan 05:56 2014

note from Don Knuth -- bug(s) in MetaPost?

PS -- The "unfilled circles" happen when Ghostview or Preview renders
that PostScript file. But if you apply Acrobat Distiller, and presumably
also if you use a reputable Adobe "rip" to create the image, all of
the circles are filled in.

Some of them are however larger than others, because of the "stroke"
in addition to "fill", and that should not be.

Unfortunately the Ubuntu engine that converts PostScript to my
laserprinter has the same bug as Preview and Ghostview...

-- Don

Maggie McLoughlin | 16 Jan 05:31 2014

note from Don Knuth -- bug(s) in MetaPost?

Dear TeX-Kers,

The "drawdot" command in MetaPost hasn't been working for me.

Consider the following input file
> beginfig(1)
> for j=1 upto 9:
>   pickup pencircle scaled .4;
>   drawdot (10j,0) withpen pencircle scaled .5j;
>   pickup pencircle scaled .5j;
>   drawdot (10j,10);
> endfor
> endfig;
> bye.
I ran this with newly installed MacTeX from the TeX Collection 2013.

When I say "tex mproof test.1" and then "dvips test -o", I get an output
file that contains nine correctly filled circles above nine strange
partially filled circles. The Postscript file begins with
> %!PS-Adobe-2.0
> %%Creator: dvips(k) 5.993 Copyright 2013 Radical Eye Software
> %%Title: mproof.dvi
> %%CreationDate: Wed Jan 15 19:07:45 2014
> %%Pages: 1
> %%PageOrder: Ascend
> %%BoundingBox: 0 0 612 792
> %%DocumentFonts: CMTEX10 CMR7 CMR10
> %%DocumentPaperSizes: Letter
and then a whole bunch of infrastructure stuff and then the guts starts with
> %%BeginDocument: test.1
> %!PS
> %%BoundingBox: 9 -3 93 13 
> %%HiResBoundingBox: 9.55 -2.45 92.45 12.25 
> %%Creator: MetaPost 1.803
> %%CreationDate: 2014.01.15:1907
> %%Pages: 1
> %%BeginProlog
> %%EndProlog
> %%Page: 1 1
>  0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
>  [] 0 setdash 1 setlinejoin 10 setmiterlimit
> newpath 10.2 0 moveto
> 10.2 0.05304 10.17892 0.10391 10.14142 0.14142 curveto
> 10.10391 0.17892 10.05304 0.2 10 0.2 curveto
> 9.94696 0.2 9.89609 0.17892 9.85858 0.14142 curveto
> 9.82108 0.10391 9.8 0.05304 9.8 0 curveto
> 9.8 -0.05304 9.82108 -0.10391 9.85858 -0.14142 curveto
> 9.89609 -0.17892 9.94696 -0.2 10 -0.2 curveto
> 10.05304 -0.2 10.10391 -0.17892 10.14142 -0.14142 curveto
> 10.17892 -0.10391 10.2 -0.05304 10.2 0 curveto closepath
> gsave fill grestore stroke
> newpath 10.25 10 moveto
> 10.25 10.0663 10.22366 10.12988 10.17677 10.17677 curveto
> 10.12988 10.22366 10.0663 10.25 10 10.25 curveto
> 9.9337 10.25 9.87012 10.22366 9.82323 10.17677 curveto
> 9.77634 10.12988 9.75 10.0663 9.75 10 curveto
> 9.75 9.9337 9.77634 9.87012 9.82323 9.82323 curveto
> 9.87012 9.77634 9.9337 9.75 10 9.75 curveto
> 10.0663 9.75 10.12988 9.77634 10.17677 9.82323 curveto
> 10.22366 9.87012 10.25 9.9337 10.25 10 curveto closepath fill
>  0 1 dtransform truncate idtransform setlinewidth pop

The bottom "newpath .. pop" works better, but the top "newpath .. stroke"
fails rather spectacularly. The definition of "drawdot" in the
"plain mem" file seems to use currentpen, without setting currentpen.

I believe the semantics of drawdot specify that "withpen" overrides
the current pen, while lack of "withpen" uses the current pen.
Thus, it seems to me, both lines of dots should have been identical.
But they obviously aren't.

Looking further, I believe BOTH of these are incorrect; because
both of them do a "stroke" as well as a "fill", while drawdot
in METAFONT is simply a "fill".

I also see that "withpen pencircle scaled 2" gives different results
from "withpen (pencircle scaled 2)"! In METAFONT there is no difference
between these.

Thus it seems that there are MULTIPLE errors in METAPOST with respect
to drawdot.

The idea of drawdot (see the METAFONT manual page 150) is to
"draw" a one-point path. When making fonts, this can help to
correct pixels at the endpoints of another path (as mentioned there).
With PostScript there is no such problem, at least not usually;
I suppose that's why people who come to METAPOST without beginning
with METAFONT have not used drawdot enough to run into this bug.

I'm kludging around this in my own METAPOST programs until the bug is fixed.

Sincerely, Don