Age | Commit message (Collapse) | Author |
|
Communicate Kashida insertion positions in an explicit way.
Rest of LibreOffice communicate adjustments to character widths (e.g.
for justification or spacing) using so-called DX array. DX array is an
array of absolute character positions (e.g. DX[n] is the position after
character n from the start of the lines, and its widths is DX[n] -
DX[n-1]).
This DX array is modified also when Kashidas are inserted after a given
character for Arabic justification, by expanding its width. VCL would
use this to know where to insert the Kashidas and how many ones.
But because DX array is used for both widths adjustments and kashida
insertion, this turns out to be a source of bugs since VCL has tosecond
guess the DX array to find which is pure width adjustment and which also
involves Kashida insertion, and the heuristics it uses are fragile.
This change adds a second array of booleans that records where Kashida
is inserted and communicates it all the way from where Kashida insertion
is decoded in Writer and down to VCL layout.
This change passes the Kashida array only when it seems necessary (e.g.
during drawing but not when measuring text since the DX array is enough
in this case). Hopefully no places where Kashida insertion needs to be
passed down were missed.
A couple of glyph and layout flags that were used for old heuristics and
no longer needed and are removed.
This also fixes:
tdf#87731
tdf#106309
tdf#108604
tdf#112849
tdf#114257
tdf#127176
tdf#145647
tdf#146199
Change-Id: I4ed0850ef2fdc3e9143341afac649e7e7d463c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138068
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This reverts most of commit 09558e2f45e27d572fd261562c884c2d2cc896a7,
the problem is that GetNextToken_() resets aToken, overwriting the value
created by this function.
Change-Id: I1daca07a6e01cfecfeff9fbf7c311b0d392d84d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138190
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
to use, so databrowser with it (view data sources) has the tall case,
while bases, create table in design view has the short case
Change-Id: If3269d2ab2ce62f09acac624e5ef7e91ff91eaea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137953
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
the scrollbar in the statusbar can be thicker than the vertical one
which looks weird when both set to the thick size
Change-Id: I76496e47203a7cde72082f8e6b83f5af3e8c3759
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137952
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib2dba2d5e47a8c39f79c3ab5a8e79e8185599da6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137951
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I551112fb097a6ac2b442cd37d1a16bd2b34ecc54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137932
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I513a2885027d0295f70e7c64269d1653a6c2642b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137870
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This reverts commit 106bc0fd7a94eb48e8a81be753c156496b83578a.
it has an unusual effect in writer on hiding and reshowing scrollbars
Change-Id: I0569bf3ddb9b04f1afc6c26add84086bdf4ff5fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137886
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I22745f1c910f68fd2c0b31e8392c111fc76ef529
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137864
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
as is currently the case for the databrowser scrollbar, and do the
same to the vert for consistency
Change-Id: Icf8694f172c3121f35f612a47faa2e2caef890c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137863
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ibd5f009c4717ce236334e5fc407512a5ef8c2a70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137844
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I436067b4f2b463fe9a5d6789cf96f906891757bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137810
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Idf46b209c573316e810371597acb1567536d9529
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137806
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
with the motivation that for gtk4 theming for vcl scrollbar isn't
available, so it looks super yuck but this should also support the
long-press scrolling thing under gtk3 as a side effect.
Change-Id: Iada5a66087d5aa982f9213d7ec0a05f6177f4e66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137750
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Using "Tools > Protect Spreadsheet Structure...", it is possible to
protect the structure of a spreadsheet document. Without this patch in
place, the [+] (add new sheet) button is clickable but it does not work.
This is confusing for the user, so it was decided that the button should
be disabled when the structure is protected.
This patch disables the [+] button just after the structure is protected
using the above toggle menu option. The menu option becomes checked, and
the [+] button gets disabled immediately. After choosing the same toggle
menu option again, the check mark goes away, and the [+] button becomes
enabled immediately.
In this patch, GetDocument().IsDocEditable() is used to check if the
document structure is protected. The argument for this choice is that
the same function is used when renaming a sheet with
ScDocFunc::RenameTable().
Change-Id: If812d94841d3efd98d7ef898cc1f4b2f1387130b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137365
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: Iccdb04df53bc981e2240240daddf15e9e1bb5a16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137310
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idd50b3533e8b32e66cb4975e1257048f9233089b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137078
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I40af398107362615b2500dfa5262a63551489269
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137164
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I60e7373c924a479fed72eb4f0538006e3e422004
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137019
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2702e716dc669ffbb870d36d060e110288d7a744
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137043
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
EmbeddedObjectRef::GetGraphicStream() creates a writable
SvMemoryStream, read the graphics data into it and then returns
the stream, which will be afterwards used to decode the graphics.
But if the data is broken, incorrect seeking may cause a seek
way past the buffer, and since the stream is writable, it would
be done and cause problems such as running out of memory.
The VersionCompatRead class is one such place that reads size
from the stream and then seeks based on the read data.
Add SvMemoryStream::MakeReadOnly() that will change the stream
to be read-only after the initial read of the data into it.
Change-Id: I1d44aabaf73071a691adafa489e65e4f5e3f021d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137002
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
By default Rectangle uses closed interval, if we really want to use half
open intervals then we should specifically say as such in the name.
Change-Id: Id7a91120ba1a1a4bc330014216b73a692dbf03a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136575
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
which is internal API, unused (as far as I can tell) by external
users.
This state is purely a bitset
(as implemented by utl::AccessibleStateSetHelper)
so we can just return it as a 64-bit value.
This shaves significant time off the performance profiles
of code that loads very complex shapes, because this state
is frequently used, and we no longer need to allocate a return
value on the heap for every call.
Change-Id: Icf1b3bd367c256646ae9015f9127025f59459c2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136786
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I757b29574526882da6e307cef51dfa70f6a1c4bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136833
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I05770f0209aaee1b9af6b88f85764ec98e7fa5a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136504
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Hyperlink URLs on images are currently written to the HTML output as-is,
without any any encoding.
Image links are written using HtmlWriter from svtools, which has the
advantage of not building the markup manually (similar to
sax_fastparser::FastSerializerHelper for XML), but that doesn't do any
escaping. Some other parts of the HTML export build the export markup
manually, but use HTMLOutFuncs::Out_String() to encode problematic
content.
Fix the problem by using HTMLOutFuncs::Out_String() in HtmlWriter for
attribute values: it seems reasonable to assume that users of HtmlWriter
would pass in unencoded strings, similar to how the sax serializer
works.
This could lead to double-encoding in case some user of
HtmlWriter::attribute() would encode its attribute value already, but
inspecting existing calls, none of the clients seem to do that at the
moment.
Change-Id: I5439e829b1b837cb9c51292b118f0b47e84197db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136399
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
See https://crashreport.libreoffice.org/stats/signature/%60anonymous%20namespace'::calcCustomItemSize
Change-Id: I5f1b19b7679c73cf29952629469e5151395b2b12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136254
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Changing "Save Autorecovery... information every ... minutes"
option in Tools->Options...->Load/Save->General shows that
dialog window to warn about its work.
Change-Id: I91ae72ea1e52ec5c6d9286a43cd986386636076c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135221
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I9fdce7c9fb8a18571d3d6a317b28a344f18efa82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136227
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I8134744b6c1279c497d4763eddf614bb840f7f3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135602
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Signed-off-by: Mert Tumer <mert.tumer@collabora.com>
Change-Id: I275cbea668afc5beb5147370119631df8b6a2d46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135178
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
The original problem was that %PRODUCTNAME wasn't replaced for
accessibility descriptions (which are reused for extended tips) under
gtk.
Universally querying all a11y descs on load to potentially replace
%PRODUCTNAME in a11y descs at runtime led to tdf146971 which was a huge
startup slowdown.
The half way 7.3 fix was to leave a11y descs alone, but do the
replacement when querying for the extended tip case. So the extended
tooltips were ok, but screen readers would still say a raw
"%PRODUCTNAME" text, hence the rewording effort to remove %PRODUCTNAME
from the a11y descs entirely for 7.4.
But there is now a few cases where some options paths exists in the a11y
descs which is not exactly correct wrt to the text shown in the options
dialog.
Reworking the options dialog to not have %PRODUCTNAME there at all and
updating everything to fit that sort of change would not be popular. So
move the cases where a11y descs really should have %PRODUCTNAME in them
out of the .ui files and into .hrc files and use specific
set_accessibility_description calls for them via ResID which will do
the %PRODUCTNAME replacement automatically.
Hopefully the a11y runtime cost for just this handful of cases is
negligible in the overall scheme of things.
Change-Id: Ieb17d26fd581cd5804a52b371b3bb5ea43023aa3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135432
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...where a signed and an unsigned value are compared, and the signed value has
just been proven to be non-negative here
Change-Id: I20600d61a5d59d739bc1bee838c0038e4611aec2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134875
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(*) use o3tl::span for the array param, which means we don't need a null
entry to terminate the array
(*) use std::unordered_map to speed things up
(*) mark the array as static at a few more call sites
Change-Id: I05b6cae7552f44459e183ec05cb94e60edb3bfe0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134832
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Regression from b099da78a6f0b3e120f706714003b05d84d11e70
we didn't update linked OLE document after document reload
Change-Id: I8e52f6430f454b276cb43449c6f7a3b0e07e909f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130692
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Tested-by: Jenkins
|
|
found by inspecting call sites of OUString::getToken
Change-Id: I4269c7476c7aa46fac39528227e350568f0eb34a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132644
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id10d68f2eb016671be6842dfaa82909207b0708d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133754
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib5a86de01abd6eab2f60d76bda50fa9407286dbc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133770
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I042b8dcadbf7581de325c161763fe35aecde5ca2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133694
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4462f7cf4740fa4d1b129d76a0775f4250f41bbd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133555
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4229460fb27ae3dc133c0f6a53c7792a87bf4db3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133389
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I336fd329b577b6fa141265d8bc7ce67784bd7306
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133210
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
for which we have o3tl:: equivalents
Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913
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>
|
|
Anything else is just a joke today.
Change-Id: Ie6a0cec1edcd257cbadef702018e6a919e6a0b44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132628
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
which converts to compare
Change-Id: If03c790ea113a7caedbe89f926b29055c9ec1e76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132455
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This ports most existing uses of the now deprecated
`AccessibleTableModelChangeType::INSERT` and
`AccessibleTableModelChangeType::DELETE` to emit
events of the the four new table model change types
added in
Change-Id I30821a5acafa4f3d1dafdfc219f3b4568d9a6e89,
"a11y: Add new table model change types for row/col insertion/del"
instead, which among others fixes the a11y events that are sent
on the platform level for gtk3 and macOS,
s. commit message of the mentioned change for more details.
From all I can see, `AccessibleGridControlTable::commitEvent`
is just meant to handle removal of rows, not columns,
so add a corresponding assert there.
(See how only row-related a11y events are emitted
in `svtools/source/table/tablecontrol_impl.cxx`,
and the "columns aren't selectable" comment for
`AccessibleGridControlTable::isAccessibleColumnSelected`.
Given that the full range of rows would previously
have been sent in the `AccessibleTableModelChangeType::DELETE`
event for column removal, this should still have worked in
practice, since this would have cleared the whole vector,
and elements would have been inserted on demand as needed
again later. However, if that should ever be needed in
the future, it should be handled more explicitly.)
The handling of sending events when rows or columns
are inserted or deleted in a Calc spreadsheet is more
fundamentally broken and will be handled in a separate
commit.
Change-Id: Icfd5e326143e8e90cc513e430bfabbba39e7bdc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132218
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
WYSIWYG preview should use the actual document color instead
the dialog/window background
Change-Id: Ifff07b2f754ed88cb7e60e0494092e266d3c7cf1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132023
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
It's used only for the ConfigurationWrapper singleton, so it's used
only the first time and then ignored. It also causes calls to
comphelper::getProcessComponentContext() for every single invocation
despite the value not being needed, and the calls may not be cheap
(it's ~5% CPU during ODS save because relatively frequent calls
to officecfg::Office::Common::Save::ODF::DefaultVersion::get()).
Change-Id: I02c17a1a9cb498aeef220ddd5a0bde5523cb0ffb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131056
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
See tdf#42949 for motivation
Change-Id: I25779cbfb1aa93c31d6e12ac95e136b3bdbbc058
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130403
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|