[
https://issues.apache.org/jira/browse/TIKA-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106741#comment-18106741
]
ASF GitHub Bot commented on TIKA-4831:
--------------------------------------
dschmidt opened a new pull request, #3044:
URL: https://github.com/apache/tika/pull/3044
Adds detection and parsing support for the GeoGebra file formats.
Issue: https://issues.apache.org/jira/browse/TIKA-4831
## Detection
- `application/vnd.geogebra.file` (`*.ggb`) and
`application/vnd.geogebra.tool` (`*.ggt`) are now `sub-class-of
application/zip`, so the filename hint survives magic detection instead of
being discarded in favor of plain `application/zip`
- new mime types: `application/vnd.geogebra.slides` (`*.ggs`, zip-based) and
`application/vnd.geogebra.pinboard` (`*.ggp`, JSON-based)
- a new `GeoGebraDetector` (zip container detector, ZipFile and streaming
mode) recognizes the formats without a filename by their well-known entries:
`geogebra.xml` (worksheet), `structure.json` + `_slideN/geogebra.xml`
(Notes/Slides), `geogebra_macro.xml` (tool). Since a worksheet with macros
contains both `geogebra.xml` and `geogebra_macro.xml`, the decision is made
after all entry names have been seen
- `ZipParser.ZIP_SPECIALIZATIONS` is kept in sync with the new registry
entries
## Parser
A new `GeoGebraParser` (miscoffice module) for `ggb`/`ggs`/`ggt`:
- metadata: construction title/author/date become
`dc:title`/`dc:creator`/`geogebra:date`, plus `geogebra:appName`,
`geogebra:appVersion`, `geogebra:formatVersion`, `geogebra:id`; Notes/Slides
set `xmpTPg:NPages`
- content: user-visible text as XHTML paragraphs - string-literal expression
elements of text objects, rich-text content runs (JSON), element captions,
macro names and help texts; Notes/Slides emit one div per slide in
`structure.json` order
- the representative rendering (`geogebra_thumbnail.png` at the root, or the
first slide's thumbnail) is emitted as an embedded document marked
`embeddedResourceType=THUMBNAIL`, following the existing convention in the
OOXML, ODF and iWork parsers, so `/unpack/all` sidecars identify the preview
image; other slides' thumbnails are redundant renderings and are skipped
- any other embedded file (e.g. inserted pictures) is emitted as an embedded
document
XML is parsed through `XMLReaderUtils.parseSAX` like the other parsers in
the module; `structure.json` and rich-text runs use Jackson (new
`jackson-databind` dependency in the miscoffice module, version managed by the
existing BOM import).
## Testing
- new unit tests: `GeoGebraDetectionTest` (zip-commons) and
`GeoGebraParserTest` (miscoffice) with crafted `ggb`/`ggs`/`ggt` fixtures; the
ggs fixture deliberately orders `_slide1` before `_slide0` in `structure.json`
to pin the ordering behavior
- full test suites of `tika-core`, `tika-parser-zip-commons`,
`tika-parser-miscoffice-module` and `tika-parser-pkg-module` pass, plus
`CompositeZipContainerDetectorTest` in the integration tests
- verified end-to-end against a real-world GeoGebra Notes file: detected as
`vnd.geogebra.slides`, text extracted, thumbnail emitted with the `THUMBNAIL`
marker
> Add content-based detection and a parser for GeoGebra files (ggb, ggs, ggt)
> ---------------------------------------------------------------------------
>
> Key: TIKA-4831
> URL: https://issues.apache.org/jira/browse/TIKA-4831
> Project: Tika
> Issue Type: New Feature
> Reporter: Dominik Schmidt
> Priority: Major
>
> GeoGebra files are currently only recognized by file extension. The mime
> registry has glob-only entries for {{application/vnd.geogebra.file}}
> ({{*.ggb}})
> and {{application/vnd.geogebra.tool}} ({{*.ggt}}), but both formats are zip
> containers and the entries are not declared as sub-classes of
> {{application/zip}}. As a result, as soon as content is available, magic
> detection returns {{application/zip}} and the filename hint is discarded in
> {{MimeTypes.applyHint()}} - even when the resource name is known. Content-only
> detection (no filename) has no way to identify the formats at all, and the
> newer GeoGebra formats {{*.ggs}} (Notes/Slides) and {{*.ggp}} (Pinboard) are
> missing from the registry entirely.
> There is also no parser for any of the GeoGebra formats: files fall through to
> the generic {{PackageParser}}, which extracts the zip entries but produces no
> document metadata and no usable text (the {{geogebra.xml}} construction is
> emitted as raw XML through the XML parser).
> Proposed improvement:
> * mime registry: declare {{application/vnd.geogebra.file}} and
> {{application/vnd.geogebra.tool}} as {{sub-class-of application/zip}}; add
> {{application/vnd.geogebra.slides}} ({{*.ggs}}, zip-based) and
> {{application/vnd.geogebra.pinboard}} ({{*.ggp}}, JSON-based)
> * a {{ZipContainerDetector}} that identifies the formats without a filename by
> their well-known entries: {{geogebra.xml}} (worksheet), {{structure.json}}
> plus {{_slideN/geogebra.xml}} (Notes/Slides), {{geogebra_macro.xml}} (tool);
> a worksheet with macros contains both {{geogebra.xml}} and
> {{geogebra_macro.xml}}, so the decision must be made after all entry names
> have been seen
> * a {{GeoGebraParser}} for ggb/ggs/ggt that extracts the construction metadata
> (title, author, date) and application name/version, emits the user-visible
> text (text objects, rich-text notes, captions, macro names/help) as XHTML,
> and emits the embedded {{geogebra_thumbnail.png}} (root, or the first
> slide's
> for Notes/Slides) as an embedded document marked
> {{embeddedResourceType=THUMBNAIL}}, following the existing convention in the
> OOXML, ODF and iWork parsers, so downstream consumers of {{/unpack/all}}
> sidecars can identify the preview image
> Use case: file sync/share servers (e.g. OpenCloud) use Tika for content
> extraction and for serving embedded preview images; with the THUMBNAIL marker
> they can select the representative preview of a GeoGebra file the same way as
> for Office documents.
> Pull request to follow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
