<div dir="ltr">Two developments today:<div><br></div><div>Herbert updated pst-barcode to embedd the fonts. CTAN will be updated shortly.</div><div><br></div><div>I did confirm what Paulo Cereda said, Fedora 26 does not exhibit the problem. In fact after checking some other machines, the problem seems to be bound to Ubuntu.</div><div><br></div><div>Paulo Ney</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 5, 2017 at 4:57 AM, Zdenek Wagner <span dir="ltr"><<a href="mailto:zdenek.wagner@gmail.com" target="_blank">zdenek.wagner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">2017-08-05 10:10 GMT+02:00 Norbert Preining <span dir="ltr"><<a href="mailto:preining@logic.at" target="_blank">preining@logic.at</a>></span>:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="m_-6233846737237908561gmail-">> The other one is - TL installation and maintenance should not interfere with the way Evince displays a PDF. It works fine before and then it breaks after the installation. As Norbert said it is probably doing something really wrong with those two fonts.<br>
<br>
<br></span>
It is not the TL installation, but the fact that you did make available all fonts to fontconfig. This is an optional step and of course influences *every* program that uses fontconfig.<br>
<br>
They ask for a font name like "Helvetica" and fontconfig returns whatever thinks for best to it. By adding a bunch of fonts, several providing the name Helvetica or something similar, there will be a change.<br></div></blockquote><div><br></div></span><div>It is even more complex:<br></div><div>1. Each PDF viewer has its own substitution rules<br></div><div>2. Fontconfig has its own suibstitution rules<br><br></div><div>It is hard to say which rule wins. In addition, fonconfig is built in such a way that it always returns a glyph. If the glyph does not exist in the current font, it takes it from another font. Suppose that you want to typeset città and you select a font containing only US ASCII. Fontconfig returns c, i, t from the selected font but à is not there, fonconfig therefore selects it from another font which it considers compatible.<br><br></div><div>Okular has the most useful substitution rules at least for the documents that I have to read but embedding is the only reliable solution. Do not waste time by tweaking substitutions, it may work on your computer but you will be surprised what can happen if you give your files to someone else. <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
Nothing TL can influence or change.<span class="m_-6233846737237908561gmail-HOEnZb"><font color="#888888"><br>
<br>
Norbert</font></span><div><div class="m_-6233846737237908561gmail-h5"><br></div></div></div></blockquote></span><div><br><div><div class="h5"><br clear="all"><div><div class="m_-6233846737237908561gmail_signature">Zdeněk Wagner<br><a href="http://ttsm.icpf.cas.cz/team/wagner.shtml" target="_blank">http://ttsm.icpf.cas.cz/team/<wbr>wagner.shtml</a><br><a href="http://icebearsoft.euweb.cz" target="_blank">http://icebearsoft.euweb.cz</a></div></div>
<br> </div></div></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="m_-6233846737237908561gmail-h5">
<br>
<br><br><div class="gmail_quote">On August 5, 2017 6:19:55 AM GMT+09:00, Paulo Ney de Souza <<a href="mailto:pauloney@gmail.com" target="_blank">pauloney@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Zdenek,<div><br></div><div>Thanks for putting laying bare what is going on.</div><div><br></div><div>There are two issues here, one that is not TL's problem which is PST-barcode producing files with Helvetica and Courier when the user has not requested - it should use just plain standard TeX fonts, most probably LM fonts, and use Helvetica and Courier only if the user so requests. I'll take the issue up with Herbert.</div><div><br></div><div>The other one is - TL installation and maintenance should not interfere with the way Evince displays a PDF. It works fine before and then it breaks after the installation. As Norbert said it is probably doing something really wrong with those two fonts.</div><div><br></div><div>Paulo Ney</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 4, 2017 at 1:52 PM, Zdenek Wagner <span dir="ltr"><<a href="mailto:zdenek.wagner@gmail.com" target="_blank">zdenek.wagner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span>2017-08-04 22:37 GMT+02:00 Paulo Ney de Souza <span dir="ltr"><<a href="mailto:pauloney@gmail.com" target="_blank">pauloney@gmail.com</a>></span>:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Zdenek,<br><br></div>I did expect that embedding was the problem I was seeing, but I am after the source of the problem -- because:<br><br></div>1- XeLaTeX embeds fonts by default, so if in this simple case it is not embedding, something is wrong, possibly with PST-barcode, possibly XeTeX.<br></div></div></div></blockquote><div><br></div></span><div>XeLaTeX embeds fonts if it is requested in the config file of xdvipdfmx which is the default (for good reasons). PST-barcode creates an EPS file and dvipdfmx inserts it to the output PDF. The fonts are embedded only if they are embedded in the EPS file which is not the case. <br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div>2- I have tons of files that do NOT have embedded Courier and Helvetica (created by other tools) on my machine. The installation of TL should not mess up with my ability to view them.<span class="m_-6233846737237908561gmail-m_2124742483396554294m_-2138009446993709177gmail-HOEnZb"><font color="#888888"><br></font></span></div></div></blockquote><div><br></div></span><div>The algorithms for representing unembedded fonts are quite complex and are defined in the config files of the viewers. A subtle change in te font name or font id may play a significant role. In addition, you never know what are the exact substitution rule in a particular viewer. TL does not interact with the PDF viewers. Of course, you can manually install TL fonts so that a particular PDF viewer will find them but you never know what happens if you give the file without embedded fonts to someone else. I have seen a lot of different problems, some of them really weird. And a few years ago it cost me quite a lot of money because the phototypesetter intepreted them in a really different way than my printer. Thus verification of at least partial compatibility with PDF/X or PDF/A is a must.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span class="m_-6233846737237908561gmail-m_2124742483396554294m_-2138009446993709177gmail-HOEnZb"><font color="#888888"><br></font></span></div><span class="m_-6233846737237908561gmail-m_2124742483396554294m_-2138009446993709177gmail-HOEnZb"><font color="#888888">Paulo Ney</font></span><div><div class="m_-6233846737237908561gmail-m_2124742483396554294m_-2138009446993709177gmail-h5"><br></div></div></div></blockquote><div><div class="m_-6233846737237908561gmail-m_2124742483396554294h5"><div><br><br clear="all"><div><div class="m_-6233846737237908561gmail-m_2124742483396554294m_-2138009446993709177gmail_signature">Zdeněk Wagner<br><a href="http://ttsm.icpf.cas.cz/team/wagner.shtml" target="_blank">http://ttsm.icpf.cas.cz/team/w<wbr>agner.shtml</a><br><a href="http://icebearsoft.euweb.cz" target="_blank">http://icebearsoft.euweb.cz</a></div></div>
<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="m_-6233846737237908561gmail-m_2124742483396554294m_-2138009446993709177gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 11:11 PM, Zdenek Wagner <span dir="ltr"><<a href="mailto:zdenek.wagner@gmail.com" target="_blank">zdenek.wagner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Paulo,<br><br></div>pdffonts says in our case emb=no which means that the font is not present in the PDF. The rendering engines is then (almost) free to do whatever it wants. Usually the engines have their built-in fonts. If a font with the same name is found, it is usually used but it need not be the intended font. If it is not found, the rendering engine often has replacement rules and selects a font. If there is no matching replacement rule, either a default font is used or nothing is displayed at all. Thius is why documents without embedded fonts look differently in different viewers. Usually ghostscript has reasonalbe replacements so you can often fix the problem by post-processing the PDF file by ps2pdf (yes, it is able to build another PDF from a PDF).<br><br></div><div class="gmail_extra"><span><br clear="all"><div><div class="m_-6233846737237908561gmail-m_2124742483396554294m_-2138009446993709177gmail-m_-2626553090463202854m_-6822800598338112654m_2293003422649979161gmail_signature">Zdeněk Wagner<br><a href="http://ttsm.icpf.cas.cz/team/wagner.shtml" target="_blank">http://ttsm.icpf.cas.cz/team/w<wbr>agner.shtml</a><br><a href="http://icebearsoft.euweb.cz" target="_blank">http://icebearsoft.euweb.cz</a></div></div>
<br></span><div><div class="m_-6233846737237908561gmail-m_2124742483396554294m_-2138009446993709177gmail-m_-2626553090463202854m_-6822800598338112654h5"><div class="gmail_quote">2017-08-04 5:29 GMT+02:00 Paulo Ney de Souza <span dir="ltr"><<a href="mailto:pauloney@gmail.com" target="_blank">pauloney@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I imagine people are doing this for the sake of XeTeX, and not really to use TeX fonts in LibreOffice...so it should be on TL's lap the responsibility to get these fonts to XeTeX without damaging anything else on the machine - specially a PDF viewer, like Evince.<div><br></div><div>It definitely should come out of the manual -- because under the tow of that section, tons of people are recommending that all over SX and other places. Better yet, the section should probably say</div><div><br></div><div> ** DO NOT DO THIS ** It was recommended in the past, but we know better now that ....</div><div><br></div><div>In the TeX world we are acquainted with a lot of blind-recipes like updmap, mktexlsr, texhash, ... some of them people have no idea what is going on, so if it is a recipe out there - it should be a good one!</div><div><br></div><div>I still do not know who is at fault here... Is it the PDF file? PST-barcode? fc-cache? The machine? Evince?</div><span class="m_-6233846737237908561gmail-m_2124742483396554294m_-2138009446993709177gmail-m_-2626553090463202854m_-6822800598338112654m_2293003422649979161HOEnZb"><font color="#888888"><div><br></div><div>Paulo Ney</div><div><br></div><div><br><div><br></div><div><br></div></div></font></span></div><div class="m_-6233846737237908561gmail-m_2124742483396554294m_-2138009446993709177gmail-m_-2626553090463202854m_-6822800598338112654m_2293003422649979161HOEnZb"><div class="m_-6233846737237908561gmail-m_2124742483396554294m_-2138009446993709177gmail-m_-2626553090463202854m_-6822800598338112654m_2293003422649979161h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 6:32 PM, Norbert Preining <span dir="ltr"><<a href="mailto:preining@logic.at" target="_blank">preining@logic.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ok, a bit more relaxed answer ...<br>
<span><br>
> cp $(kpsewhich -var-value TEXMFSYSVAR)/fonts/conf/texliv<wbr>e-fontconfig.conf<br>
> /etc/fonts/conf.d/09-texlive.c<wbr>onf<br>
> fc-cache -fsv<br>
<br>
</span>I know that this is in the manual, but I *STRONGLY* advice against it.<br>
There are some broken fonts, some that mess up fontconfig due to naming<br>
issues, all kind of bad things can happen. In Debian I have been pushed<br>
to do this for long time, but always rejected and recommend people<br>
adding only those fonts one by one that they are actually use.<br>
<br>
Just my 2Yen<br>
<br>
Norbert<br>
<br>
--<br>
PREINING Norbert <a href="http://www.preining.info" rel="noreferrer" target="_blank">http://www.preining.info</a><br>
Accelia Inc. + JAIST + TeX Live + Debian Developer<br>
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</blockquote></div><br></div></div><span class="m_-6233846737237908561gmail-">
--<br>
PREINING Norbert + TeX Live & Debian Developer + <a href="http://www.preining.info" target="_blank">http://www.preining.info</a><br></span><span class="m_-6233846737237908561gmail-">
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13</span></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>