GNOME Bugzilla – Bug 792943
A single character is drawn incorrectly
Last modified: 2018-03-28 17:58:28 UTC
Created attachment 367493 [details] Screenshot of incorrectly drawn 'N' in title The character 'N' in the word "Non-test" of slide #52's title (screenshot attached) is drawn incorrectly. Note that no other character in the title is drawn incorrectly. I cannot get mupdf or xpdf to display this slide incorrectly, but I can get epdfview (@ 123%) and acroread (@ 150%) to display the same character incorrectly in the same way. Not all magnifications cause the 'N' to be drawn incorrectly in evince. Only 125% seems to cause problems. Selecting the 'N' causes it to be drawn correctly. I am using the following packages on a recently updated Arch system: poppler 0.61.1-1 evince 3.26.0+14+g2a499547-1 xpdf 4.00-2 epdfview 0.1.8-8 mupdf 1.12.0-1 acroread 9.5.5-7 Here is my system info: System: Host: vivaldi Kernel: 4.14.14-1-hardened x86_64 bits: 64 gcc: 7.2.1 Desktop: Xfce 4.12.4 (Gtk 2.24.31) Distro: Arch Linux Machine: Device: laptop Mobo: INTEL model: CRESCENTBAY serial: N/A UEFI: American Megatrends v: 5.6.5 date: 08/29/2015 CPU: Dual core Intel Core i7-5650U (-MT-MCP-) arch: Broadwell rev.4 cache: 4096 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 8783 clock speeds: max: 3200 MHz 1: 2601 MHz 2: 2441 MHz 3: 2595 MHz 4: 2552 MHz Memory: Using dmidecode: root required for dmidecode Graphics: Card: Intel HD Graphics 6000 bus-ID: 00:02.0 Display Server: X.Org 1.19.6 driver: modesetting Resolution: 1920x1080@60.00hz OpenGL: renderer: Mesa DRI Intel HD Graphics 6000 (Broadwell GT3) version: 4.5 Mesa 17.3.3 Direct Render: Yes Audio: Card-1 Intel Wildcat Point-LP High Definition Audio Controller driver: snd_hda_intel bus-ID: 00:1b.0 Card-2 Intel Broadwell-U Audio Controller driver: snd_hda_intel bus-ID: 00:03.0 Sound: Advanced Linux Sound Architecture v: k4.14.14-1-hardened Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169 v: 2.3LK-NAPI port: e000 bus-ID: 02:00.0 IF: enp2s0 state: up speed: 100 Mbps duplex: full mac: <filter> Card-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169 v: 2.3LK-NAPI port: d000 bus-ID: 03:00.0 IF: enp3s0 state: down mac: <filter> Card-3: Broadcom Limited BCM43224 802.11a/b/g/n driver: bcma-pci-bridge bus-ID: 04:00.0 IF: wlp4s0b1 state: down mac: <filter> Drives: HDD Total Size: 6501.2GB (40.0% used) ID-1: /dev/sda model: Samsung_SSD_850 size: 500.1GB temp: 0C ID-2: USB /dev/sdb model: My_Passport_2599 size: 4000.8GB temp: 0C ID-3: USB /dev/sdc model: My_Passport_0741 size: 2000.4GB temp: 0C ID-4: USB /dev/sde model: Edge25_Flash size: 0.0GB temp: 0C Partition: ID-1: / size: 48G used: 44G (97%) fs: ext4 dev: /dev/sda2 ID-2: /var size: 16G used: 11G (72%) fs: ext4 dev: /dev/sda4 ID-3: /boot size: 511M used: 84M (17%) fs: vfat dev: /dev/sda1 RAID: Device-1: /dev/no components: N/A Info: raid: zfs-no-raid size: pools available: N/A allocated: available Sensors: System Temperatures: cpu: 29.8C mobo: 27.8C Fan Speeds (in rpm): cpu: N/A Info: Processes: 279 Uptime: 6 days Memory: 7710.5/15478.7MB Init: systemd Gcc sys: 7.2.1 Client: Shell (fish) inxi: 2.3.56
The PDF Previewer in Firefox ESR 52.6.0 displays a horizontal white line at 125% exactly where the 'N' is broken, but does not display it incorrectly until 140%. Chromium also displays it incorrectly, but I can't tell at what magnification.
Please attach the PDF and I'll look at it. Though if acroread displays it incorrectly, it's likely a problem with the PDF, not evince/poppler.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!
Created attachment 370209 [details] A PDF of a PPTX file According to this file's metadata, the PDF was created by Acrobat Distiller 7.0.5 (Windows) from a Microsoft PowerPoint (PPTX) presentation.
While manipulating the PDF file with various PDF programs on Linux (evince, pdftk, pdfopen, pdfinfo, etc.), I get this error message on my console (GNOME Terminal): DEBUG: FC_WEIGHT didn't match But ... I now agree, there must be something wrong with the file because I was incorrect: I can get both 'mupdf' and 'epdfview' to display an erroneous 'N' at a some large magnification > 250%. I don't know if this is worth chasing down, but if you have a PDF verifier, you might try verifying the file. I've marked this bug NOTGNOME because that seems like the most reasonable option; feel free to change.
Vladimir, you should still file the bug with the sample pdf to poppler's bugzilla... MAybe there is something we can do in poppler to read the file even if it's malformed (The pdf format is so complex that many PDF files out there are malformed...)
That document is drawing the "Test Data, Non-text" text twice. It crops to the top half of that line and draws the text, then again for the bottom half of the line, using slightly different parameters for character and word spacing. I haven't worked out the math to determine whether the characters of both lines should be placed in the *exact* same position, but even if it does work out, it would be easy for rounding errors to affect it.
@José I'll file with poppler. @Jason Thanks for the detective work. I'm going to PM you.
(In reply to José Aliste from comment #6) > (The pdf format is so complex that many PDF files out there are malformed...) You mean that some people aren't familiar with all 1310 pages of the PDF 1.7 reference (that's just the base reference; errata and addendums add more)??? Harrumph… I find it hard to believe that there aren't outright contradictions somewhere in those 1310 pages.
(In reply to Vladimir Ivanovic from comment #9) > (In reply to José Aliste from comment #6) > > (The pdf format is so complex that many PDF files out there are malformed...) > > You mean that some people aren't familiar with all 1310 pages of the PDF 1.7 > reference (that's just the base reference; errata and addendums add more)??? > Harrumph… > > I find it hard to believe that there aren't outright contradictions > somewhere in those 1310 pages. Sure, read it like this, it's the same... PDF standard is so complex that it has inconsistencies and too many small things not documented... but they just work on Adobe or maybe another rendered... so Sometimes we can fix it in poppler by mimmicking what (we think) adobe does.