There was no LOK API to get a list of all fields of a given type where
the name matches a certain prefix.
This is useful in case the API cilent wants to know what previously
inserted refmarks were deleted by the user as part of deleting text
content.
Add a new getCommandValues(".uno:Fields") that returns the names of
matching refmarks. Do not return the refmark text, assuming that would
be updated by the API client anyway.
In practice this is needed by Zotero in case it wants to model its
citations with refmarks.
Change-Id: Ie469253891896aa8ab00d434c9ab116adbe3864b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144985
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Pasting Calc tables into Writer tables uses temporary table
deletion, which never occured if change tracking was enabled,
resulting freezing. Fix this by disabling change tracking
during temporarily, also add a limit for other potential cases,
where it's not possible to delete the table.
Regression from commit 05366b8e66
"tdf#60382 sw offapi: add change tracking of table/row deletion".
Change-Id: I57874fa658652b30fc78b267ab49a52d7277a838
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144946
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Now roundtrips the w15:appearance value which dictates whether there's
an effect when hovering a placeholder.
Change-Id: I3c911a0cfe31e235b9d981bbff0c1bb5827a85ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144845
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
some of the items in that resource are themselves dictionaries instead
of references.
Change-Id: I427386b14fe5507dfdfc9745dad27a8fceefd929
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143564
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 4cb521b28e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144438
Tested-by: Jenkins
of the inner XObject, else the clip polypolygon may clip out partly or
whole contents. Adjusting the clip polypolygon is not straightforward.
Change-Id: If3b208ba850c3579c9e16c15e4fb2f947dad4406
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143561
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit a67dcc248a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144436
Tested-by: Jenkins
(Adding just CPPUNIT_ASSERT wasn't enough to silence the warnings at least for
my GCC 13 trunk build, so also added the redundant initializations.)
Change-Id: I8ec9e097d4725d22dd90e9278a37768a749e292d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144943
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The window will clear its background in [SalFrameWindow displayIfNeeded]
so when Skia/Metal is enabled, explicitly flush the Skia graphics to the
window during live resizing or else nothing will be drawn until after live
resizing has ended.
Also, when Skia/Metal is enabled, rapidly resizing a window has a noticeable
amount of flicker so don't send any paint events during live resizing. Also,
it appears that most of the LibreOffice layouts do not change their layout
much during live resizing so apply this change when Skia is not enabled to
ensure consistent behavior whether Skia is enabled or not.
Change-Id: If6423faa72529b9de8735e04e69c9511aceb2276
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144979
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The combobox described in 148109 is indeed a listbox.
If drop down list is not open and only the selected item
is shown without having the focus, the background color
will be paint either it's defined as native control
or not.
Change-Id: I210916fbe07f74aaa5835bf2c88e764b010c6d61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131904
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Used HTML should be free from new line characters and also <ul>
marks so we don't generate new lines.
Change-Id: I02b8f9a9af9f93e8d90a7f4a22ea02c8e1f47651
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143507
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144948
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
update event was triggering other widget change:
when opened calc and selected shape first time
we saw color text next to other color label
Change-Id: I71670ac1273ce96fafc8d20126d9f32151e96d89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143471
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Pedro Silva <pedro.silva@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144950
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
to make it easier to understand, very little of the code is shared
between the nTol == 0 and the nTol != 0 cases.
Also flatten the code structure a little.
Change-Id: I601b9046a6678a5dcf2176dbfe565a9a4e7299d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144962
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
from around:
commit 780d83771a
Date: Mon Nov 4 17:17:58 2019 +0100
jsdialogs: .uno:Color with string argument
and:
commit 1144712bb9
Date: Mon Oct 28 10:19:50 2019 +0100
jsdialogs: make possible to set .uno:BackgroundColor in Writer
SvxColorItem Color SID_ATTR_CHAR_COLOR
(SfxStringItem Color SID_ATTR_COLOR_STR, SvxColorItem Color SID_ATTR_CHAR_COLOR,...
^^^^^ ^^^^^
rename the most recently added to "ColorString"
Change-Id: I9e00be60c768af124be7df800df4b26df83b5267
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144866
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Inserting a fieldmark using .uno:TextFormField, then entering into that
fieldmark using the cursor, finally doing in insertion again using
.uno:TextFormField resulted in a crash.
The problem is that lcl_SetFieldMarks() uses 3
IDocumentContentOperations().InsertString() calls to insert the field
start/separator/end, but right after inserting the field start we
already create an sw::InsertText hint, which works with an inconsistent
string (the start is already inserted but not the separator / end).
Fix the problem by just not allowing the insertion of fieldmarks inside
fieldmarks on the UI: these are meant to be read-only for the user, so
fieldmark insertion is OK to be not working, as long as a clear error
message is provided.
An alternative approach would be to insert the inner fieldmark in a way
similar to how import filters can do it, but that would be more work.
Change-Id: I7d1a7c638b179fd9149ccdc47215329e3433b6e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144947
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The immediate reason for this is that pipes are broken in the
Emscripten runtime, see
https://github.com/emscripten-core/emscripten/issues/13214. But if we
can drop the use of a pipe for other platforms, too, why not.
Without this, when attemting to run Collabora Online as WASM, I get:
Aborted(Assertion failed: nRet == 1, at: .../vcl/headless/svpinst.cxx,538,DoYield)
It is quite possible that the code could be simplified drastically. I
only replaced the use of a pipe with hopefully equivalent use of a
queue, a condition variable, and a mutex.
Change-Id: I9259ba36afeabce6474a1aec827d01bcbbd4412b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144944
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins
This was introduced forever ago with
commit 6c3ae34e32
Author: Frank Meies on Tue Nov 20 15:24:54 2001 +0000
Chg: Vertical Formatting - Growing frames
But why?
Assuming that anything that NEEDED to set a proper height
has done so by now. The commit suggests it was added to
handle vertical layouts.
If this exploratory patch causes problems
(and it very well might since this is a really generic spot)
then perhaps it can be limited to verical layout situations?
Change-Id: Ib6e4a45379e670fd343a2e2d87879e6bb52afebf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144787
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Adds ThemeExport that takes a svx::Theme as input and exports that
into a theme.xml file in the OOXML document. Currently supports
exporting of color schemes and font schemes. Format schemes are
hard-coded for now. The ThemeExport isn't yet used in any actual
export functionality.
Change-Id: I5ca9c256da65be77e7192be7d66c73d26d78ebd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143996
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
docx has the information, that a shape is a WordArt shape, after the
text content. So in import of such file there is already a frame
attached to the shape, which makes it impossible to set it into text
path mode.
The patch detects that it should be a WordArt shape. It transfers the
text from frame to shape, removes the frame and then sets the shape
into text path mode.
WordArt in OOXML has the same closed set of types as we have for MS
binary import. But MS Word can combine them with arbitrary shapes. The
patch does only convert rectangles.
The text is copied from frame to the shape as string. Thus it looses
all styles. But our Fontwork cannot use different styles for
portions of text, so I think that is acceptable.
Fontwork uses not the styles of the text but styles set at the shape.
The patch copies the styles from the first not empty run. That should
give sufficient results in most cases. These text styles are set at
the shape, which will result in a paragraph style referenced by the
draw:text-style-name attribute of the draw:custom-shape element in ODF.
The patch does not yet include export to docx. The current 'restore
old shape' on resave to docx is lost. ToDo: Patch for export.
Change-Id: I880ee7c7616db50524032e4b1443730a2d0a7361
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143615
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
warning seen on saving very simple writer document.
maybe since:
commit 91f649a119
Date: Thu Dec 9 08:43:27 2021 +0100
ODP import/export: refer to theme from shape text color
Refer to the 12 pre-defined colors by name + don't write the attribute
for the case when there is no theme.
Change-Id: I4a7d21a7bab1ee77336ed6a5de8862fbab9be177
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144870
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This patch fixes the tdf#70423 which is an unexpected line break for
~10k characters. The fix consists of removing part of the code that
creates a new paragraph when reaching ~10k characters. The limit was
not exactly 10k characters, because the code tried to break at space
character when reaching around 10k-100 characters.
A test is also created, which can be checked by invoking:
make CPPUNIT_TEST_NAME="testTdf70423" -sr CppunitTest_sw_txtimport
The test checks that there should be exactly 1 paragraph with 30k
characters inside it.
Change-Id: Ic37c2b6eb89b52b533e34dd117b9635b9608bab2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121548
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
This change extends writerfilter to use oox::ThemeFragmentHandler
to read the theme properties, and sets that to the one and only
draw page of a Writer document.
This change also removes ThemeTable and replaces it with the
ThemeHandler, which takes theme font data from svx::Theme
instead.
In addition, a test has been writen, which loads a document with
a theme, and asserts the draw page has the theme and the theme
properties currently supported.
Change-Id: Iff0048cd21ea030ac55287707852acc463ec3cb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143699
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Automatically switching to en-US locale when using English
function names caused too much confusion. There also might be the
possibility that the '.' dot decimal separator clashes with the
inline array column separator in some locales.
A proper solution would make this user-specified and if set also
adjust the separators to the common English ones. For now keep the
default locale again as it previously was the case.
Change-Id: Ic4712c6609c14f35cf0d1d842ac7443806a6e115
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144924
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
this code has been dead for some time, no need to keep it anymore.
Change-Id: I9c553fa7460bda5331f5908311783207bf88be17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144927
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
