Hi, Jonas Smedegaard wrote:
> I agree that this is unlikely a bug in Ghostscript. > > The test PDF provided by Jonathan Nieder _is_ searchable with Evince > 3.38.2-1. > > If same file was not searchable with Evince available in January 2011, > then the issue might be the encoding of the strings in the PDF, or it > might be something else that confused that older release of Evince. > > But that test file was produced by LibreOffice. I would expect that a > file generated by cups-pdf would instead have cups-pdf as creator in the > metadata. > > I therefore suspect that the test PDF file should be ignored for this > issue, and that the originally reported issue is a different one: [...] > For the record: If you suspect that an issue is in Ghostscript then > please provide the ghostscript command that causes this issue - without > that the only possible action is to tag it as unreproducible and close > it, which is not really helpful. This response is puzzling. The example that I produced was a simple postscript file and then a ps2pdf command that invokes ghostscript to produce this issue. I don't understand why you're insisting simultaneously that I should have - used cups-pdf instead of using ghostscript directly - used ghostscript directly instead of using a larger pipeline that invokes it since I don't see how those are possible to do at the same time. [...] > Ghostscript primarily renders a "painting" and secondarily preserves as > metadata high-level information like strings of text and color spaces. > > One way metadata is lost is if CUPS filters use Postsript as > intermediary format. That was the case in the past but the default > should nowadays use PDF as intermediary format. This analysis seems spot-on; I think you have correctly described the issue. [...] > This issue is highly likely a duplicate of 847462 - thus merging. IIUC that bug was fixed by switching to the pdftocairo renderer. Thanks much, this makes a lot of sense to me. Sincerely, Jonathan
