Bug 388741 - pdflatex-generated doc renders blank if "fontenc" package is used
Summary: pdflatex-generated doc renders blank if "fontenc" package is used
Status: RESOLVED DOWNSTREAM
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 0.26.1
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-09 16:24 UTC by kdebugs.grokchem
Modified: 2018-01-10 11:27 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
PDF sample (1.64 KB, application/pdf)
2018-01-09 16:24 UTC, kdebugs.grokchem
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kdebugs.grokchem 2018-01-09 16:24:15 UTC
Created attachment 109768 [details]
PDF sample

If pdflatex is used to compile the following code, it produces a PDF that renders fine in evince, but not in okular or xpdf.  The SLOC "\usepackage[T1]{fontenc}" seems to be the critical component to reproducing this.  When the /print preview/ feature is used, then it renders the word "foo", as it should.  The PDF is attached, and the code is below:

\documentclass[12pt]{minimal}
\usepackage[T1]{fontenc}
\begin{document}
foo
\end{document}

I would like to have formatted the above text, but I don't know how, and the  "bug writing guidelines" link is broken:

The requested URL /bugzilla-tip/page.cgi was not found on this server.

I'm not sure if this is related, but I recently updated the search path for *.sty files on my system by taking these steps:

  $ mkdir -p ~/lib/texlive/tex
  $ sudo tlmgr conf --conffile /etc/texmf/texmf.d/00debian.cnf texmf TEXMFHOME "~/lib/texlive"
  $ mv foo.sty ~/lib/texlive/tex/
  $ sudo update-texmf
  $ sudo texhash
  $ kpsewhich foo.sty; #checks whether it's found
  $ kpsewhich -var-value TEXMF | grep TEXMFHOME; #shows the whole search path
Comment 1 Oliver Sander 2018-01-09 16:30:50 UTC
One of the effects of \usepackage[T1]{fontenc} is switching to a Type3 font, and those are known to be difficult.  That being said, my okular renders these fonts (and the example file in particular) just fine.  Your summary says that you are using okular 0.26.1. Can you try a newer one?  And what is your poppler version?
Comment 2 kdebugs.grokchem 2018-01-09 16:38:46 UTC
@Oliver

poppler-utils and the libs for it are version 0.48.0-2+deb9u1.  I'll see if I can get a backports version or something, and try it.

I should also mention that the bug manifests similarly to this bug:

  https://bugs.kde.org/show_bug.cgi?id=344645

If the beamer class depends on the fontenc package, it could be the same bug.
Comment 3 Michael Weghorn 2018-01-10 10:16:10 UTC
This seems to be a bug introduced by the latest Debian security update for Poppler. I just verified with the attached file on a Debian stable installation that the problem does not occur with version '0.48.0-2' of the poppler packages, but only with the lates security update, version '0.48.0-2+deb9u1'.

There is the following Debian bug report which seems to desribe the same problem:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23886733
Comment 4 kdebugs.grokchem 2018-01-10 10:49:08 UTC
@Michael

Indeed I just noticed that. Poppler was silently updated on Jan. 8.  It didn't just break LaTeX-generated PDFs, I also have no text on PDFs of web browser PDF prints.

How annoying that a silent update would have that nasty effect. Something seems to be questionable about the Debian quality control practices.  Auto updates are supposed to be isolated to security critical fixes, and I'm tempted to disable them.
Comment 5 Michael Weghorn 2018-01-10 10:53:17 UTC
(In reply to kdebugs.grokchem from comment #4)
> How annoying that a silent update would have that nasty effect. Something
> seems to be questionable about the Debian quality control practices.  Auto
> updates are supposed to be isolated to security critical fixes, and I'm
> tempted to disable them.

In fact, this IS a security critical fix by Debian, but unfortunately those can sometimes break things, too...
Comment 6 kdebugs.grokchem 2018-01-10 11:23:48 UTC
For the record, this is what was fixed in the poppler update that broke rendering. The update was apparently justified imo.

  * Fix CVE-2017-9406: a memory leak vulnerability was found in the function
    gmalloc in gmem.cc, which allows attackers to cause a denial of service
    via a crafted file.
  * Fix CVE-2017-9408: memory leak in the function Object::initArray in
    Object.cc that allows attackers to cause a DoS via a crafted file.
  * Fix CVE-2017-9775: Stack buffer overflow in GfxState.cc in pdftocairo that
    allows remote attackers to cause a denial of service (application crash)
    via a crafted PDF document.
  * Fix CVE-2017-9776: Integer overflow leading to Heap buffer overflow in
    JBIG2Stream.cc in pdftocairo allows remote attackers to cause a denial of
    service (application crash) or possibly have unspecified other impact via a
    crafted PDF document.
  * Fix CVE-2017-9865: The function GfxImageColorMap::getGray in GfxState.cc
    allows remote attackers to cause a denial of service (stack-based buffer
    over-read and application crash) via a crafted PDF document
  * Fix CVE-2017-14517: NULL pointer dereference vulnerability in the
    XRef::parseEntry() function in XRef.cc
  * Fix CVE-2017-14518: Floating point exception in the
    isImageInterpolationRequired() function in Splash.cc
  * Fix CVE-2017-14519: A memory corruption may occur in a call to
    Object::streamGetChar
  * Fix CVE-2017-14520: Floating point exception in Splash::scaleImageYuXd()
  * Fix CVE-2017-14617: Floating point exception in the ImageStream class in
    Stream.cc
  * Fix CVE-2017-14975: NULL pointer dereference vulnerability in the
    FoFiType1C::convertToType0 function in FoFiType1C.cc
  * Fix CVE-2017-14976: Heap-based buffer over-read vulnerability in the
    FoFiType1C::convertToType0 function in FoFiType1C.cc
  * Fix CVE-2017-14977: NULL pointer dereference vulnerability in the
    FoFiTrueType::getCFFBlock function in FoFiTrueType.cc
  * Fix CVE-2017-15565: NULL Pointer Dereference in the
    GfxImageColorMap::getGrayLine() function in GfxState.cc
Comment 7 Albert Astals Cid 2018-01-10 11:27:37 UTC
No, the debian people broke poppler.

They applied upstream poppler patches but upstream poppler works with this file while their package does not.

So they are to blame for breaking things. Complain to the debian poppler maintainer. There's nothing we can do to fix this.