[tex-live] possible bug or mistake ...

Paulo Ney de Souza pauloney at gmail.com
Sat Aug 5 01:01:27 CEST 2017


On Fri, Aug 4, 2017 at 2:49 PM, Zdenek Wagner <zdenek.wagner at gmail.com>
wrote:

>
>> The problem is not which fonts are used but they are not embedded. It is
> not sufficient to just request LM or TeX Gyre, they must be embedded which
> is not a simple tast without having a complete PostScript interpreter which
> XeLaTeX is not.
>


Yeahhh ... but there is a huge difference in between the two here:

Embedding Helvetica and Courier are hard because the machine at play may
NOT have them to begin with.

Embedding LM or TeX Gyre is easy -- you just make a fake undisplayable text
(as part of the PDF file) with all the font characters -- in our specific
case only 14 characters are needed.



>
>> 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.
>>
>
> The biggest problems I have ever seen were caused with Times, Helvetica
> and Courier. Even Adobe violates its own specification. Another problem is
> fontconfig because it does not always work according to its specification.
> So the source of the trouble may be fontconfig, not TL, not Evince. It is
> difficult to guess. I had two computers with the same version of Fedora,
> the same version of TL, the same installed fonts, the same config files for
> fonconfig. On one computer everything worked, on the other I got weird
> errors. The problem was that fontconfig apparently did not obey the
> configured order of directories when searching for the fonts.
>
>
> Zdeněk Wagner
> http://ttsm.icpf.cas.cz/team/wagner.shtml
> http://icebearsoft.euweb.cz
>
>

I hear what you are saying. Paulo Cereda has just told me that is is NOT
occurring on TL'17 under Fedora. So far we have seen it on all Ubuntu
machines we have installed since 2015. So it looks like the problem is
distribution specific.

Paulo Ney



>
>
>>
>> On Fri, Aug 4, 2017 at 1:52 PM, Zdenek Wagner <zdenek.wagner at gmail.com>
>> wrote:
>>
>>> 2017-08-04 22:37 GMT+02:00 Paulo Ney de Souza <pauloney at gmail.com>:
>>>
>>>> Hi Zdenek,
>>>>
>>>> I did expect that embedding was the problem I was seeing, but I am
>>>> after the source of the problem -- because:
>>>>
>>>> 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.
>>>>
>>>
>>> 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.
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> 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.
>>>
>>>>
>>>> Paulo Ney
>>>>
>>>>
>>>
>>> Zdeněk Wagner
>>> http://ttsm.icpf.cas.cz/team/wagner.shtml
>>> http://icebearsoft.euweb.cz
>>>
>>>
>>>
>>>>
>>>> On Thu, Aug 3, 2017 at 11:11 PM, Zdenek Wagner <zdenek.wagner at gmail.com
>>>> > wrote:
>>>>
>>>>> Hi Paulo,
>>>>>
>>>>> 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).
>>>>>
>>>>>
>>>>> Zdeněk Wagner
>>>>> http://ttsm.icpf.cas.cz/team/wagner.shtml
>>>>> http://icebearsoft.euweb.cz
>>>>>
>>>>> 2017-08-04 5:29 GMT+02:00 Paulo Ney de Souza <pauloney at gmail.com>:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>      ** DO NOT DO THIS ** It was recommended in the past, but we know
>>>>>> better now that ....
>>>>>>
>>>>>> 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!
>>>>>>
>>>>>> I still do not know who is at fault here... Is it the PDF file?
>>>>>> PST-barcode? fc-cache? The machine? Evince?
>>>>>>
>>>>>> Paulo Ney
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 3, 2017 at 6:32 PM, Norbert Preining <preining at logic.at>
>>>>>> wrote:
>>>>>>
>>>>>>> Ok, a bit more relaxed answer ...
>>>>>>>
>>>>>>> > cp $(kpsewhich -var-value TEXMFSYSVAR)/fonts/conf/texliv
>>>>>>> e-fontconfig.conf
>>>>>>> > /etc/fonts/conf.d/09-texlive.conf
>>>>>>> > fc-cache -fsv
>>>>>>>
>>>>>>> I know that this is in the manual, but I *STRONGLY* advice against
>>>>>>> it.
>>>>>>> There are some broken fonts, some that mess up fontconfig due to
>>>>>>> naming
>>>>>>> issues, all kind of bad things can happen. In Debian I have been
>>>>>>> pushed
>>>>>>> to do this for long time, but always rejected and recommend people
>>>>>>> adding only those fonts one by one that they are actually use.
>>>>>>>
>>>>>>> Just my 2Yen
>>>>>>>
>>>>>>> Norbert
>>>>>>>
>>>>>>> --
>>>>>>> PREINING Norbert
>>>>>>> http://www.preining.info
>>>>>>> Accelia Inc.     +    JAIST     +    TeX Live     +    Debian
>>>>>>> Developer
>>>>>>> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C
>>>>>>> DC13
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-live/attachments/20170804/2419e840/attachment.html>


More information about the tex-live mailing list