This bug is a continuation of bug 2150. The Poppler path turned out not be be feasible right now, partly due to the Fontconfig dependency. Instead, Sumatra was choosen. Sumatra has a drawback, however: It renders the print job to a bitmat: Krzysztof Kowalczyk: "The way I implement printing in sumatra pdf using poppler (or mupdf) is by rendering to a bitmap and then blasting that bitmap to a printer. Not a great way to do things (lots of memory needed for the bitmap at printing-quality resolution) but it works and is very simple to implement." This is, of course, far from optimal: Adrian Johnson: "This is worse than what poppler/cairo is currently doing in win32 with emitting each glyph as a path. In one test I did a full page of text resulted in a 1.5MB spool file. An full page bitmap is a lot larger than 1.5MB. The printing was slower than using fonts but no where near as slow as printing a full page bitmap. Due to the half toning on laser printers, printing text as a color bitmap results in a lower resolution than printing with paths and the text is not as sharp." We should try to switch to Poppler as soon as the Fontconfig dependency has been lifted, which is the first item on their TODO. Or, perhaps Sumatra will get a redesign.
Sergio has reported that he believes that SumatraPDF is unstable. When he tried printing the TAG, lots of memory was consumed. In this case, the PDFwriter printer was used. It might be that this combination is very problematic, but of course we know that SumatraPDF is not optimal. Unfortunately, there's little progress in making poppler work on Windows. The removal of the Fontconfig dep ("David Turner's cairo-ft rewrite") is no longer first on the list; it is scheduled for cairo 1.12 (2010?). See http://cairographics.org/roadmap/.
The Gnome 2.28 release notes claim that Evince has been ported to Windows. That should mean that the poppler stack is now fully functional on Windows.
See http://www.seppemagiels.com/blog/building-poppler-windows-using-mingw
Upstream bug #79936 adds support for windows printer as outåut for pdftocairo util. https://bugs.freedesktop.org/show_bug.cgi?id=79936 This was added in following release: poppler-0.28.0.tar.xz (Tue Nov 4, 2014)
I have been able to built poppler for windows platform and perfomed tests which shows that it works good. Rendering of vector graphics is a big step up when cairo is used instead of sumatrapdf. The poppler tool used is pdftocairo, where cairo have support for windows print gdi and commandline arguments for printing... The following things had to be done: - Upgrade poppler to 0.40.0 which brings Windows printing support in pdftocairo tool. - Poppler upgrade triggered a build error on i386 which needed a patch for glibc (LLONG vs. LONG_LONG i limits.h). - Rebuild of glibc trigged a few issues in our buildsystem: - patch for building gettext withou xml2 - patch for gettext deps for glibc - patch for glibc stage1 build using make >3.9 - Upgrade of cairo to 1.14.6 - patch for Xext deps - fix clientdeps where windows requires cairo for pdftocairo - Build libturbojpeg using cmake because the autoconf framework is unmaintained and cmake is used for Windows builds upstream. - Patch to libjpeg turbo for using GNUInstallDirs when building using cmake so it can be properly be crosscompiled. libjpegturbo used hard coded install prefix c:\... - Upgrade of cmake to 2.8.12 required by libjpegturbo - patch bug in cmake where REMOVE_DUPLICATE is used on empty list on OSX build. - add patch found upstream to fix link_lib problem in 2.8.12 - patch for upgrading our find_tool.patch to work with new version of cmake - fix for buildsystem _cendio_cmake macro, to pass install prefix to cmake as we do with _cendio_configure - fix cenbuild_toolchain cmake to set c++ compiler
(In reply to comment #5) > > - patch for glibc stage1 build using make >3.9 > We have bug #5575 for this issue.
(In reply to comment #5) > - Rebuild of glibc trigged a few issues in our buildsystem: > > - patch for building gettext withou xml2 > > - patch for gettext deps for glibc > > - patch for glibc stage1 build using make >3.9 Additional, a problem with PKG_CONFIG_PATH was found and fixed in buildsystem, bug #5804.
Note to tester: - Upgrade of cairo affect imagemagick and with this bug printing on Windows. imagemagick is for example used when generating icons for the ThinLinc client see; /home/tlbuilder/ctc/client/tlclient/icons/Makefile. - Upgrade of poppler affects only the printing parts of ThinLinc on all platforms. - libjpegturbo build using cmake Windows platform affects fltk and is tested using ThinLinc client.
I've found three regressions so far: - poppler cannot handle encrypted PDFs (probably not important) - poppler follows the page size of the PDF. This could be a feature, but it is different from how Sumatra does things. - poppler rasterises some things that Sumatra is able to pass on in vector form. This is made much worse by the fact that poppler rasterises at a very low resolution by default (150 ppi) There is also buggy behaviour in the print dialog. There are some options at the bottom to control page size and placement. These freak out when changing the printer, and they also do not seem to have any effect. Perhaps just remove them?
The Linux client has also been tested and behaves the same before and after the upgrade.
(In reply to comment #24) > - poppler follows the page size of the PDF. This could be a feature, but it is > different from how Sumatra does things. > Commit 31332 disables the use of document size when printing using pdftocairo on windows platform.
(In reply to comment #24) > > There is also buggy behaviour in the print dialog. There are some options at > the bottom to control page size and placement. These freak out when changing > the printer, and they also do not seem to have any effect. Perhaps just remove > them? Commit 31334 removes the buggy printdlg hook.
(In reply to comment #24) > > - poppler rasterises some things that Sumatra is able to pass on in vector > form. This is made much worse by the fact that poppler rasterises at a very low > resolution by default (150 ppi) > DPI increased in commit r31335 to 300
Retested and things seem to work fine. - Paper size now follows the one configured for the printer. It is possible to properly change to something else using the printer dialog. - Resolution is good enough. It is difficult to tell what is rasterised and what is vector graphics. - The print dialog is now free from buggy extra controls. I also compared print job sizes. Some went up and some went down. Difficult to say what the average will be. The cause is most likely bug 5824. There is another regression though. poppler uses the old PrintDlg() rather than the modern PrintDlgEx() (which Sumatra uses). This gives us a printer dialog that looks somewhat dated.
We'll keep the older dialog for now.
Created attachment 704 [details] lemon jelly regressions We're seeing regressions printing the "lemon jelly" test PDF when printing it via Evince ? thinlocal ? pdftocairo. The test file is attached to bug 5824. The attached document is a scan of several printouts with several different printing chains, noted on each page. Server: RHEL 7, ThinLinc 4.6.0-5123 Client: Windows 10, ThinLinc 4.6.0-5132
Created attachment 706 [details] Zip archive with example pdf files used for testing
Created attachment 707 [details] Test report
(In reply to comment #34) > Created an attachment (id=704) [details] > lemon jelly regressions > > We're seeing regressions printing the "lemon jelly" test PDF when printing it > via Evince → thinlocal → pdftocairo. The test file is attached to bug 5824. > > The attached document is a scan of several printouts with several different > printing chains, noted on each page. > > Server: RHEL 7, ThinLinc 4.6.0-5123 > Client: Windows 10, ThinLinc 4.6.0-5132 The report was presented in todays dev meeting and discussed. Decision was to keep pdftocairo and create bugs for the identified issues. Closing this bug now when report and test files are attached.
