To have a more direct and more reliable association between the
XShape/oox::Shape and the model data svx::diagram::Point I added
optional usage of the Model-UUID for that at the oox::Shape.
Also added a 'fake' UUID to work with the BackgroundShape's
attributes. Changed all preserve/rescue code to work based on that.
Also cleanups/comments and preparations of some flags in the
Diagram ModelData to steer behaviour on re-ceration.
Change-Id: Ie30effdff34dcdbbc79a766de09157b2a3bd97d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133168
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
The ToolbarValue class defined in include/vcl/salnativewidgets.hxx
was used only by vcl. Therefore, it is now moved to a seperate include
file named toolbarvalue.hxx which is inside vcl/inc folder.
This header file only contains the definition of the the ToolbarValue
class. All the files that references the ToolbarValue class now
include toolbarvalue.hxx.
Change-Id: I78fe3ceb09892c5d3f720ee3d66111bdcdf48db2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131321
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
...to make those char class array initializations more readable. (Making the
corresponding variables constexpr is mostly done so that failures in the
provided `unencoded` arguments, like non-ASCII characters or duplicate
character typos, would lead to compile-time errors also for !HAVE_CPP_CONSTEVAL.
And assigning to a sal_Bool std::array needs another hack to avoid false
loplugin:implicitboolconversion warnings.)
Change-Id: Ieb8827f69f55f1212a9428817d5331fcb18ef1d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Having a separate sparkline context is very useful, so we can add
a custom UI when the user has the cursor over a sparkline. This
will allow a "Sparkline" tab for NotebookBar and its own deck in
Sidebar, activated only when the sparkline is present. Also the
pop-up menu can be customized specifically for the sparkline, but
this may be less useful.
For the sparkline context we need a custom shell - SparklineShell
where now all the UNO commands can be implemented (not done in
this commit).
Change-Id: Idca2ad946af3afdd1b494744b80c9c093eec602c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133022
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
...which had been butchered by c7fb93764b "Cleanup
comment": e4ff847fe0 "loplugin:stringview check
for getToken and trim" had turned this into a template, but had not lifted the
other restrictions. But while at it, also adapt the mention of "OString" and
"std::string_view" in the comment to that
e4ff847fe0 change.
Change-Id: I3c27efe145c4bea6c4b16f81da671bf22160545c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133000
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Additionally to the Text/Attributes already saved/secured after
Diagram import, secure more data that is part of the Diagram
ModelData. This is about attributes (e.g. FillStyle/LineStyle,
TextAttributes, ...) in UNO API formt that will be secured/
attached to the Diagram ModelData in it's
svx::diagram::Point structure.
This is done for all those entries for which a XShape will/
would be incarnated, thus associated to entries that will
get a visualization, including the BackgroundObject.
From that data, at re-creation time, the attributes can be
re-applied to the re-created XShape(s), also after changes
to the Diagram Model Data (e.g. Add/Remove).
This is - besides the already added securing of the Style/
Theme - a 2nd method for lossless re-creation. For the
BackgroundObject - if it has FillStyles - it is even the
only method to secure that data and thus necessary for that
case. The selection of atributes that gets secured is minimal
for now and may/need to be extended for existing cases
accordingly.
Change-Id: Ie9b72b9b9135113cf858d57fe6cd8622d736c4a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132976
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
When OutputDevice::ImplLayout() computes glyphs, the result
is always the same for the same string (and font etc.),
and if the function is asked to work on just a subset of the string,
the returned glyphs are often also a subset of glyphs for the full
string. Since e.g. EditEngine breaks text into lines by first
laying out a full string and then repeatedly calls the same function
for a subset of the string with increasing starting index. So if
the full result is cached, it's faster to just make a subset of that,
adjust it as necessary and return that, instead of doing a layout
again.
This requires support from harfbuzz to tell us if it's safe to break
at a given position, and HB_GLYPH_FLAG_UNSAFE_TO_BREAK is that
(https://harfbuzz.github.io/harfbuzz-hb-buffer.html#hb-glyph-flags-t).
I'm keeping the optimization for tdf#144515, as avoiding the extra
layout altogether is still useful.
Change-Id: I33f70f9af89be79056e464908eac0861f58d274a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132753
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
For !LIBO_INTERNAL_ONLY, go back to the state before
d91d98a536 "fix gcc-4.0.1 and/or 32bit build for
string literals" of having just a sal_Int32 overload. (For !LIBO_INTERNAL_ONLY,
the current state was confusing, as the existence of further overloads depended
on __cplusplus >= 201103L.)
And for LIBO_INTERNAL_ONLY:
* Have overloads for all integral types, with an assert checking that they do
not use out-of-bounds length arguments. (The std::make_unsigned_t dance in
the assert is needed to avoid signed/unsigned mismatch warnings as seen at
least with MSVC.) This removes the need for explicitly casting arguments that
are larger than (unsigned) int. (And I cleaned up two such places that I had
become aware of with the abandoned previous attempt
<https://gerrit.libreoffice.org/c/core/+/132825> "Let O[U]StringBuffer ctors
take sal_Int32 length parameters"; there may be more places to clean up,
though.)
* Have deleted overloads for all integral types that are not actually integer
types. (This excludes signed char and unsigned char, as at least
> OUStringBuffer aBuf( rToken.GetByte());
in ScTokenConversion::ConvertToTokenSequence in
sc/source/ui/unoobj/tokenuno.cxx does a legitimate call with an argument of
type sal_Int8 aka signed char.)
Change-Id: I2df77429f25b74f19cc3de5064e6fd982e87b05e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132951
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
We use the AddTempDevFont() API to add a new font. Sadly there is no
corresponding way to remove such a temporarily added font.
Change-Id: I6fe61919daa5af29e964cec1caf7293aefa8ea4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132948
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
The testcase has a very long text in a cell that is really high
enough to hold only one line of text, yet EditEngine formats and
wraps the entire string. Which can be expensive because of calling
into text layout to find out width of a text portion, and this
is done repeatedly for the yet-unformatted text, so pretty much
O(N^2). For top-aligned text it's enough to format only as much
as will fit and ignore the rest, so implement that and add
EditEngine::EnableSkipOutsideFormat() to enable the optimization.
Change-Id: Ida87a1843737a368798ba2b3e60eedc99ee0f611
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132932
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
look for call sequences that can use string_view and the new o3tl
functions in o3tl/string_view.hxx
Also add a few more wrappers to said #include file
Change-Id: I05d8752cc67a7b55b0b57e8eed803bd06bfcd9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
where we can convert that to
o3tl::toInt32(o3tl::getToken(
and avoid the heap allocation of a temporary string
Change-Id: Ib11c19c6e6cdc0de3e551affd3578d181e292de4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132810
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The Style/Theme information is central for re-creating the
Diagram shape representation. Make that data available in
the ModelData classes in svx. With that information, a re-
creation with all needed attributes is possible, e.g. when
the model gets changed (remove/add data entries).
Also some cleanups done.
Change-Id: Icd925c9731891092f1ddd96c8feb165e1f846f4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132738
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
since we now have o3tl versions of those that work on
string_view.
Also improve those o3tl functions to support both string_view
and u16string_view
Change-Id: Iacab2996becec62aa78a5597c52d983bb784749a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132755
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The color values in vcl::Font are obsolete, and the underlying font is
the same regardless of the color.
Change-Id: I66801a07092bc189f43bf2b28bc54ead6d20f70e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132747
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
And can't be put into impglyphitem.hxx, as then it would have
a circular dependency with fontinstance.hxx .
Change-Id: I57289fa5433851f095f7b73ce842ba5a0e8497ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132745
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Now the cache should be capable of detecting what needs
to stay the same for having the same result, so it should
be enough to have just one cache that can reuse results
even between callers from different places.
Change-Id: Ibdc0303f5b727d1a1d7be91d61db9465ed95e1c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132673
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Noel Grandin