Hi John - are there any other packages that support such PDF
functionality?
AcroTeX et al. are problematic not just because of the reader end, but
also because of the writer end, some of which required Adobe software.
The author (Donald Story) was (understandably) not interested in teasing
out the
Thanks for the report. Do they have a tracking system?
No. bug-help2man forwards directly to Brendan O'Dea's email address.
FYI, I sent in a report to bug-help2man. If the output can be made
usable, I'll add it to TL, else maybe give up on help2man and just fix
it by hand as Bjarni wrote originally. We'll see what happens. -k
1) mflua.1 has never been in TeX Live. I guess someone created it for
Debian (or other) without sending it upstream? Anyway, I will copy it
into TL. Although mflua.1 doesn't have the usual Debian disclaimers for
man pages, I assume that's ok :).
2) It would be welcome, and the fixes seem ok in the
it looks like the LuaTeX binaries were compiled with "-g -O2", but
running "readelf" and "objdump" shows that they're stripped, so I
don't think that that's the issue here.
FWIW, it's my understanding that what matters for execution speed is not
the presence or absence of debug symbols
I noticed that there is now a package context-legacy.r69173.tar.xz in
the TL/archive subdir . I contains a lot of stuff
"tex/context/patterns/mkii".
Yes, Siep created context-legacy to continue to support mkii.
I guess I have to package that and upload it into Debian.
Indeed.
The files are not in the "minimal distribution" (which includes binaries,
fonts etc.), but they are still present in the context zip itself.
Mojca - by the "context zip" do you mean cont-tmf.zip? I'm guessing not
.. please advise. Because, as Siep said, the current cont-tmf.zip
contains on
Thanks for bringing this to our attention. The primary wdiff
maintainer (Martin von Gagern) has not been active on the project in
some time so I'm not sure how soon the project will get to it.
Denver, Martin (Martin, are you there?) - in principle, all GNU packages
should be activel
STill, also this will not work for Debian, as here only collection <->
collection relations can be tracked.
If all the hyperref deps are in c-latex (I just moved them), and the
Debian c-latex is installed, why won't hyperref then work?
force me to package at the collection level was a
Subject: colletion-latexbase hyperref.sty depends on collection-latexextra
letltxmacro.sty
Ok, but before I change anything: hyperref has a package-level
dependency on letltxmacro (and a bunch of others). Why doesn't that
suffice?
As far as I can see (per previous mail to the tex-live li
Thanks for the explanation.
I think we should add all known hyperref deps to c-latex, anyway.
Because, why not. It's improbable that anyone would install latex and
not use hyperref, nowadays. I'll do that.
However, I think package-level deps are the only solution to some
(other) problems. -k
esint10.mf
is empty, besides comments and a lone
\endinput
Is this on purpose?
No, I just didn't notice. In the 2019/07/19 update of esint, esint10.mf
is supposed to be generated from esint.dtx, while only that stub file in
fact shows up. I am not sure. Running the
Subject: [pdftex] Add option -synctex to pdftex(1)
I applied this patch (and made some other updates at the same time).
TL r51815. Thanks. -k
not sure if this is the correct mailing list.
It's fine.
Subject: [pdftex] Add option -synctex to pdftex(1)
Sure, why not. Thanks. -k
Hi Hilmar,
... -lfreetype -lz -lgs
/usr/bin/ld: libdvisvgm.a(DLLoader.o): undefined reference to symbol
'dlclose@@GLIBC_2.2.6'
Martin can answer better (cc-ing), but I am under the impression that
dlopen/dlclose are not intended to be used when -lgs was linked. At any
rate, as far as
please move powerdot to -extra!
Moved for tonight's build. Thanks for doing the search. -k
Hi Hilmar,
please consider to move enumitem.sty from texlive-latex-extra to
texlive-latex-recommended or even texlive-latex-base.
I think I'd prefer to move powerdot to c-latexextra, instead of adding
enumitem to c-latexrecommended (I see no need for c-latex[base). But if
you think that w
It looks like a good idea to move ifplatform to collection-base ???
Agreed, moved, thanks. -k
I think in this particular case it would be better to move them to the
docfiles?
Sure, agreed. Moved for tonight's build (in upstream TL). Thanks. -k
Added wordcount.sh to TeX Live for tonight's build. Thanks. -k
I'm fine with installing patches in TL. If Thorsten wants to create his
own ttf2pk2 somewhere as the upstream, and have us (TL) pull from there,
that's fine too.
Thanks,
Karl
Do you think (or AKira) that this is the problem for mips?
For sparc I am a bit stymed.
Yes, it's all about BigEndian architectures (and ICU and upmendex).
(And don't bother explaining that sparc is endian-neutral, the practical
reality is that it is still bigendian in our world.)
And the
On another front:
@iftex
@macro cl{name}
{@smallertt@phantom{concurrency:}@llap{cl:}}\name\
@end macro
@end iftex
What's inside @iftex is supposed to be valid Texinfo.
(Just like @ifinfo, etc.) To lapse into plain/raw TeX,
@tex should be used. That's why it exists.
(Of
I reported it here: http://tracker.luatex.org/view.php?id=965
I'm glad Luigi could eventually reproduce the problem.
Why luatex loads different files depending from which directory it is
run?
I cannot explain anything about luatex behavior, which is (especially at
the moment) in a c
Hi Igor,
checksum mismatch in local font cmb10 (-770990554 != -770990554)
This is complaining that a number is not equal to itself, clearly a
representation problem as you describe. I think you should report it,
with your analysis, on tracker.luatex.org. Perhaps it is already fixed
in t
Hi Norbert,
I am not sure, but it might be related to this discussion on
the fontinst mailing list:
http://www.tug.org/pipermail/fontinst/2016/001692.html
No, Igor is reporting something unrelated, purely in LuaTeX's handling
of vf files. The fontinst issue that Michael and L
> Also, "man ofm2opl" says about "-charcode-format" option,
> which does not exist:
Sorry, that describes on the legacy WEB version, now we call
it as 'wofm2opl'. Try wofm2opl --help.
In the C version, 'ofm2opl', the corresponding option
is -char-format.
Akira, if the only
lots of mails here
Indeed. I'm afraid I can't keep up, so after these short replies, I'm
bowing out of this thread.
I still don't see why you are opposing
the idea to have different versions of the same program installed,
and wanting to be able to *check* all of them.
I don't op
would be useful for install-info to be able to do some transformation,
along with a transformation of the filename. (Karl, please explain why
you think this is a bad idea.)
Having I-I being able to transform dir file entries I have no particular
objection to. I suppose that is the way
Perhaps it's naive, but I feel like I might just want a dir like this so
that I can find what I want and don't have to change global state and/or
restart the viewer just to read different versions:
I agree. You can have that now. It does not need new features, so far
as I can see. J
That doesn't happen, and nobody seems to miss it. If the shell can
avoid a lot of complexity handling multiple versions of programs, I
suspect it may not be necessary for documentation either.
Indeed. Which is why I don't understand why we're having this whole
thread. Sorry. It seem
Here's what I don't get: suppose there are two versions of Emacs
installed, emacs-x and emacs-y. Presumably Debian (and anyone else) has
some method for the user to choose which one is invoked by just "emacs".
Can't that method, whatever it is, also switch the Info files that are found?
For insta
> * my wish list: support of sub directories and links within subdirs
> in this case selecting a link would *first* search for the
Hmm. Sadly, I just cannot comprehend -- this seems like an
unspecifiable, unmanageable, mess. I expect I'm missing something.
Officially supporting
/usr/share/info/emacs-24/emacs.info.gz
FWIW, to the best of my knowledge, $(infodir) has always been a flat
directory, and dir files a flat namespace. The problem of multiple
versions, similar to multiple languages, has never been satisfactorily
resolved. This is the first time I hav
> l.56 \initial {\\}
Works for me with current texinfo.tex and the input below (to force
creating the \initial line). I don't doubt there was a bug in some
version of texinfo.tex in this regard, but I routinely run Texinfo
documents with \indexentries, so I doubt it existed for long. -k
---
* coreutils: (coreutils)coreutils invocation. Multi-call program.
I do not have a program named "coreutils" on my system, despite the
documentation, and I installed coreutils-8.23 from original sources.
Maybe coreutils.texi should not contain this Info entry?
Not that that particular case h
- move euenc to collection-latexrecommended
It's tiny, so ok. Also makes sense, in that if fontspec+luatex wants to
read it, it is not xetex only.
By the way, there is no fontspec-luatex package in TeX Live.
But I get the drift.
- make collection-luatex depend on collection-xetex
Certa
I just committed changes to texlive-ru and texlive-en such that lmodern
is not loaded for texlive-ru. I also added the line
\usepackage[T2A]{fontenc}
to texlive-ru.tex, which seemed to be the other crucial change. I
assumed the textual changes were related to (the many) changes
between 2010 and 2
Norbert and all,
It seems I added the t2alm*.fd files in 2012, sent to me by Vladimir
Lomov (cc'd) as part of an update to the Russian translation of the TL
guide.
http://tug.org/svn/texlive/trunk/Master/texmf/doc/texlive/texlive-ru/t2almr.fd?view=log&pathrev=29712
(I unfortunately misspelled his
Hi Juliusz,
What about mnsymbol? It's a fairly small package, and is a simple,
hassle-free way to get a bunch of mathematical symbols that blend
relatively well with many common fonts
I guess I don't have any overwhelming argument against it, but it would
be nice if I had a note from
Do what you want in Debian, of course. (Do you exactly 100% follow the
TL collection constituents now?)
For TL, I see that c-fontsrecommended has txfonts and pxfonts. Perhaps
I should exchange those with the newtx and newpx in extra, but I'm not
sure. I have a feeling that an awful lot of docum
as far as I understand it seems that at least Karl Berry agrees in
that regard)
I hadn't realized that the ligatures only failed with non-fully-embedded
PDF's. Such PDF's are inherently defective; it's been a long time since
Adobe recommended anything but full embeddi
FWIW, I don't see how adding "ff" and the like to the OT fonts simply as
independent glyphs for rendering, not related to any OT or Unicode
ligature mechanism, could confuse anything.
I agree the real bug is in poppler (and/or Debian's choice of using
these OT fonts without sufficient testing), bu
revert to the old-style names in the OTF
Seems like there should be no need to revert. In principle, couldn't
the fi ligature glyph appear as both "f_i" and "fi"? In other words,
add a bunch more duplicate glyphs; nothing else need change, as I
understand it ... f + i would still lead to f_i
The problem is that the ligatures are named
f_i
Adobe wants it that way these days, as I understand it. (Personally I
think they were terribly wrong to try to change something so fundamental
but, surprisingly, they didn't ask me. :)
See section 6 (or search for ligature) in
htt
Jerome said:
> i can't actually build the tool and make live tests but a careful
> reading shows that all the changes really make sense and look ok
So we should go ahead and apply the proposed changes in TL.
Ok, Peter?
Thanks,
Karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.de
What do you think?
Seems clear to me, but I forwarded the message to Jerome (Laurens).
As the synctex author, he's the one who should be in the loop :).
I will report back if he replies to me.
Thanks,
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
Is there a reason for it, and why do we not switch to ttf2pk2
and get rid of one more lib in libs?
Peter removed freetype1 and ttf2pk in the sources some time ago,
so they'll be gone in TL 2014.
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
I am not sure who is currently maintaining mendex,
As you know, it was part of the general Japanese-TeX import into TL, so
I suppose you and Akira are :), with the rest of us chipping in as
necessary.
Please apply whatever patch you see fit.
#define TAIL(x) (x+strlen(x))
The first x o
Foo. Bar.
Foo. Bar.
Foo. Bar.
NaN. Bar.
NaN. Bar.
NaN. Bar.
with texinfo 5.1.dfsg.1-4 (I've removed the blank lines).
What are you reporting? The above looks correct to me; the previous
behavior (of preserving intersentence spacing in some situatio
> texi2html, which texinfo superseeds, allowed the rendering of @math
> environments to images in HTML output. Please add similar functionality
> to texinfo.
Is this planned
Well, Patrice and I haven't talked about that specifically. Patrice?
(We have had other discussions about
> Hi Karl, hi all,
We need peb's input on this. I expect it can be done for TL'14.
Thanks,
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> $ echo $LINES $COLUMNS
> 64 208
>
> Start info with the make info file from make-doc 3.81-5.1:
> $ info make
>
> Enter these keystrokes:
> i p TAB TAB
>
> Result: segfault.
I can reproduce this, even without all the special compiler flags (-g on
> ../../../binutils/doc/binutils.texi:4378: warning: @itemx should not
begin @table
> ../../../binutils/doc/binutils.texi:4386: @itemx must follow @item
It's a real error in the Texinfo, that unfortunately C makeinfo did not
diagnose. It needs to be reported to the binutils maintainers.
The following additional files are here:
uhvbrc8a.pfb
uhvboc8a.pfb
uhvrrc8a.pfb
uhvroc8a.pfb
Ok, I removed them. Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi Frank and Saulo,
Thanks for the report.
1. I moved adjustbox to collection-latexextra.
2. Yes, in general, satisfying dependencies with the static collection-*
assignments we have is impossible, for a variety of reasons. This is
one reason why everything is installed by default (in the origi
Cross-manual links should work correctly in the next release of
makeinfo, and not depend on "being in the same place". We've expended a
lot of effort on the problem. You can try the development version if
you like. I hope a first pretest will happen fairly soon.
Until then, what I have done is
FWIW, I agree with Norbert's analysis regarding cyrfonts and have
nothing to add ...
k
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi Norbert,
to go to the Top dir file again showed nothing.
After removing the hardening flags it worked again, so I assume that is
is related to that. The way we are compiling is wiht
FYI: we are finally getting close enough to a texinfo pretest that I
tried your "hardening" recipe
Is there something that has been checked in *after 2012-05-16
r26437 | peter | 2012-05-16 09:44:41 +0200
shows kpse_cnf_get being re-exported. I see nothing in cnf.c now that
would stop the symbol from being exported.
Maybe you did your build just before that change? Don't know how else
to
I have no knowledge of what is in Debian where. Thanh sent me a change
that fixed it for him. I committed it some days ago, likely after May 16.
k
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.o
!pdfTeX error: pdflatex (file ./test.pdf): PDF inclusion: /Group
dict missing
==> Fatal error occurred, no output PDF file produced!
Well, I'm glad it doesn't crash any more. I recall Thanh (or someone)
making fixes in this area.
As for the actual problem, I've forwarded it to Thanh
np> somewhere between 20120410 and20120510 it seems that
cnf.h
is not installed anymore.
Peter changed kpathsea/Makefile.am not to install cnf.h and several
other .h's. I'm not sure why, or if he and I discussed it. Peter?
k
On Di, 15 Mai 2012, Michael Biebl wrote:
> Packa
Isn't there any way to actually fix this bug and allow the coexistence
of scalable-cyrfonts-tex and texlive-fonts-extra?
The cyrfonts filenames would have to be changed. Whether doing that
would be worse than the current conflict is not my call.
Is there any alternative TeX font pack
A diff against the latest CVS version of the info directory is
attached.
I applied it. Thanks.
k
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
By the way, the package is already called ÂâÂÂucsÂâ in TeXLive.
I know :).
How can I change the package and directory name on CTAN?
In general, request the change of CTAN maintainers when you make the
upload, and they will discuss it with you. And yes, I would upload with
th
I wonder whether it is sensible to always call the package ucs
Please do. There are far too many gratuitious name differences already,
and ucs is at least a little more specific than "unicode".
Thanks,
k
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
Does anyone have an idea why this might happen?
Not out of my head. And Sergey's main server (gnu.org.ua) apparently
developed hardware woes, so I doubt he'll be able to answer anything
Texinfo-related quickly.
(I tried compiling current sources, but that didn't work out,
Sergey has ma
After some tests. I changed kpathsea/getopt.h to omit the declaration of
getopt when compiling under C++. We'll see if problems arise on other
systems.
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists
After some tests, I removed the popen/pclose declarations from
kpathsea/c-std.h. We'll see if problems arise on other systems.
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi again Julian,
I wonder which library the getopt(_long) calls are
taken from - is it from the kpse library or the libc++ library? If
the prototypes are different, are the behaviours different as well?
If so, might it be wiser to rename the functions so that the behaviour
is
Hi Julian,
Perhaps the simplest solution is to rename the kpathsea
version as kpse_getopt
I don't think that's simple -- requires investigating/changing all uses
of getopt(_long) everywhere in the source. It would make sense in the
long term, but don't want to go there now, just for the
Both header files are included by FileFinder.cpp (part of dvisvgm
[part of TL source code]) and g++ 4.7 refuses to compile the source
Sigh. Well, I suppose we can add !defined (__cpluscplus) easily enough.
If someone would like to send me a patch, that would be nice, else I'll
look at it
Hille,
Regarding the popen/pclose companion bug:
[2] http://bugs.debian.org/64524
I rather suspect they are declared in the headers of all systems on
which one would compile TL nowadays, so my first thought is simply to
remove those declarations altogether from c-std.h.
If someone would lik
So my question before uploading a fixed version is: based on his
reply, am I allowed to add his original PDF documentation to the
package?
Mojca, if you want to include the original PDF in the CTAN upload, feel
free to do so. Indeed, I think it makes some sense to do that. It is
easy
Hi Norbert,
I think you missed one point ... thumbpdf didn't have real problems,
I was simply reacting to the error messages you reported, since I didn't
have anything else to go on.
I also have the feeling that it comes from the fact that texi2pdf
is run two times, and the second ti
Package thumbpdf Warning: Missing driver name.
I didn't look, but I doubt texi2dvi actually "works" with thumbpdf,
given the name. DVI ... PDF ... not the same thing :).
Package thumbpdf Warning: Compressed PDF objects of PDF 1.5 are not
supported.
Well, this seems clear enough. th
Done that, see the diffstat at the head of the individual patches.
I installed it for dvips, with doc tweaks.
I await ChoF/et al. reply before doing *dvipdfmx.
Thanks,
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Con
I attach the two patches, both apply (with some fuzzyness) to current
sources in TeX Live.
I agree with Peter. I installed the second patch.
Thanks, Mathias and all!
karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
Is there schedule for a new texinfo package?
No.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi Akira,
I think there is no 2G limit for the output file in the
present dvips even in 32bit systems.
Right, as I already explained, there is no limit specifically in dvips.
I can only surmise that on w32 the compiler does 64-bit file stuff by
default. Unless you did a ton of 64-bit stu
dvips seems to have a size limit for output postscript files:
http://bugs.debian.org/383781 at least on 32bit systems. Is there any
chance to fix this?
Hi Hille -- the short answer is no (as far as I can tell).
Here's the long answer:
Despite your laudable attempts at recompiling wit
It is now on CTAN, hence I guess it will be in TL 2010, right?
Right.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Subject: Re: Bug#588378: texlive-latex-base-doc: oldgerm.sty documentation
missing
I asked RobinF about making oldgerm.pdf or if he'd rather we upload it.
(My experience is that he usually prefers to create it himself.)
k
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@li
Well, I definitely do not want to add set -e to our fundamental scripts
a week before our final release. But if you want to add it for Debian,
I don't know of any specific reason not to. You can experience the
pain, or lack thereof.
As I've written before:
- I am not a fan of set -e in general,
Regarding
http://bugs.archlinux.org/task/20065?dev=1047
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501520
http://www.feferraz.net/en/P/Flashcards_in_LaTeX
Unfortunately Fernando's patch apparently no longer works with the
current geometry. I get:
./flashcards.cls:88: Package keyval E
Hi Vladimir,
You are surely right that other filename-related race conditions exist,
and that adding the pid to the temp file for fls is merely a palliative,
not a fix. However, since that's the case that was reported, and since
it was easy to do, it seemed worth doing. That's all.
Thanks,
Karl
recorder_name = (string)xmalloc(strlen(kpse_program_name) + strlen(pid_str)
+ 5);
I knew I was forgetting something obvious. Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
I made the change below (this is web2c/lib/openclose.c), let me know if
problems. I hope compilers won't give any guff about the cast and sprintf.
k
--- openclose.c (revision 17609)
+++ openclose.c (working copy)
@@ -37,12 +37,19 @@
static void
recorder_start(void)
{
-/* Alas, while we mi
> but I wonder, why use intermediate file for recorder at all? Why not to
> open $(jobname).fls in the first place?
Don't want to overwrite the file from a previous run, I suppose.
I'm not enthused about using mkstemp (and providing a fallback), but
perhaps we can add the pid to the temp
9 #ifdef KPATHSEA
10 #include
11 #include
12 #include
13 #endif
In general, I think #include must come first, and
should replace the #include .
/usr/include/kpathsea/types.h:66: error: expected
specifier-qualif
> command is expected to create the file a.pdf, but the pdf is written
> to stdout:
>
> epstopdf --filter --outfile=a.pdf < a.ps
Thanks for the report.
Want to try this version before I release it?
(It once again lets --outfile override --filter. I'll clarify the man
page, too.)
Hi Frank,
Is there a reason not to include this? It appears to me as if TeXLive
contains the contents of CTAN://fonts/urw/antiqua/uaq.zip,
Plus the contents of urw/antiqua, it looks like. More or less. Sort of.
not of CTAN://fonts/psfonts/urwvf/*.
Well, in theory we could insta
Unfortunately, the POT file is very out of date
(http://translationproject.org/POT-files/gnulib-1.0.0.1991.dbebf.pot
Gnulib folks -- perhaps we should set up a cron job to update it
monthly, or some such?
Unfortunately I don't know how the previous pot was generated. Maybe
a Makefile cou
First, I checked in the fix for pdfxmltex.ini.
(/home/norbert/tl/2009/texmf-dist/tex/context/base/supp-pdf.mkii
! You can't use `macro parameter character #' in horizontal mode.
l.82 \def\@@mptopdf@@twodigitrounding#
Is there any way to "escape" into TeX in an xmltex document?
An
I think it is a matter of time when somebody as for revtex4 class option
wrapper in order to use documents written using revtex4 package.
FYI, I suggested that to the APS as soon as I realized what had happened
with revtex4.1 (ie, that revtex4.cls had disappeared). They rejected
the idea.
>
/home/hille/ptex-bin-3.1.10+0.04b/tetex-src-3.0/texk/web2c/ptex-src-3.1.10/tex2.c:3476:
> undefined reference to `kpse_make_tex_discard_errors'
I speculate that a different (old) types.h is being read in the tex*.c
compilations, because otherwise the identifier
kpse_make_tex_discard_err
> because etex is gone.
etex is not gone. That would be crazy. If you deleted it in Debian,
please undelete it.
- first the TEX seting in texmf.cnf should be changed,
I don't agree. As far as I can see, etex is exactly the right thing to
be using, and there is no alternative.
-
#6 0x7fffeac0c509 in kpse_fontmap_lookup () from
/usr/lib/libkpathsea.so.4
I feel completely brainless these days, but kpathsea/ChangeLog has this
entry:
2007-08-27 Karl Berry
* fontmap.c (map_file_parse): free the original pointer, not the
potentially moved one
xfrac.sty from collection-mathextra needs template.sty from
collection-latex3. I didn't test any other components of the mh package
(in which xfrac.sty is included).
It's up to you to decide whether it is possible to fix that by moving
around packages or letting mathextra depe
1 - 100 of 224 matches
Mail list logo
