[
https://issues.apache.org/jira/browse/TIKA-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109672#comment-18109672
]
ASF GitHub Bot commented on TIKA-4831:
--------------------------------------
dschmidt opened a new pull request, #3100:
URL: https://github.com/apache/tika/pull/3100
Follow-up to #3044: a tool file (`.ggt`) has no `geogebra_thumbnail.png`,
but a tool can have an icon, stored in a directory with a generated name and
referenced by the macro's `iconFile` attribute (File Format reference, ".ggt").
The parser now emits that icon as the tool's THUMBNAIL, and not a second time
as a picture.
Order of preference is unchanged for the other files: the worksheet
thumbnail, then the first slide thumbnail, then the tool icon. A worksheet with
an embedded tool keeps its own thumbnail; the icon stays INLINE there.
I could not find a real `.ggt` with an icon anywhere public (GitHub does not
index binaries, GeoGebra's site offers no tools for download), so the test
builds one after the XML reference.
https://issues.apache.org/jira/browse/TIKA-4831
> 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)
