View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001114 | libextractor | plugins | public | 2006-06-06 07:56 | 2010-01-13 21:44 |
| Reporter | szopa | Assigned To | Christian Grothoff | ||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.5.14 | ||||
| Summary | 0001114: PDF metadata extraction is broken | ||||
| Description | The new version doesn't support PDF metadata as it should. The former version would extract nicely the author, subject, keywords, and so on. No it can do only this: bies@quine:~/Opole$ extract Dziobak.pdf software - This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4 creation date - 20060528155926+02'00' format - PDF 1,0 mimetype - application/pdf At first I thought this was a feature;), but I checked also with the BibTeX option: bies@quine:~/Opole$ extract -b Dziobak.pdf % BiBTeX file @misc{ thisdziob, title = "Dziobak.pdf", year = "This", month = " i" } That means that the program now fails to recognize any data apart from the creation date and format... The file itself isn't broken, because when I use pdftk everything seem to work fine: bies@quine:~/Opole$ pdftk Dziobak.pdf dump_data InfoKey: Creator InfoValue: LaTeX with hyperref package InfoKey: Title InfoValue: Meaning, Hintikka's thesis, and computational complexity InfoKey: Producer InfoValue: pdfeTeX-1.21a InfoKey: Author InfoValue: Ryszard Szopa InfoKey: Keywords InfoValue: theory of meaning, P vs. NP, Hintikka's thesis, Edmonds' thesis InfoKey: PTEX.Fullbanner InfoValue: This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4 InfoKey: Subject InfoValue: I discuss some natural language constructions that turn to be very difficult from the computational point of view and consider what this means for the theory of meaning. InfoKey: CreationDate InfoValue: D:20060528155926+02'00' PdfID0: b159ce5e5e9d4ea86e562db5ccbefca0 PdfID1: b159ce5e5e9d4ea86e562db5ccbefca0 NumberOfPages: 8 I suspect that the extract has a rigid idea of what data should be in what place, and when finds something is different, it brokes. For example, is seems to find PTEX.Fullbanner in the place it expects year and month... | ||||
| Additional Information | I am using an Ubuntu packet. I have filed this bug in Launchpad: https://launchpad.net/distros/ubuntu/+source/libextractor/+bug/47651 | ||||
| Tags | No tags attached. | ||||
|
|
LE now contains two pdf extractors. The old one, based on xpdf source, and a new one with less features (as you have experienced). Which one you get depends on the options passed to configure by whoever builds the binary package. I am perfectly aware that the new pdf extractor is far from complete, but it will take quite a bit more time to get it handle all of the PDF variations that xpdf supports. |
|
|
uh-huh. So to make it work for me means to convince the Debian/Ubuntu package maintainer to configure libextract to change the options to configure ;). Thanks! |
|
|
RMS mentioned today that GNU was working on a PDF parser. So maybe we'll be able to retire both xpdf and our internal hack with a good piece of software soon. |
|
|
I've changed SVN head to use libpopper (so we're back to full xpdf-style support). This has the advantage that first of all we get security fixes directly (without needing to change LE) and secondly with the new 0.6.x API we don't have to worry so much about crashes. While the xpdf code base is likely still a bit of a mess from a security point of view, I think if we really end up worrying about it, some chroot'ing and capability dropping for the plugins would be the better solution for further reduction of the exposure to bad code. Certainly, this is better than shipping (possibly broken) xpdf code with LE and also better than not having any real PDF support (or having to write a *secure* PDF parser ourselves). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-06-06 07:56 | szopa | New Issue | |
| 2006-06-06 10:49 | Christian Grothoff | Note Added: 0002708 | |
| 2006-06-06 10:50 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2006-06-06 10:50 | Christian Grothoff | Priority | normal => low |
| 2006-06-06 10:50 | Christian Grothoff | Severity | major => minor |
| 2006-06-06 10:50 | Christian Grothoff | Reproducibility | always => N/A |
| 2006-06-06 10:50 | Christian Grothoff | Status | new => assigned |
| 2006-06-06 10:57 | szopa | Note Added: 0002709 | |
| 2007-06-28 23:50 | Christian Grothoff | Category | extract => plugins |
| 2007-06-28 23:51 | Christian Grothoff | Note Added: 0003066 | |
| 2007-07-04 20:29 | Christian Grothoff | Severity | minor => feature |
| 2009-12-15 21:49 | Christian Grothoff | Note Added: 0003953 | |
| 2009-12-15 21:49 | Christian Grothoff | Status | assigned => resolved |
| 2009-12-15 21:49 | Christian Grothoff | Resolution | open => fixed |
| 2010-01-13 21:44 | Christian Grothoff | Status | resolved => closed |
