Bug forwarded from Evince: https://bugzilla.gnome.org/show_bug.cgi?id=600500 "The attached file (which is a barcode) displays perfectly fine on versions 2.26 and earlier. But upon upgrading to version 2.28, the whole barcode becomes completely black. The barcode itself is Code39 (with checksum) and the value should be "B0000001" (or something along those lines)." Document is attached to the original bug report. Accoring to git bisect this is a regression caused by Type 3 fonts using cairo user-fonts. a3edfa30680864b95a5196c5619846de42980857 is first bad commit commit a3edfa30680864b95a5196c5619846de42980857 Author: Adrian Johnson <ajohnson@redneon.com> Date: Sat Nov 1 01:57:32 2008 +1030 Implement Type 3 fonts in cairo backend using cairo user-fonts :040000 040000 324842fe37fe43d64b6ef86184ea61d016f1db37 51598836200945a97b48317a48b97569443793ad M poppler Adrian?
Created attachment 31064 [details] [review] patch The the PDF is using two glyphs from the Type 3 font to draw the barcode. One glyph draws a black rectangle, the other a white rectangle. The type 3 charproc for each glyph looks something like: 75 0 d0 6 0 69 2000 re 1.0 g f and 75 0 d0 4 0 71 2000 re 0.0 g f The problem is the "1.0 g" and "0.0 g". Cairo doesn't support colors in the user font render callback. Any mark made will be rendered as the font color. So both the white and black rectangle are rendered as black resulting in one big black blob. I'm not sure how we can support gray levels in the Type 3 glyphs. For now I attach a patch makes the barcode render correctly by disabling filling/stroking inside Type 3 glyphs when the gray level is > 0.5.
Pushed to git master, thank you very much Adrian.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.