I wanted to make some modifications to "/usr/share/texmf/web2c/updmap.cfg" and following the directions at the top of that file, I modified TEXMFLOCAL/web2c/updmap-local.cfg (/usr/local/share/texmf/web2c/updmap-local.cfg) and ran "tlmgr --generate updmap" and got the error msg about the missing perl module. So I ran "perl-cleaner --reallyall" and tried again but still got missing pm. Next I tried Googling about tlmgr and ran across http://www.tug.org/pipermail/tex-live/2008-November/019297.html So I tried "kpsewhich -expand-var SELFAUTOPARENT": # kpsewhich -expand-var SELFAUTOPARENT SELFAUTOPARENT # kpsewhich '${SELFAUTOPARENT}' # I'm not sure what SELFAUTOPARENT should expand to. I didn't try the other suggestion: export PATH=/usr/local/texlive/2008/bin/i386-linux:$PATH since Gentoo installs most of the texlive binaries to /bin I've tried "tlmgr --generate updmap" on both my x86 and amd64 computers with the same result about unable to find TLConfig.pm I guess I could go ahead and just modify directly "/usr/share/texmf/web2c/updmap.cfg" to suit my needs, but I was trying to follow its directions. Reproducible: Always Steps to Reproduce: 1. tlmgr --generate updmap 2. 3. Actual Results: # tlmgr --generate updmap Can't locate TeXLive/TLConfig.pm in @INC (@INC contains: //texmf/scripts/texlive //tlpkg /usr/lib64/perl5/site_perl/5.10.1/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.10.1 /usr/lib64/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.10.1/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.10.1 /usr/lib64/perl5/vendor_perl/5.10.0 /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/5.10.1/x86_64-linux-thread-multi /usr/lib64/perl5/5.10.1 .) at /usr/bin/tlmgr line 79. BEGIN failed--compilation aborted at /usr/bin/tlmgr line 79. Expected Results: Should find TLConfig.pm and concatenate updmap-local.cfg to /usr/share/texmf/web2c/updmap.cfg app-text/texlive-core-2009-r1 dev-texlive/texlive-basic-2009 Both texlive-2009 suites run otherwise just fine on both my x86 and amd64 computers. I only ran across this problem by accident. I needed to generate a pdf from a postscript file produced with LaTeX using hyperref and eforms packages: # Create dvi: latex form.tex # Create ps: dvips -Pdownload35 -Ppdf -Pamz -Pcmz -G0 form.dvi # Create pdf: ps2pdf form.ps # Check font embedding: pdffonts form.pdf name type emb sub uni object ID ------------------------------------ ----------------- --- --- --- --------- ZapfDingbats Type 1 no no no 12 0 Helvetica Type 1 no no no 15 0 ENZHHN+NimbusSanL-ReguItal Type 1C yes yes no 194 0 BDENKY+NimbusSanL-Regu Type 1C yes yes no 25 0 SEKMAF+NimbusSanL-Bold Type 1C yes yes no 22 0 As you can see, both ZapfDingbats and Helvetica, are not embedded in the pdf When I try to create the pdf from the ps using Adobe's Distiller on Windows XP, it aborts without producing the pdf because it can't find the fonts ZapfDingbats and Helvetica. In my pdf I need to use javascript functions which Adobe restricts (those related to saving fdf data in forms). Either the user must buy the full Acrobat to save form data, or alternatively, the producer (me) must buy Acrobat and use it to Distill the pdf. Rather than force all my users to buy Acrobat, I decided to buy Acrobat for my Windows XP computer and use that to distill my pdf forms. Unfortunately, I encountered the problem with Acrobat not being able to distill a pdf from my postscript because of the missing fonts. So I thought I would try changing the LW35 variable in /usr/share/texmf/web2c/updmap.cfg from URWkb to ADOBEkb. Okular is not (yet) an alternative to Acrobat/AcroReader because it stores the form values in the user's home folder and not as part of the document. And it also doesn't execute javascript -- so javascript functions to do calculations with field data or to submit emails or fdf data don't work.
Still haven't gotten tlmgr to work, but I did figure out why Acrobat was choking on my postscript. I had used the latex package hyperref and used the macro \hypersetup{ pdfstartview={FitH } } to create a pdf with a special pdfmark to initally open document to fit the window width. But after reviewing Adobe's pdfmarkReference_v9 manual, it turns out that the fit type pdfmarks can require arguments, and /FitH requires one argument to specify the distance from document origin to top of window. so the following corrects the postscript so Acrobat doesn't choke \hypersetup{ pdfstartview={FitH 0} } Apparently neither dvips nor dvipdfm check the syntax of pdfmarks and so were able to generate the (broken) pdf whereas Acrobat/Distiller could not. Now either using dvipdfm or dvips+Distiller, I can enable extended Adobe Reader features with AcrobatPro9.0
really, you shouldnt be using tlmgr with the portage installed version of texlive. tlmgr is a package manager made by the texlive team to let you install without help of your distro, it is unneeded and unwanted for us and was a mistake of being left in TeX Live 2009, it will be gone with the portage version of TeX Live 2010.
"it will be gone with the portage version of TeX Live 2010" Users are still trying to use this, and being affected by this breakage in 2017. The breakage, incidentally, is because that horrible mess of code that assigns $MASTER assigns it to '', and then loads '//tlpkg' instead of '/usr/share/tlpkg' Please either nuke this properly or fix the issue.
(In reply to Kent Fredric (IRC: kent\n) from comment #3) > "it will be gone with the portage version of TeX Live 2010" guess it's back :)
(In reply to Alexis Ballier from comment #4) > (In reply to Kent Fredric (IRC: kent\n) from comment #3) > > "it will be gone with the portage version of TeX Live 2010" > > guess it's back :) and gone again Note: I think debian provides some kind of support for tlmgr. If someone is interested in doing the work (I think it is non trivial) we can talk.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3712dc9ee61c9127ef1d3a795efe96a8988bd565 commit 3712dc9ee61c9127ef1d3a795efe96a8988bd565 Author: Florian Schmaus <flow@gentoo.org> AuthorDate: 2024-06-05 11:21:24 +0000 Commit: Florian Schmaus <flow@gentoo.org> CommitDate: 2024-06-05 12:17:23 +0000 app-text/texlive-core: install tlmgr (forced in user mode) We now install tlmgr, but forced in user mode (similar to what Debian does). This means that we now can use commands like "tlmgr conf", which are helpful when debugging issues with the TeX Live installation. Bug: https://bugs.gentoo.org/263194 Bug: https://bugs.gentoo.org/326527 Bug: https://bugs.gentoo.org/832139 Signed-off-by: Florian Schmaus <flow@gentoo.org> app-text/texlive-core/Manifest | 2 +- .../{texlive-core-2023-r6.ebuild => texlive-core-2023-r7.ebuild} | 5 +---- 2 files changed, 2 insertions(+), 5 deletions(-)
