[jira] [Created] (TIKA-1672) Integrate tika-java7 component
Tyler Palsulich created TIKA-1672: - Summary: Integrate tika-java7 component Key: TIKA-1672 URL: https://issues.apache.org/jira/browse/TIKA-1672 Project: Tika Issue Type: Improvement Reporter: Tyler Palsulich Fix For: 1.10 Code requiring Java 7 doesn't need to be in a separate module now that TIKA-1536 (upgrade to Java 7) is done. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TIKA-1536) Upgrade compiler definition in pom's to Java 7
[ https://issues.apache.org/jira/browse/TIKA-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Palsulich resolved TIKA-1536. --- Resolution: Fixed Upgraded in r1688779. Thanks, all. Will open a new issue regarding integrating tika-java7. Upgrade compiler definition in pom's to Java 7 -- Key: TIKA-1536 URL: https://issues.apache.org/jira/browse/TIKA-1536 Project: Tika Issue Type: Improvement Components: packaging Affects Versions: 1.7 Reporter: Lewis John McGibbney Assignee: Lewis John McGibbney Fix For: 1.10 Attachments: TIKA-1536.patch Since we committed TIKA-1423 it would appear through [mailing list|http://www.mail-archive.com/dev%40tika.apache.org/msg11542.html] commentary that there is a willingness to drop support for Java 1.6 in favour of = Java 1.7. This issue simply addresses this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TIKA-1673) Don't include source file name in embedded path with RecursiveParserWrapper
[ https://issues.apache.org/jira/browse/TIKA-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Allison resolved TIKA-1673. --- Resolution: Fixed r1688828 Don't include source file name in embedded path with RecursiveParserWrapper --- Key: TIKA-1673 URL: https://issues.apache.org/jira/browse/TIKA-1673 Project: Tika Issue Type: Bug Reporter: Tim Allison Assignee: Tim Allison Priority: Trivial The RecursiveParserWrapper has been including the source file in the embedded file path (X-TIKA:embedded_resource_path), as in test_recursive.docx/embed1.zip/embed2.zip/embed3.zip/embed3.txt. If the client forgets to send in a file name or if a filename doesn't exist, then the RecursiveParserWrapper defaults to embed-1, which is wrong. Let's drop the source file name from the path so that the above will be /embed1.zip/embed2.zip/embed3.zip/embed3.txt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TIKA-1400) Extract Excel (xls, xlsx) headers and footers
[ https://issues.apache.org/jira/browse/TIKA-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Allison resolved TIKA-1400. --- Resolution: Fixed r1688834.. Thank you [~aeham.abushwashi]! Extract Excel (xls, xlsx) headers and footers - Key: TIKA-1400 URL: https://issues.apache.org/jira/browse/TIKA-1400 Project: Tika Issue Type: Bug Components: parser Affects Versions: 1.5 Reporter: sunxingzhe Assignee: Tim Allison Attachments: SpreadsheetWithHeadersAndFooters.xls, SpreadsheetWithHeadersAndFooters.xlsx, TIKA-1400.patch, headers and footers.xls When I parser xls file, the headers's and footers's content can not be parsed. The xlsx file has the same problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TIKA-1602) Detecting standards-non-compliant emails as message/rfc822
[ https://issues.apache.org/jira/browse/TIKA-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612321#comment-14612321 ] Jeremy B. Merrill commented on TIKA-1602: - Thank you, [~chrismattmann], [~talli...@mitre.org] et al.! [~talli...@mitre.org] -- got a bunch of normal headers, but also this `Status:` one. The only possible value in my dataset (a bunch of publicly-released emails from Jeb Bush's tenure as FL Gov) is `RO`, so the first lines of the emails who were treated improperly by Tika before this patch was uniformly `Status: RO`. I'm going to check the whole dataset once I manage to download it all back down again from storage to make sure there are no other values than `RO`. My understanding is that some mail servers use this header internally to keep track of read status. When emails are exported, they retain the header, and it sometimes appears first -- even though the server would never send this header over the wire. Detecting standards-non-compliant emails as message/rfc822 -- Key: TIKA-1602 URL: https://issues.apache.org/jira/browse/TIKA-1602 Project: Tika Issue Type: New Feature Components: mime Reporter: Jeremy B. Merrill Assignee: Chris A. Mattmann Priority: Minor Fix For: 1.10 Attachments: 036491.txt.zip Original Estimate: 1h Remaining Estimate: 1h Tika does not properly detect certain emails as `message/rfc822` if they're slightly standards-non-compliant and begin with `Status: ` as the first header. I've added `Status: ` as a magic detection line in tika-mimetypes.xml. This solves my problem and does not appear to cause unit test failures. I have not yet run the tika-batch tests. As further information, the emails that are processed incorrectly come from dumps directly from various US public officials' mailservers. The dumps, I believe since they're not intended to be transmitted over the wire, sometimes are slightly non-compliant. It's important to note that Tika (and the underlying library, James Mime4J) do properly *parse* these emails, despite the non-compliant header. The problem is getting Tika to *detect* the file as an email so that Mime4J gets chosen to parse it. Pull request on Github at https://github.com/apache/tika/pull/40 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
