This was only used in the simplecanvas library
that was dropped in
Change-Id: I301b3a42dfb6eacf6a9ef3a4851ed1d38f16ec66
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 30 15:31:11 2026 +0200
canvas: Drop unused simplecanvas library/component
Change-Id: I576c8e954d5ada273f49e9eba45dd71e65d49310
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208854
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
- Convert include guards to #pragma once in salhelper, starmath, tools, ucb, and o3tl.
- Kept changes minimal to a small cross-module batch as requested by the easyHack guidance.
- Verified with: container=1 make -j4 o3tl.build salhelper.build starmath.build tools.build ucb.build
Change-Id: Ic047061433985e12be41bdb6463ac4c8e8969ddd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204555
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
So it is not needed to write the number of elements in the array,
as this is done by the compiler.
This is similar to frozen::make_* functions (or better, those
functions are similar to to_array).
Change-Id: Ie589607fae0326ac8a01ebaee2e1b1cbec35bfdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189322
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
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>
This simplifies determining what the byte size of the template type
is, so we can write a specific implementation for 32 and 64 bit
seeds for hash_combine.
Change-Id: Icd68e4618151957ecc00585dd521adf11fe3931a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182266
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
We use the same funciton all over the place, so create a common
function in o3tl and use that in all instances where we duplicated
the code.
Change-Id: I74091fbbde8c2ba8c7e4ab30194ab53e2a338e52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180372
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
These are only sent to an external API expecting char*-like strings,
or for comparison. Having every assertXPath having three of _[ou]str
is too much syntactic noise, making the unit tests almost unreadable.
Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
where the use_count() call was happening without any kind of
synchronisation - switch to use std::atomic which does the right thing
for us
Change-Id: I79a6452f42bd425ea494bb0298dc134de5678813
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170217
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Most of these don't use boost themselves, nor do they need
it transitively since the use of boost::optional was removed
Change-Id: Ic9dee1c4e160b313ec5b91677b02ffdea6c5779d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164440
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
This allows to simplify the code somewhat, and also to relax requirements
to the arguments, e.g. allowing to pass const objects to search in vector
containing non-const objects.
Change-Id: Id34911a8694bbdec275d22b51ca4a0845c9fa4c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163519
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
And change o3tl::iterateCodePoints to use sal_Int32 for its
second param, to integrate better with places where the parameter
comes from an UNO API, which cannot use std::size_t
Change-Id: I7b9dd2c9bc7f48e6c4a912f039f1b5dae7beae69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151421
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...as what they do is orthogonal (and it turned out that the use case that
motivated the addition of o3tl::iterateCodePoints in the first place needs them
independently, anyway)
Change-Id: Id33901a2f7ac627253654ee6d883305dcf5a456f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151415
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
improve the check by checking for methods that exclude
using string_view, rather than checking for methods that
__can__ use string_view, which leads to exposing
some holes in our o3tl/string_view.hxx coverage.
Change-Id: Ic9dd60441c671f502692f9cd2a1bb67301c4b960
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150277
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...not the whole CppUnit::assetion_traits<T> classes (where applicable). That
avoids spelling out the (identical) equals member functions, and also leaves
around the less and lessEqual member functions, in case they want to be used
after all.
Change-Id: I18f8d6cff0353921ced4952b33a0c85ff8292923
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147165
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It didn't quite make sense before that maxsize == 0 meant no cleanup,
and now with items optionally being count as having size more than 1
it makes even less sense to limit the size to max_size() of the
containers. This comes from 16a338e173,
so instead make that special caller pass a large size, which in
practice is the same.
Change-Id: Id875862126200ba889211f6e4079ae5921f27650
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133690
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
When used with items that may vary significantly in size (such
as SalLayoutGlyphsCache storing glyphs for texts of different sizes)
limiting lru_map to just the number of items performs poorly,
since it may use only small amount of memory if items are small
or it may spent a huge amount of memory if items are large.
As extra optional template argument to o3tl::lru_map that is a functor
that provides cost of item each, and the total size is based on this
instead of each item having cost 1.
Change-Id: I2b326754fe63eb4bd20010d4cea615187407e26c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133672
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Regression during `make check` introduced with
ab699bfdb3 "new loplugin:stringviewvar looks for
OUString vars that can be".
Change-Id: Ib6b9aabcfd380b43a77a97cf9d7e15c37aeb852c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133204
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
SvParser::aToken was OUString despite being a buffer where the parsed
result is collected.
Change-Id: Id24c842738ea0f6f1836f77d855069963ac5ae55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130763
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
As the OUString equivalent shows, it needs to check == 0. Commit
33ecd0d5c4 for some reason also
dropped the cheap checks (even from OUString) that OString has,
so add them.
Change-Id: I88e68b5ae10fd76c3c08b9b36d5abed0fad17bbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130753
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
...including ones with a rest out parameter, modeled after their O(U)String
counterparts and not present in any C++ standard (so intended to stay in o3tl,
even when the C++20 wrappers are eventually removed again). Plus test code.
These additional overloads will be used in forthcoming commits changing more
places to use std string_view.
Change-Id: Ifd05e0fdcb93e8751da22b8e4a59796ad00fe581
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122407
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
If a LogicToLogic uses fixed units, we can use o3tl::convert
instead. We can also do the same for all other cases where
LogicToLogic is used, but that needs additional investigation to
determine if it is safe to do so.
Note:
MapUnit::Pixel is converted to o3tl::Length::pt because it assumed
72 PPI for a logical pixel, which corresponds with the conversion
rate of a point (72 PPI).
Today, 96 PPI is standard, which is also used for o3tl::Length:px.
Change-Id: I29126df38bfcfda74b5d83d4cb880a378aecd18b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120230
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
MM50 constant is the number of twips for 5mm. This is (ab)used as
a "shortcut" to set or compare various variables through the code
and also to set a multiplied value (like 1cm, 2cm, 4cm) or divided
value (2.5mm, 1.25mm). The problem with this is that converting the
5mm to twip doesn't round up exactly and multiplied and divided
values increase the error even more.
Instead of basing it from MM50 constant, it is just better to use
our o3tl::convert (or the added variant o3tl::toTwip), which can
actually calculate the conversion at compile time, so there is no
added complexity at runtime and we get a more readable code with
more exact result.
i.e.
o3tl::toTwip(4, o3tl::Length::cm)
instead of the more cryptic
MM50 * 8
In addition also sanitize and comment the values of the constants
in sw/inc/swtypes.hxx.
Change-Id: I85c306c36207d47ac3dc207094b68d0fb1ca5b70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119397
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
* Updated README.md contents to fix various issues
* Fixed source links by using [git:], processed by mkdocs scripts
* Added README.md for ios, setup_native, unotest
* Fixed issues with "underline" and "less than" sign
Change-Id: I3e52a1d3372586c390ee6c42a2ef48bbabc81398
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114248
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Renaming all README files for all top level modules to README.md,
applying no content change at this stage to be able to track history
of the files. These files should be edited to use correct Markdown
syntax later.
Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
This also allows to easily add more units, both of length and for other
unit categories.
The conversion for "Line" unit (312 twip) is questionable. Corresponding
entries in aImplFactor in vcl/source/control/field.cxx were inconsistent
(45/11 in; 10/13 pc; 156/10 pt). They were added without explanation in
commit c85db62602. I haven't found a spec
of the unit (https://en.wikipedia.org/wiki/Line_(unit) is not specific).
I used the definition based on "by pt", "by mm/100", "by char" (they all
were consistent); "by pc" seems inverted; "by twip" was half as much.
This accepted conversion makes unit test for tdf#79236 pass.
Change-Id: Iae5a21d915fa8e934a1f47f8ba9f6df03b79a9fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110839
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
emscripten clang fails with:
sc/source/core/data/attarray.cxx:378:44: \
error: call to member function 'erase' is ambiguous
aNewCondFormatData.erase(nIndex);
~~~~~~~~~~~~~~~~~~~^~~~~
include/o3tl/sorted_vector.hxx:86:15: note: candidate function
size_type erase( const Value& x )
^
include/o3tl/sorted_vector.hxx:97:10: note: candidate function
void erase( size_t index )
This looks like a compiler error, but if the vector contained
size_t values, this would also be ambiguous to begin with. So
this just renames erase(size_t) to erase_at.
And instead of a 2nd find in the failing code, after copying
the vector, it mow uses std::distance to remove the item.
Change-Id: I7d03ff32352a1890cc01ca241452c0f00d6a9302
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108212
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Andrea Gelmini