C++ library to visualize files, especially documents, in HTML.
- odt, odp, ods, odg (OpenOffice / LibreOffice), including the flat xml form (fodt / fodp / fods / fodg)
- docx, pptx, xlsx (Microsoft Office Open XML)
- csv
- doc, ppt, xls
- pages (Apple Pages — body text and the tables it anchors; styles, page geometry and images are not read yet)
- key (Apple Keynote — the text of each slide, in boxes where the file puts them; styles, masters, images, tables and presenter notes are not read yet)
- numbers (Apple Numbers — one sheet per table, showing the values the app last computed; number formats, merged cells, charts and formulas are not read yet)
- rtf (body text only; character and paragraph formatting, tables and pictures are not read yet)
- txt
- json
- md (Markdown — CommonMark plus the GitHub extensions; raw html, images and
horizontal rules are not read yet. Never detected from its bytes, so open it
as
FileType::markdownexplicitly) - zip
- cfb (Microsoft Compound File Binary File Format)
- ttf / otf (font specimen pages)
Every accepted file extension and MIME type — including the template and
macro-enabled aliases (docm, dotx, xltx, ppsx, …) — is enumerable at
runtime via file_extensions_by_file_type / mimetypes_by_file_type, so a
consumer never has to maintain its own copy of these tables.
These are classified by extension and MIME type, and wpd is also recognised
from its bytes, so a caller can report them — but there is no decoder, and
opening one throws:
- wpd (WordPerfect)
- xlsb (Excel binary workbook — an OOXML package whose workbook parts are binary rather than spreadsheetml)
- html / htm / xhtml (route to a web view; not detected from its bytes)
capabilities_by_file_type(FileType) answers, per format, whether the library
can detect, open, decrypt, render, edit, save or encrypt it — the decisions a
caller has to make before it holds a file, e.g. which MIME types to advertise
to a system file picker. It is a declared upper bound; DecodedFile::capabilities()
and Document::is_editable / is_savable give the precise answer for a
concrete file.
Editing and saving are currently limited to odt, odp, odg (edit + save),
ods (save only) and docx (edit + save); saving with a password is not
supported for any format.
- xml
- yaml
Currently, used as backend for OpenDocument.droid and OpenDocument.ios.
Bindings: Python (pyodr), Java/JNI and
Android (app.opendocument:odr-core-android),
Apple (OdrCore, a Swift package), and
WebAssembly (@opendocument/odr-core, for rendering in the
browser with no server).
Replaces legacy projects OpenDocument.java, JOpenDocument and svm.
Potential test files: https://file-examples.com/
tools/pdf— generators for the PDF engine's committed encoding data.
This project comes with CMake as a build system and Conan as package manager. In principle they should be independent and one can build without Conan.
Using Conan one can use our Artifactory as a Conan remote for convenience: https://artifactory.opendocument.app/
As an alternative to the Conan remote you can also export the package locally via Conan i.e. conan export . --name odrcore --version VERSION (fill VERSION with something appropriate).
What changed per version is in CHANGELOG.md, and in full in the
releases.
Every font the output embeds has to survive OTS,
the sanitizer browsers put in front of @font-face — one it rejects is dropped
whole and the text renders as tofu. After a test run:
pip install opentype-sanitizer
python test/scripts/check_fonts.py build/test/outputScripts and Docker images can be found here https://github.com/opendocument-app/compare-html
./test/scripts/compare_output_server.shOpenDocument.core is licensed under the Mozilla Public License 2.0
(MPL-2.0).
The committed PDF font/encoding tables in src/odr/internal/pdf/ are
generated from third-party source data whose provenance and terms are documented
in tools/pdf/THIRD_PARTY_LICENSES.md.