https://bugs.documentfoundation.org/show_bug.cgi?id=170147
--- Comment #8 from V Stuart Foote <[email protected]> --- (In reply to Jose L Viejo from comment #7) > I find the 'Not a Bug' assessment arbitrary. Relying on KPDF’s failure to > justify LibreOffice's behavior is flawed logic; it simply suggests that KPDF > shares the same limitation or rendering bug as Draw. > > Blaming Bullzip or labeling the file content as 'junk' overlooks the > critical fact that Adobe Acrobat Reader—the reference implementation of the > PDF standard—renders and prints the file perfectly. > > We should not use third-party interpreters (like KPDF, PDF24, etc.) as the > benchmark for correctness. If they all fail, it is not an excuse for > LibreOffice to fail as well. The fact remains: the file works flawlessly in > Acrobat, meaning the visual data is valid. LibreOffice is failing to > interpret what the standard viewer handles correctly. Therefore, this is a > compatibility bug No. You are missing the point. LibreOffice reads the obfuscated PDF just fine using a pdfium based filter--as you indicated. LibreOffice is not failing, it is doing exactly what it is able to do. And, the PDF is internally corrupt from the poppler parsing lib projects perspective. So these, or any other PDF for which poppler can not read text spans, deliver object streams that *are* parsed with poppler lib calls, but they include obfuscated character mappings used for the print job that do not include the Unicode glyph tables poppler needs to bring characters back to their Unicode point values. Which are *necessary* to then assemble into cairo drawing objects to place onto LibreOffice drawing canvas or writer page. What is passed is garbage because it is not structured in a fashion usable by poppler lib extraction. Just reality. Absent that minimal structure--there is nothing an import filter parsing text runs from the PDF can do, it is just reading what's there. Any poppler based application will suffer the same way. Results contrasted with the pdfium based filter, which makes *no* attempt at all to parse text runs--it simply places what it receives as a discrete object. It reads exactly what the PDF page layout states for each object with each character and graphic element laid out as parsed. All assembled and then rendered to a raster image (with some user control). => NOT OUR BUG (i.e. not our responsibility to correct Bullzip PDF, or the poppler project) -- You are receiving this mail because: You are the assignee for the bug.
