Add login mechanism for them
Also add --config and --outdir arguments to
set the pathes
Change-Id: I641f10396e1f4cf5bdb19da287b1a2962ff4e2ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135495
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
during creation it might not have all its children created yet
if a11y querys it during its setup.
Change-Id: Ifbbec7eeb80409dc5e871c2022d1ee1e36c6e74f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135526
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
no need to copy
Change-Id: I1fcc5d645a8f5278e2122a168b00c846d75bc091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135522
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
70009098fd "tdf#128969: Let the user explicitly
decide to execute an external program" had shoehorned that new warning dialog
into the existing XSystemShellExecute::execute IllegalArgumentException return
path, which caused some issues: For example, it caused the warning dialog to
reappear after you acknowledged it on macOS (see comment at
<https://bugs.documentfoundation.org/show_bug.cgi?id=140886#c10> "Allow
hyperlink opening on file with execute bit set ref. CVE-2019-9847"), and it
caused the warning dialog to erroneously appear for a non-existing file on
Windows (see comment at
<https://gerrit.libreoffice.org/c/core/+/124422/2#message-ac76b728fedc53e7d0a04c99f00364068b51a8ea>
"tdf#128969: Let the user explicitly decide to execute an external program").
So rather than reusing IllegalArgumentException for this case, use a different
kind of exception to trigger that warning dialog. The existing
AccessControlException (which is also a RuntimeException) happened to fit more
or less well.
Change-Id: I3f743c21be48d54f10951006ef3d7172e23e9076
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135524
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Update helpcontent2 from branch 'master'
to dae8c0f4225b25d4612f7a9db86fc4518bf4b3d9
- (Related) tdf#126658 update Arrow styles help to reflect UI change
text/shared/01/05200300.xhp (Arrow Styles tab)
* update new control names
* corrections to description of tab and its use
text/shared/00/00040502.xhp ("howtoget" for Arrow Styles)
+ add appl-switches with
* menu variations for Writer, Calc, Draw and Impress
+ access variations using toolbars
+ add right-click access
+ add section for embedding
* rename German ID
Change-Id: Ic224d72b2abeee777063626f4dcdb570562d3650
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/133037
Tested-by: Jenkins
Reviewed-by: Seth Chaiklin <sdc.blanco@youmail.dk>
During PDF drawing we already know the glyph width, but when subsetting
we get it again from the font subset.
For fonts without CFF table this is redundant but harmless, but for
fonts with CFF table, if the CFF and hmtx table (the authoritative
source of glyph widths) disagree, we will be drawing the PDF string with
the wrong adjustment resulting in displaced glyphs. This is a font bug,
but avoiding redundancy and having one source of truth is an improvement
overall.
I kept the code that calculates advance widths for font subsets, just in
case it is is still used elsewhere.
Change-Id: I757cd0c2ebb6477b2f840d0005e84b5a131f7efb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135442
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
The label for Calc was Format > OLE Object (using
.uno:ObjectMenu), while the label for Impress was
Format > "Object and Shape" (using .uno:FormatObjectMenu).
This patch (a) changes the label of .uno:FormatObjectMenu
from "Object and Shape" to "Text Box and Shape"
(to bring it in line with Writer). This change appears
immediately in Impress, and (b) changes the .uno:ObjectMenu
in Calc to .uno:FormatObjectMenu, which also gives the
"Text Box and Shape" label, which is also more appropriate
for its submenu.
Kept the same keyboard accelerator "o", which was used both
in Impress and Calc.
Change-Id: Ifcf7b953b6bed262d630f7a07bf1f5000ee33aa4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135162
Tested-by: Jenkins
Reviewed-by: Seth Chaiklin <sdc.blanco@youmail.dk>
Can use CPPUNIT_TEST_FIXTURE() instead.
See commit a226cec52e
(CppunitTest_sw_rtfimport: convert one testcase to use
CPPUNIT_TEST_FIXTURE(), 2019-11-05) for motivation.
Change-Id: I6d5c130ea25982d2cc0dc424a79c6962c1aa4f1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135510
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Nonobviously, there are situations where the anchor node must be
preserved and restored when it's not on the node that is being deleted.
(probably regression from commit 91b2325808)
Change-Id: I39f09ddb631204c8ad522f9ec7068d235ca94ad2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135509
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
* Next/Previous controls placed in an extra frame
* This frame becomes hidden in case of picture and objects
(next/prev is only possible for frames)
Change-Id: Iab7042b72efa7857c5405a8c345ba03d6b975519
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135494
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Also fixes: tdf#134007 tdf#138835 tdf#139514
When a character is deleted via the keyboard by Backspace or Delete key,
an artificial selection is created in SwWrtShell::DelLeft()/DelRight().
Ideally this should not delete flys that may be anchored to the
paragraphs, but unfortunately this may happen if there are only 2 empty
paragraphs in the section, because then the artificial selection cannot
be distinguished by the SwDoc implementation from a selection from
Ctrl+A (Select All), which *should* delete the flys.
So introduce a new flag that needs to be passed down multiple layers so
that SwUndoDelete can use it to determine if flys should be deleted, and
translating it to a flag that had been introduced to preserve flys in
ReplaceRange() previously.
There are a couple more callers that look like they want to "replace"
some text, so guess a bit at where to set this new flag.
(note: of course fly anchored *as char* must be deleted via keys.)
(regression from commit e75dd1fc99)
Change-Id: Ib4467476b12a12aefbbcb74ab9802f9318cf9aa0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135476
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
... and use it to remove a duplicate and simplify code.
Should mostly be a refactoring, which was mainly done by some
larger sed calls, except for the new API calls, which helped
shrinking some LOC. All data is also now private.
Originally two of the "replaced" "classes" had unsigned width
and height and one had signed. Noel pointed out, that during
calculations, the value might get negative temporarly, so this
now settles with signed values. Still the set size should never
be negative and this is enforced this way. Not sure that is what
Noel had in mind.
This also includes:
- rename WindowState => WindowData
- rename WindowStateMask => WindowDataMask
- rename WindowStateState => WindowState
- move WindowState and WindowDataMask to vcl/windowstate.hxx
- move WindowData(Mask) and WindowState into vcl namespace
- readability: replace or'ed WindowState enums with "meta" enums
+ add "meta" WindowState enums PosSize and PosSizeState
Change-Id: Icd16cfb498531aa7238ddbde83fcb0ed6d9e4f77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135426
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This is similar to commit 51942eafdb (DOC
import: allow negative page border distances, 2022-06-08), except here
we map \pgbrdropt's 5th bit to the "from page edge" bool, and then the
rest of the import works already after the DOCX fixes.
Similarly, the export has to map the "from page edge" bool to \pgbrdropt
and has to call into editeng::BorderDistancesToWord(), but the rest of
the process works after the DOCX fixes.
Change-Id: Ic88f1ab17ac169025c38790ffa895748df0a76c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135502
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
* Update helpcontent2 from branch 'master'
to fc9022d593c7b7ae9818ed4b4502a2743e7ac377
- Fix sentence about solver settings
As pointed out by Adolfo in change 40ee3181de08d372b5a25bb691644a94d3ffe9bd, the word "beware" was used incorrectly. This patch fixes it.
Change-Id: I3b2dd94b04b9c9c5ca5dc9c0b4c99a8e1c048941
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/135384
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Callbacks may be invoked while calling getLOKPayload(), which
would try to lock the mutex again. I actually originally expected
this possibility, as the comment and moving the data to
temporaries in CallbackFlushHandler::enqueueUpdatedTypes()
shows, I just didn't realize the used mutex wasn't recursive
and so would deadlock.
Change-Id: I2b5c4b6b4c1a3933a32ae4641830877e085f2b6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135499
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
and use it for the case in charnamepage
Change-Id: I5920aa429c750e9b147cbc09a6f3814166851a8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135493
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
GCC's -fdiagnostics-color option is complex (read: brain-damaged),
since it depends on how the compiler was configured during building it
(https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html).
So while with Clang coloring works out of the box and the option
can be used for force it in special cases, GCC depending on how
it's been built may (or may not) require the option explicitly
just to do the sane default. 13b52f50e5
added an explicitly =auto to handle that, and then
9ab2703d5c changed it to =always
depending on gb_COLOR to prevent it from overriding
explicitly used option. This results in a possible massive rebuild
when redirecting build output (because e.g. PCHs get rebuilt if
build flags change, and ccache I think cannot use cached compilations
either).
It should not be gbuild's job to go out of its way to handle broken
tooling, so just revert both of those. If somebody uses such a lame
GCC build, either don't do that, add those explicit flags
to CXX/ENVCFLAGSCXX, or create a clean way to add flags to CXXFLAGS
or something.
Change-Id: Ieac6ac7dd198639529aba8f47983587771772349
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135467
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Just translate the test and add required or handy CppUnit helpers.
Change-Id: Ib8ccd3490876c6302cca85e69f4d61600f7aec84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133844
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
In case the margin (distance between body frame and page frame) is
smaller than the border spacing (distance between border and page
frame), then we can map that to a negative border distance during the
import of DOCX files since commit
1f127a2b9e (sw layout: allow negative page
border distances, 2022-06-07), but DOC import had the same problem.
The above commit intentionally kept the default behavior of
BorderDistanceFromWord() unchanged to avoid side effects in other
clients of that function (not DOCX import), but means that DOC import
was still broken.
Given that it turns out there are only 2 callers of
BorderDistanceFromWord(), fix the problem by allowing negative border
distances unconditionally: this simplifies code & SetBorderDistance() in
the DOC import will now get the correct border distance out of the box.
DOC export works out of the box without any additional work.
Change-Id: I6bf15b3c73823c9265218b7b3a7b869e131818db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135484
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Inset values for top, bottom are calcualted differently in OOXML
and need to be coverted on import to the text distance LO values,
that place the text relative to the shape correctly.
At export, the values can be converted back to the OOXML inset
compatible values, but the values are not always converted back to
the same values as the conversion is not bijective, however they
do render the same.
This also adds the test for the conversion when importing and
checks that the exported values are expected.
Change-Id: Ic64eec1a2a80ddad997f916da3e87dc30aaa12be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135463
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Once a dropdown content control is inserted, the properties dialog can
modify list items. The desktop case updates these list items when
SfxViewFrame::Enable() calls SwView::ShowCursor(), but for some reason
the same implicit update doesn't happen in the LOK case.
This means adding new list items requires leaving the content control &
entering again, then the dropdown shows the new list items, which is
confusing. And also the update (when it works) is implicit, so it can
break without us noticing.
Fix the problem by explicitly updating the cursor before ending the
properties dialog: this will scroll to the cursor position, but that's
not a problem since the properties dialog is always editing the content
control at the current position anyway.
Show / hide is used because that's an easy way to call
SwCursorShell::UpdateCursor(), which is private to us.
Change-Id: I43aca24c2961ef6c4cc14f895edd6f3f22980148
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135483
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
A one-pixel image will do the job.
Change-Id: Ied9b51c104a39b0bcf5401d8486c11f87c979805
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135477
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
I can't see any reason for this code to be this way. I can
see that Jim has tried to make some dialogs retain window size and
position. Surely all dialogs should be able to do this?
Unfortunately, it has been this way since initial commit.
Let us live dangerously and see what happens if we give
power to ALL the dialogs.
VIVA LA REVOLUTION!!!
Change-Id: I44e389ba3cb46793365607d36a05474584ee6490
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135478
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
1. Create Justify::SnapToGridEdge() to adjust kern array
under CJK textgrid GRID_LINES_CHARS mode when snap to chars is off.
This function can handle a) Unicode IVS b) rInf.GetSpace() like
what CJKJustify() does. c) rInf.GetKern() value for letter spacing.
Excluded parts comparing to original kern array adjustment:
a) Kana compression under textgrid mode has been removed. Kana compression
is used to compress space of punctuation. It doesn't make sense to
perform that under textgrid node.
b) Inserting nSpaceAdd for CH_BLANK is removed. I don't know its
purpose.
2. Use Justify::SnapToGridEdge() in GetTextSize(), GetTextBreak(),
DrawText(), GetModelPositionForViewPoint() to adjust kern array
consistently.
Change-Id: I136a92f513fae05af2fb429e747356ba7eedec7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135086
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
* Update helpcontent2 from branch 'master'
to 40ee3181de08d372b5a25bb691644a94d3ffe9bd
- Related tdf#38948 Warn that Calc Solver does not save model to file
Based on Comment 36 from bug 38948, the help should make it clearer that Solver models are not saved to the file by LO Calc.
This patch changes the current <note> into a <warning> and makes it clearer that solver settings are not saved.
Change-Id: Ie1cdf5a82c105c371e05b85ccad6736ed5e74a3f
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/135272
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Testing it locally, I could download 52.000 documents
Reuse mimetypes dictionary from get-bugzilla-attachments-by-mimetype
by putting it into an external file
Change-Id: I875d90f6119c3c3bdfea6a0efd3bbc8c5be1eb63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135457
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
in View->Formatting Marks mode instead of hiding them
This way it's possible to avoid interoperability issues
better, when these (now visible) spaces are stripped only
in Writer, but not in MSO, resulting different layout,
i.e. bad paragraph alignment, because the users can
notice the extra spaces and remove them in Writer.
Extend SwHolePortion::Paint() to paint its text,
what is probably just a bunch of spaces.
It's an initial fix for tdf#43100, tdf#120715 and tdf#104683
(cursor movement on the hidden spaces, end of paragraph sign
before the hidden spaces, unable to select spaces after the margin).
Follow-up to commit 93d7bdcb85
"fdo#33167, i#20878: Show spaces at the end of line".
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: I48df3b41af37c77fd594bb6776ca30e845c51490
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135104
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
