1

Since I could come up with an MWE for the problem, I'm completely rewriting this post - if curious about my original problem, check this past revision (1).

Consider this MWE, test.tex:

\PassOptionsToPackage{dvipsnames}{xcolor}

% compile with: lualatex test.tex

\documentclass[10pt,a4paper]{article}

  \makeatletter
  \newcommand{\name}[1]{\def\@name{#1}}
  \makeatother

  \usepackage[margin=2cm]{geometry}
  \geometry{left=1.25cm,right=1.25cm,top=1.25cm,bottom=1.25cm}
  \usepackage{fontspec}
  \newfontfamily\titlenamefont{EB Garamond}[Ligatures=TeX]
  \usepackage[hidelinks=true]{hyperref}

\begin{document}

  \name{\hspace{4em}\addfontfeature{LetterSpace=10.0}\textsc{Brazen Discovery}}

  \begingroup
    \makeatletter
      {\ifcsname titlenamefont\endcsname\titlenamefont\fi \Huge\bfseries{\@name}\par}
    \makeatother
  \endgroup\medskip

  Testing some normal paragraph text here...

\end{document}

I have an old machine, which has some hardware broken, but can still be used under some circumstances, with Ubuntu 14.04 and TexLive 2014 or 2015 (I've always used TexLive by installing it in an "off" folder, and then adding /path/to/texlive/2014/bin/i386-linux to the $PATH).

Then, I have a new machine, with Ubuntu 14.04 installed from scratch, and TexLive 2014 or 2015 copied from the old machine verbatim (but still at the same path). The compilation process runs OK on both machines, but there is a problem with the fonts.

The old machine reports this:

$ uname -a
Linux myOldPC 4.4.0-57-generic #78~14.04.1-Ubuntu SMP Sat Dec 10 00:16:09 UTC 2016 i686 i686 i686 GNU/Linux
$ echo $(lsb_release -i -d -r -c)
Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty
$ tlmgr --version
tlmgr revision 39298 (2016-01-07 03:44:29 +0100)
tlmgr using installation: /path/to/texlive/2014
TeX Live (http://tug.org/texlive) version 2014
$ lualatex --version
This is LuaTeX, Version beta-0.80.0 (TeX Live 2015) (rev 5238)

When I build with lualatex test.tex, the output finishes with:

$ lualatex test.tex
...
(/path/to/texlive/2014/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
(/path/to/texlive/2014/texmf-dist/tex/latex/oberdiek/grfext.sty)
(/path/to/texlive/2014/texmf-dist/tex/latex/latexconfig/epstopdf-sys.c
fg)) (/path/to/texlive/2014/texmf-dist/tex/latex/hyperref/nameref.sty
(/path/to/texlive/2014/texmf-dist/tex/generic/oberdiek/gettitlestring.
sty)) (./test.out) (./test.out) [1{~/.texlive2015/texmf-var/fo
nts/map/pdftex/updmap/pdftex.map}] (./test.aux))
 301 words of node memory still in use:
   3 hlist, 1 vlist, 1 rule, 2 glue, 3 attribute, 44 glue_spec, 3 attribute_list
, 1 write nodes
   avail lists: 2:42,3:4,4:38,5:22,6:65,7:2,8:2,9:13,10:5
</path/to/texlive/2014/texmf-dist/fonts/opentype/public/lm/lmroman10-re
gular.otf><~/.fonts/EBGaramond08-Regular.otf>
Output written on test.pdf (1 page, 8339 bytes).
Transcript written on test.log.

The PDF document looks like this in evince:

test_old.png

... basically, the title font is sort of bolded, and in small caps - and the fonts embedded in the PDF are:

$ pdffonts test.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
IJJDUA+EBGaramond08-Regular          CID Type 0C       Identity-H       yes yes yes      8  0
QXSXVQ+LMRoman10-Regular             CID Type 0C       Identity-H       yes yes yes      9  0

... that is, EBGaramond08-Regular is included for the title (which corresponds to the <~/.fonts/EBGaramond08-Regular.otf> in the last lines of the lualatex log).

The new machine reports this:

$ uname -a
Linux myNewPC 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:06:11 UTC 2017 i686 i686 i686 GNU/Linux
$ echo $(lsb_release -i -d -r -c)
Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty
$ tlmgr --version
tlmgr revision 39298 (2016-01-07 03:44:29 +0100)
tlmgr using installation: /path/to/texlive/2014
TeX Live (http://tug.org/texlive) version 2014
$ lualatex --version
This is LuaTeX, Version beta-0.80.0 (TeX Live 2015) (rev 5238)

So, pretty much everything is the same, except for the kernel version. When I build with lualatex test.tex, the output finishes with:

$ lualatex test.tex
...
(/path/to/texlive/2014/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
(/path/to/texlive/2014/texmf-dist/tex/latex/oberdiek/grfext.sty)
(/path/to/texlive/2014/texmf-dist/tex/latex/latexconfig/epstopdf-sys.c
fg)) (/path/to/texlive/2014/texmf-dist/tex/latex/hyperref/nameref.sty
(/path/to/texlive/2014/texmf-dist/tex/generic/oberdiek/gettitlestring.
sty)) (./test.out) (./test.out)

LaTeX Font Warning: Font shape `EU2/EBGaramond(0)/bx/n' undefined
(Font)              using `EU2/EBGaramond(0)/m/n' instead on input line 23.


LaTeX Font Warning: Font shape `EU2/EBGaramond(1)/bx/n' undefined
(Font)              using `EU2/EBGaramond(1)/m/n' instead on input line 23.



LaTeX Font Warning: Font shape `EU2/EBGaramond(1)/bx/sc' undefined
(Font)              using `EU2/EBGaramond(1)/bx/n' instead on input line 23.

[1{/path/to/texlive/2014/texmf-var/fonts/map/pdftex/updmap/pdftex.map}]
(./test.aux)

LaTeX Font Warning: Some font shapes were not available, defaults substituted.

)
 310 words of node memory still in use:
   3 hlist, 1 vlist, 1 rule, 2 glue, 1 kern, 4 attribute, 44 glue_spec, 4 attrib
ute_list, 1 write nodes
   avail lists: 2:40,3:4,4:37,5:22,6:65,7:2,8:2,9:13,10:5
</path/to/texlive/2014/texmf-dist/fonts/opentype/public/lm/lmroman10-re
gular.otf><~/.fonts/EBGaramond12-Regular.otf>
Output written on test.pdf (1 page, 7527 bytes).
Transcript written on test.log.

So, besides the difference of 310 words of node memory (vs 301 words of node memory in the case of old pc), there are also undefined font shapes - which, in the case of bx/sc, I guess it means that the bold small caps shape is undefined.

The PDF document looks like this in evince:

test_new.png

... basically, the title font is sort not bolded, and not small caps - and the fonts embedded in the PDF are:

$ pdffonts test.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
JYJWKP+EBGaramond12-Regular          CID Type 0C       Identity-H       yes yes yes      8  0
QXSXVQ+LMRoman10-Regular             CID Type 0C       Identity-H       yes yes yes      9  0

... that is, EBGaramond12-Regular is included for the title (which corresponds to the <~/.fonts/EBGaramond12-Regular.otf> in the last lines of the lualatex log) - but, it does not correspond to the EBGaramond08-Regular used in the build on the old machine ?!

So, I guess my questions are:

  • How come, that more-less the same lualatex on the same OS environment, can pick one font family in one case (old PC build), and another in another case (new PC build), for the exactly same .tex source file?
  • How can I get the build on the new machine, to perform the same and generate the same document, as the build on old machine?

Note that both old and new machine report this:

$ luaotfload-tool --find="EB Garamond"
luaotfload | resolve : Font "EB Garamond" found!
luaotfload | resolve : Resolved file name "~/.fonts/EBGaramond12-Regular.otf"

If I look up the garamond OTF fonts on both systems and compare them, I get:

# $ find / -xdev -iname '*garamond*.otf' 2>/dev/null | sort | tee findold # on old PC
# $ find / -xdev -iname '*garamond*.otf' 2>/dev/null | sort | tee findnew # on new PC
$ diff -U 100000 findold findnew
--- findold 2017-12-05 07:13:18.813205949 +0100
+++ findnew 2017-12-05 07:13:09.413124141 +0100
@@ -1,15 +1,11 @@
 ~/.fonts/EBGaramond08-Italic.otf
 ~/.fonts/EBGaramond08-Regular.otf
 ~/.fonts/EBGaramond12-AllSC.otf
 ~/.fonts/EBGaramond12-Italic.otf
 ~/.fonts/EBGaramond12-Regular.otf
 ~/.fonts/EBGaramond-InitialsF1.otf
 ~/.fonts/EBGaramond-InitialsF2.otf
 ~/.fonts/EBGaramond-Initials.otf
 ~/.fonts/EBGaramondSC08-Regular.otf
 ~/.fonts/EBGaramondSC12-Regular.otf
-~/.fonts/GaramondNo8-Italic.otf
-~/.fonts/GaramondNo8-Medium-Italic.otf
-~/.fonts/GaramondNo8-Medium.otf
-~/.fonts/GaramondNo8-Regular.otf

... so at least I have the same EBGaramond filenames (GaramondNo8 is, I guess, "URW Garamond", not EBGaramond). Turns out, I also have the exact same EBGaramond*.otf files too (apparently, from EBGaramond-0.016.zip - see past revision for code how I got it installed on new PC):

# $ find / -xdev -iname '*ebgaramond*.otf' 2>/dev/null | sort | xargs ls -la | sed "s/$(whoami) $(whoami)//" | tee ls-laold # on old PC
$ find / -xdev -iname '*ebgaramond*.otf' 2>/dev/null | sort | xargs ls -la | sed "s/$(whoami) $(whoami)//" | tee ls-lanew # on new PC
-rw-r--r-- 1  200656 Apr  8  2014 ~/.fonts/EBGaramond08-Italic.otf
-rw-r--r-- 1  259968 Apr  8  2014 ~/.fonts/EBGaramond08-Regular.otf
-rw-r--r-- 1  212492 Apr  8  2014 ~/.fonts/EBGaramond12-AllSC.otf
-rw-r--r-- 1  298252 Apr  8  2014 ~/.fonts/EBGaramond12-Italic.otf
-rw-r--r-- 1  495300 Apr  8  2014 ~/.fonts/EBGaramond12-Regular.otf
-rw-r--r-- 1   60240 Apr  8  2014 ~/.fonts/EBGaramond-InitialsF1.otf
-rw-r--r-- 1    5120 Apr  8  2014 ~/.fonts/EBGaramond-InitialsF2.otf
-rw-r--r-- 1   78512 Apr  8  2014 ~/.fonts/EBGaramond-Initials.otf
-rw-r--r-- 1  226840 Apr  8  2014 ~/.fonts/EBGaramondSC08-Regular.otf
-rw-r--r-- 1  353364 Apr  8  2014 ~/.fonts/EBGaramondSC12-Regular.otf
$ diff -U 100000 --report-identical-files ls-laold ls-lanew
Files ls-laold and ls-lanew are identical

Relevant entries in luatex-cache names also are identical on both old and new PC:

$ zgrep -i ebgaramond /path/to/texlive/2014/texmf-var/luatex-cache/generic/names/luaotfload-names.lua.gz | grep -v '"full"' | grep fullpath | sort
   ["fullpath"]="~/.fonts/EBGaramond08-Italic.otf",
   ["fullpath"]="~/.fonts/EBGaramond08-Regular.otf",
   ["fullpath"]="~/.fonts/EBGaramond12-AllSC.otf",
   ["fullpath"]="~/.fonts/EBGaramond12-Italic.otf",
   ["fullpath"]="~/.fonts/EBGaramond12-Regular.otf",
   ["fullpath"]="~/.fonts/EBGaramond-InitialsF1.otf",
   ["fullpath"]="~/.fonts/EBGaramond-InitialsF2.otf",
   ["fullpath"]="~/.fonts/EBGaramond-Initials.otf",
   ["fullpath"]="~/.fonts/EBGaramondSC08-Regular.otf",
   ["fullpath"]="~/.fonts/EBGaramondSC12-Regular.otf",

... and the only difference seems to be in luatex-cache otf fonts:

# $ ls -la /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond* | sed "s/$(whoami) $(whoami)//" | tee luatex-cache-otf-old # on old PC
# $ ls -la /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond* | sed "s/$(whoami) $(whoami)//" | tee luatex-cache-otf-new # on new PC
$ diff -U 100000 luatex-cache-otf-old luatex-cache-otf-new
--- luatex-cache-otf-old    2017-12-05 07:48:06.679082205 +0100
+++ luatex-cache-otf-new    2017-12-05 07:45:15.625596626 +0100
@@ -1,6 +1,4 @@
--rw-rw-rw- 1  473749 Oct 28  2016 /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond08-regular.lua
--rw-rw-rw- 1  303043 Oct 28  2016 /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond08-regular.luc
--rw-rw-rw- 1  568196 Oct 28  2016 /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond12-italic.lua
--rw-rw-rw- 1  364914 Oct 28  2016 /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond12-italic.luc
--rw-rw-rw- 1  724218 Oct 28  2016 /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond12-regular.lua
--rw-rw-rw- 1  466820 Oct 28  2016 /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond12-regular.luc
+-rw-rw-rw- 1  568148 Dec  4 16:21 /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond12-italic.lua
+-rw-rw-rw- 1  364894 Dec  4 16:21 /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond12-italic.luc
+-rw-rw-rw- 1  724173 Dec  4 16:21 /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond12-regular.lua
+-rw-rw-rw- 1  466728 Dec  4 16:21 /path/to/texlive/2014/texmf-var/luatex-cache/generic/fonts/otf/ebgaramond12-regular.luc

I tried diffing, say, ebgaramond12-italic.lua on old and new machine - but there is simply way too many changes, that are changes of numbers in numeric references (as in ["slookups"]={ 983214, 983316, 983112, 983418 },), so that doesn't reveal much.

Besides that, the only obvious difference is that on the new machine, ebgaramond08-regular.lua/.luc fail to get generated in texmf-var/luatex-cache/generic/fonts/otf/ (and they should get generated if they don't exist upon first next run of lualatex) ... AND, from the lualatex log:

  • old machine uses ~/.texlive2015/texmf-var/fonts/map/pdftex/updmap/pdftex.map (it also has texmf-config in ~/.texlive2015)
  • new machine does not have ~/.texlive2015, and it so uses /path/to/texlive/2014/texmf-var/fonts/map/pdftex/updmap/pdftex.map (apparently?)
    • though, if I run updmap on new machine, ~/.texlive2015/texmf-var gets created (but ~/.texlive2015/texmf-config does not), and then lualatex reads the pdftex.map in it - but the same problem with the fonts persists..

I'm really at loss with how to proceed debugging from here ...

  • 1
    Be aware that the TeX-distributed EBGaramond might not contain all of the fonts! Have a look at the package vis ctan.org, and also have a look at the designer's own web site: georgduffner.at/ebgaramond – user139954 Dec 4 '17 at 15:53
  • 1
    This problem is easy to show in a minimal document. You need only to try to use the font in a small size and \scshape. – Ulrike Fischer Dec 4 '17 at 16:31
  • 3
    There is no bold in the EB Garamond family. At one time, the CTAN package provided an unsatisfactory bold, but that was removed at the request of the font designer. – Thérèse Dec 4 '17 at 18:44
  • 2
    You could try to force the issue with something like \setmainfont{EB Garamond}[BoldFont=EBGaramond08-Regular], but that’s a crime against good taste, and Garamond will be turning in his grave. – Thérèse Dec 4 '17 at 19:26
  • 1
    Thanks @Thérèse - I will try to stay away from crimes against good taste, haha :) I have completely changed the post with an MWE now, and I guess the real question is: how can two systems, with nearly identical OS, TexLive and (relevant) font installations, have a different compilation process (and PDF results) - and how to make it identical again? – sdaau Dec 5 '17 at 7:14
1

Well, I think I solved this somewhat, but it's all kind of patchy - so if anyone knows how I could "repair" this install (but without reinstalling from scratch), I'd love to hear it.

The thing is: while on the old machine, I did install TexLive 2014 / 2015 at the time using the install-tl script (but in an "off" folder, that is to say, folder in a non-system, additionally mounted partition); on the new machine, I simply copied the installation from the old machine's "off" folder to the new machine's "off" folder (i.e. additionally mounted partition, with the same path(name) as the "off" folder on the old machine). (I'm a big fan of running software from externally mounted partitions, with minimal interventions in what would be considered the OS install tree).

I had assumed, that since both (old and new) "off" folders have the same path, all I need to do is add the same /path/to/texlive/2014/bin/i386-linux to the $PATH in .bashrc, and things would work the same - and generally they do (i.e. the executables run as usual). Except, I had forgotten there are additional folders created in $HOME (apparently created by install-tl or tlmgr, although I cannot recall if I created any of them manually).

So, after making sure, as in the OP, that I have the same fonts placed in the new machine at the same location as in the old one, I repeated the copying, this time with the $HOME folders:

rsync -aP oldPC.lan:/path/to/texlive /path/to/
rsync -aP oldPC.lan:~/.texlive2014 ~/
rsync -aP oldPC.lan:~/.texlive2015 ~/
rsync -aP oldPC.lan:~/texmf ~/

After this copy, finally the test.tex as in OP compiled fine, no complaints about undefined font shapes, and the PDF looks the same as the "old" PC example in OP.

I guess, one could say that if the same font files are in the same location at the "new" PC as in the "old" PC (i.e. where the texlive install/luatex-cache would expect them to be, as shown via fc-list), and if the texlive installation is at the same path at the "new" PC as in the "old" PC, - then with the above folder copy, the cached information from the "old" PC will be applicable to the "new" one as well, and Latex compilation will execute in the same manner.

Except, not quite. Before I get to that, note that this command started showing the same output on "new" machine as on "old" only after the above rsync copy:

$ kpsewhich --all updmap.cfg
~/.texlive2015/texmf-config/web2c/updmap.cfg
/path/to/texlive/texmf-local/web2c/updmap.cfg
/path/to/texlive/2014/texmf-dist/web2c/updmap.cfg

Before the copy, the line ~/.texlive2015/texmf-config/web2c/updmap.cfg was not output. As noted in OP, updmap on new machine creates ~/.texlive2015/texmf-var even if ~/.texlive2015 didn't previously exist; but then, what creates ~/.texlive2015/texmf-config ? In this case, I had just copied ~/.texlive2015/texmf-config from the "old" machine to the "new", and because the paths are the same, things happen to work - but I guess it would be more proper to generate ~/.texlive2015/texmf-config using some tool (like ~/.texlive2015/texmf-var is generated by updmap; I had hoped there's a tlmgr --repair for something like this, but no, there isn't. There is tlmgr check all, but it reports the same error on both "old" and "new" machine).

Possibly because of this, I experienced another font issue: after the copy, and confirming that test.tex works, I returned to the original document that caused this trouble, and couldn't compile it because the font Lato was not found. So I copied the Lato files to where luatex-cache would have expected them (in this case, in ~/.fonts/ on "new" machine), and ran:

luaotfload-tool -vvv --update --force

... but after this, the Lato fonts were found - but EB Garamond reverted back to the same error as in the OP! So, after this, I had to re-run the rsync copy process again to "undo" the effects of luaotfload-tool (and the only thing the copy process replaced were lato* and ebgaramond* files in luatex-cache) - and then finally compilation completed as on the "old" machine.

Well, it would be great to know how to restore or repair the copied install on "new" machine, so also the luaotfload-tool call results with working compilation process - but I guess, my usage case is already way too obscure, for that to be a straightforward answer...

  • 1
    Check to see if any of the files or folders are actually links to somewhere else. – user139954 Dec 6 '17 at 0:22
  • 1
    /usr/local is designed for non-system, locally-installed software, by the way. It is its raison d'être. Neither tl-install nor tlmgr touch your home directory (unless you tell them to). However, normal compilation will create directories such as ~/.texliveYYYY. So, unfortunately, with updmap (which you should never use). – cfr Dec 6 '17 at 0:44
  • 1
    When you rerun luaotfload, it deletes the current cache and creates it anew. Since you don't have the same fonts installed on this machine - the same system fonts - the result will correctly omit fonts you don't have. It seems likely that fontconfig is looking in different places or you don't have the same fonts at all or some other muddle is taking place. In general, your 'solution' is extremely fragile and will break. If you installed from upstream, did you configure fontconfig to use fonts from the TeX tree? If not, the fonts in your TeX install are mostly irrelevant. – cfr Dec 6 '17 at 0:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.