...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
No need to export if it's no different from the default.
Also reorder defaults alphabetically, in same order as
exported by original document producers (though not all
of them are always added in MSO, which is not addressed
in this change).
Change-Id: I8526da5adc068f02e6da072961c82f4e75e3b984
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193224
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
It is only impossible during normal package parsing because of the added
consistency checks, but the inconsistency can happen during recovery.
Kind of arbitrary which size is used then?
Change-Id: I31ce9ae8b6fe3d1ca50a118ae6c1feaaaffe17ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191455
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
This would be reported on reading as an 8-byte gap at the position where
a 32-bit DD for the entry would end.
The problem is that if flag bit 3 is set, and the uncompressed size
exceeds 2^32, writeDataDescriptor() will write 8-byte sizes, but the
Zip64 extension header is missing - the latter should also write 0 even
though the APPNOTE doens't appear to require it.
4.3.9.2 [...] When extracting, if
the zip64 extended information extra field is present for
the file the compressed and uncompressed sizes will be 8
byte values.
Also make sure that the ZipEntry nSize member actually contains the
uncompressed size, which is somewhat tricky, but is required in
writeLOC() to check if Zip64 is needed. (Assume that the DEFLATEd size
is never larger than uncompressed, which is true for every XML file).
Change-Id: I611e6ffda12d8e6953e9306dc4a4407be8e725a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191185
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Whatever that was intended to mean: if that meant that the constants
were encoded that way, these are UTF-16 already; is that meant that
they only contained characters in that range, that is unimportant.
Change-Id: I5463f1fca0d552a93d3c9d487ed9912c9e1a989e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191240
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
It makes no sense to insist on a random type, only to reinterpret_cast
it everywhere. An opaque void fits the case perfectly.
Change-Id: If945b1c59d98c5f561350db649f29fe8036e7cdb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186982
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Commit a6ad198d09 made the size read
from the grabber wrong for the last chunk: it wasn't decreased to
the remaining size, but was still equal to nBlockSize. The grabber
could read past the chunk, and the CRC was wrong. No idea why did
that only hit this file - it seemed that any file larger than 32K
and that was stored (i.e., any image) would trigger that path?
Change-Id: I980dd701e54c4ed565173b5b90ed301bf9b5f719
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186241
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Integrate build system support for the Zstandard (zstd) library and
implement the corresponding C++ decompression stream classes, enabling
future use of zstd-compressed streams in ZIP packages.
Build System (Part 2a):
- Add `--with-system-zstd=[yes|no|auto]` configure option.
- Implement system library checks (`zstd.h`, `libzstd`) in configure.ac.
- Define rules (`external/zstd/*`) for downloading and building the
internal zstd static library (decompression components only).
- Set up necessary CFLAGS/LIBS via configure.ac and config_host.mk.in.
- Configure linking via RepositoryExternal.mk (`gb_LinkTarget__use_zstd`).
- Update auxiliary files (download.lst, distro-configs, etc.).
C++ Implementation (Part 2b):
- Implement `InflateZstd` (in `include/package`) and `InflaterBytesZstd`
(in `package/inc`) inheriting from `Inflater`/`InflaterBytes`.
- Use the zstd streaming API (`ZSTD_decompressStream`) following the
existing single-call pattern established by the zlib implementation.
- Manage context (`ZSTD_DCtx`) and input buffer (`ZSTD_inBuffer`) state.
- Handle errors, stream completion (`ret == 0`), and input truncation.
- Add new classes to `package/Library_package2.mk` build.
This completes the infrastructure for zstd decompression support.
The next step (Part 2c) involves adding logic to select the
appropriate Inflater based on the ZIP entry's compression method ID.
Change-Id: Ia673f3f19b6a751ba5225394fcf8c3f145c4ae63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184243
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
This adds support to export the fonts that are used in an
presentation document. The fonts are converted to EOT fonts.
Adds an EOT converter, which converts a TTF font to EOT font by
writing a EOT header and adding the TTF font data.
Adds BigEndianTypes so we can read a structure that is defined in
big endian and the types get converted (if needed) to system
endian when accessed. + test
Adds TTF reader which reads the true type font structure in an
easy way that is used by the EOTConverter. + test
Change-Id: I8b0bcb69e47943c2a8679edf881d7c2bab45c450
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184288
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Refactor ZIP decompression classes (Inflater, InflaterBytes) to support multiple decompression algorithms, enabling future Zstandard
support.
Make Inflater and InflaterBytes abstract base classes defining a common interface. Move the original zlib/Deflate logic into new derived classes InflateZlib and InflaterBytesZlib.
Update usage sites to instantiate the *Zlib variants via unique_ptr to the base class, preserving existing functionality. Move header files to standard locations (include/package, package/inc) and update includes and build files.
This pure refactoring prepares the codebase for adding Zstandard (zstd) decompression. Correct a minor logical bug in the ZipFile::getSizeAndCRC loop condition.
Change-Id: I9be3c02946e29eb2dae09f500eb47d8a4261af22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183504
Reviewed-by: Devansh Varshney <varshney.devansh614@gmail.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
The PK78 signature is optional, and if the sizes in the local file
header are 0 then without the DD the recovery won't do anything useful.
If the latest local file header has the DD bit set in flags, then try to
find the DD before the next thing that has a PK?? signature.
Change-Id: I149a87805f7bcb6216fc909c20ece600ce77956d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183722
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
found by a little plugin I created.
Plugin parked into store/ folder because it needs hand-holding
when run.
Change-Id: I2b4da7378f0becbc5f020ac9e78cd765aa0119b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181768
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
V668 There is no sense in testing the 'm_pRelStorElement->m_xStorage' pointer against null, as the memory was allocated using the 'new' operator. The exception will be generated in the case of memory allocation error.
Change-Id: Ie195de78b48c3766ef08a2d3666f778f75d2ca6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176596
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
... compressed size = 0.
The problem is that vector::data() on a vector of size 0 returns
nullptr, and osl_readFile into a nullptr buffer returns E_INVAL, which
causes an exception to be thrown.
Catch the exception, so that there is a chance to read the values from
the data descriptor instead.
(regression from commit 32cad89592
and/or commit a6ad198d09)
Change-Id: I9b2d9a930997146faf224d8033955b142fe93f58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176289
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
https://rzymek.github.io/post/excel-zip64/ claims that it's sufficient
for the version number to be 45 (4.5 - File uses ZIP64 format
extensions) for Excel to read a zip entry's data descriptor as
Zip64, while the Zip APPNOTE seems to require a zip64 extended
information extra field to be present (see 4.3.9.2).
Let's try to use the "version needed to extract" to be able to read
zip files produced by Apache POI Zip64Mode.Always.
Change-Id: I20f10471e3a85eb42d21c0cb08e36e345ef8fc9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176211
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Stephan Bergmann