Is MuPDF consistent with Qt4 GUI apps?

I am trying to create an app which fixes "bad" PDFs: PDFs without ToC (I mean outline tree - create ToC), PDFs with duplicate pages (delete them) or "quickly created" PDFs made by joining several other PDFs (senseless items in ToC, usually names of the PDF parts, senseless pages, etc. - delete all this). Such PDFs often contain useful information but in useless form so fix it.

I need something for manipulating a PDF (I am trying PoDoFo) and something for displaying a page because PoDoFo cannot render a page image. I already have got a bad experience with poppler-qt - very ugly images, as if they came from middle 90s. So I compiled MuPDF ver. 1.3 and tried it.

When I created a "non Qt" project in the Creator and let MuPDF render several pages of a test PDF (storing them in files), the result was splendid. When I created a Qt GUI project, the project worked until I started using MuPDF. With MuPDF, all texts vanished from the app and I got bags of error messages:

Code:

---

render glyph failed err=13 face=0x29d1eb0, glyph=51
<many similar lines>

---

The end. Does anybody know what is it all about? And why poppler-qt produces such ugly images? Many PDF apps use poppler and results aren't ugly. With poppler, I tried this:

Code:

---

Poppler::Document *document = Poppler::Document::load(filename);    // in fact, not here but in OpenPDF()
Poppler::Page     *pdfPage  = document->page(pageNumber);
QImage             image    = pdfPage->renderToImage();
 
  <display image in the page window>
 
delete pdfPage;
delete document;    // in fact, not here but in ClosePDF()

---

What am I doing wrong?

Just a guess, but have you tried higher DPI values when rendering with Poppler?

Alterantively you could check the code of Poppler using programs, e.g. KDE's Okular.

Cheers,
_

Yes, I have tried it. MuPDF renders at 96 DPI, so I have tried the default (72 DPI, ugly), 96 DPI (the image size is like the MuPDF image size - but the result was equally ugly), 144 DPI (no improvement).

All guesses ... The missing text and error message looks like muPDF does not have, or know where to find, whatever font is used in the PDF file (or can find the font but it does not contain the relevant glyph). This could happen with PDFs that do not embed non-standard fonts or if you have missed some processing step for handling embedded fonts.

The error message comes not from MuPDF but from Qt. As long as you haven't linked MuPDF libraries, the GUI is okay. Also, if you create a non-Qt project with MuPDF (update the example.c from MuPDF so that you get a C++ Qt non-Qt project), the output is okay. The error messages pop up when you link MuPDF libraries to a Qt GUI project.

The MuPDF libraries seem to interfere with Qt rendering somehow. You need not even activate MuPDF from the GUI project. It's enough to write a MuPDF-based "RenderPage()", add the libraries and compile. You need not call RenderPage() actually. You lose all texts, including menus, labels on buttons and similar texts in the app. All these texts were pure ASCII. No exotic glyphs.

As to the Poppler: Antialiasing is off completely by default. If someone reads this then the output can be improved considerably by

Code:

---

document = Poppler::Document::load("/home/radek/wk/test.pdf");
 
  document->setRenderHint(Poppler::Document::TextAntialiasing);
  document->setRenderHint(Poppler::Document::Antialiasing);
 
  ...

---

Ah, I read the problem as the text went missing from the generated PDF, not from the Qt GUI.

MuPDF has an internal version of freetype that may well be colliding with the version Qt is built with. Is it possible to build MuPDF with the system freetype?

Correct. Removing mupdf/libfreetype.a from the profile file seems to solve the problem. At least, the project compiles and runs - with the lost texts back.