[
https://issues.apache.org/jira/browse/TIKA-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109772#comment-18109772
]
ASF GitHub Bot commented on TIKA-4831:
--------------------------------------
dschmidt commented on code in PR #3100:
URL: https://github.com/apache/tika/pull/3100#discussion_r3892319497
##########
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-miscoffice-module/src/main/java/org/apache/tika/parser/geogebra/GeoGebraParser.java:
##########
@@ -301,21 +305,24 @@ private static String stripLeadingZeros(String digits) {
* is set, the document metadata. A part that cannot be read or is not
* well-formed is recorded in the metadata and skipped.
*/
- private void parseGeoGebraXml(ZipFile zipFile, ZipArchiveEntry entry,
- XHTMLContentHandler xhtml, Metadata metadata,
- boolean documentMetadata, ParseContext
context)
+ /**
+ * @return the icon files of the macros in the XML, in document order
+ */
Review Comment:
Merged into one.
> 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)
