Regression after commit 92e835dbf0
Author Kunal Pawar <hellokunalpawar@gmail.com>
Date Fri Feb 18 19:15:04 2022 +0530
tdf#98705 Replace GetCaseCorrectPathName with GetLongPathNameW
The fix tries to keep the performance improvement, and when the path
exists, it will only call GetLongPathNameW once. Anyway, for unclear
reason, this normalization only happens on long paths.
Change-Id: I1cf9a47dfc35046ec1b5eebbbcaca09edb1c471a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140516
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...similar to 93e234c45c "Fix a misuse of two-
argument std string_view rfind". This one got introduce in
15d8762dd0 "use more string_view in cui". (And if
it wasn't for other bugs elsewhere, this code could be reached e.g. in Writer
with "Tools - Macros - Organize Macros - Basic...", in "Macro From" select "My
Macros - Standard - Module1" and in "Existing Macros in: Module 1" select
"Main", then "Assign...", and this code would have miscomputed aModule as "Main"
rather than as "Module1".)
Change-Id: Id3fd66e0bd252d79af629abbbf1e38b37679de70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140490
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This is how Excel handles these.
At first I was afraid that this would upset LibreOffice users,
but then I realized that equals already is case insensitive,
so this change ought to be more consistent, and thus there should
be fewer outcrys.
Change-Id: Ia3de78d5888672ba8b774866d41ecd65293397c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140484
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
otherwise it won't end up hidden if the "keyboard" tab page is the initial
page, this handler only happens when the user switches tabs.
use the newly added virtual methods to manage this instead
Change-Id: I3eef6b4d7d453a5ec16ec62b2ebb558bd4757caa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140489
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
The problem here was that under IsNewModel tables were
selecting the entire column (including merged cells)
and then using THAT selection to ExpandColumnSelection.
Well, that ends in disaster. Since NewModel already
expands to catch the cells that are contained inside
the selected cells, there is no need to expand
the selection of GetTableCell.
Change-Id: I43089d912cdd17b2599619a43e40fecc2f5dd3b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140455
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
...introduced in 655b6c2f46
"loplugin:stringviewparam". Unlike its O[U]String lastIndexOf(x, n)
counterpart (which looks for the last x whose end position, exclusive, is <= n),
string_view rfind(x, n) looks for the last x whose start position, inclusive, is
<= n. (So here would have left slash unchanged.) (And the seemingly simpler
jvm_dll.rfind('\\', slash - 1)
would fail when slash is zero, as in that case it would call rfind with a second
argument of npos, i.e., search for the last '\\' in the complete jvm_dll.)
Change-Id: I148a5db860d4b9e9d58a4a8847880a7a7020c5a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140486
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
part of the process of hiding the internals of SwPosition
Change-Id: Ie9e74ec299d59458d0fdd99f795dc2b9ff86ed32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140436
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Thanks again to Mike Kaganski for spotting
Change-Id: Ifd8dcf15d7714ebc4f19083fefe0d78d27d46b4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140483
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Map it to vcl::PDFWriter::ComboBoxWidget, which knows that this has list
items + allows free-form user input as well.
PDF 32000-1:2008 Table 230 documents those field flag bits.
Change-Id: Ifb99625c2ab8792b756ad52a3f6d599507c5773f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140480
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Some PDF viewers might use glyph names to guess corresponding character,
and it also makes debugging the PDF output a little bit easier.
Change-Id: Ibe7f28d10814a9deb467129c85fed914fb7b3f9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140465
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
This change extracts the PNG data from the sbix/CBDT tables and embeds
them as PDF Type 3 glyphs. In case the font supports both color layers
and color bitmaps, the color layer take priority.
This also reverts the part of the following commit that allowed bitmap
fonts when creating font subsets because this is not needed now as the
such fonts will now not reach the subsetting code.
commit dcf7792da2
Author: Khaled Hosny <khaledhosny@eglug.org>
Date: Tue Aug 27 15:19:15 2019 +0200
Make Noto Color Emoji font work on Linux
Change-Id: I350ec97956f37ae574956b22712869fd6d1a6990
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140457
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
Without this, it may not actually be there, so interning "" would
use a different string instance, and then comparing with
SharedString::getEmptyString() would actually compare non-equal.
Change-Id: I22660f63aa321e3a8f72cfb96df1db56e08fbb84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140402
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
get length of glyf before std::move it
Change-Id: If2d9a2cc533d65ef4b8e0481cf7db677bf5e4349
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140472
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
* Update dictionaries from branch 'master'
to 9e27d044d98e65f89af8c86df722a77be827bdc8
- Recognise umlauts typed as -e on non DE keyboard
This change helps the spellchecker to find correct words if the misspelling consists of replacement of Umlauts with their vowel+e variants.
The file already contains entries such as "REP ae ä" on line 519 or "REP ss ß" on line 507. This tells the checker to try first replacing ae as ä and see if that works or to try replacing ss with ß and see if that works. This will only succeed if there is a single instance in the word that needs to be replaced.
The word "greetings" typed as "Gruesse" was causing me trouble as it contains both ue and ss next to each other and the REP commands do not catch this.
The MAP command seems to play a somewhat similar role as REP but whereas REP deals typically with "one character mistakes", MAP just defines character sequences that are related in a language specific setting and works with multiple replacements within a single word.
See here for details: https://www.systutorials.com/docs/linux/man/4-hunspell/
In any event, I doubt it can cause harm because the character sequences that I am relating in the MAP commands are actually related in the German language, and furthermore I am not changing any spelling rules, I am just aiding in the search for correct spelling suggestions.
Change-Id: I4683db860467ff6a68e96301c0ed187df1089b3c
Reviewed-on: https://gerrit.libreoffice.org/c/dictionaries/+/136067
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
- expose the combo box case in SwWrtShell::InsertContentControl() as a
new .uno:InsertComboBoxContentControl command
- - add the new uno command to the default & MS-compatible menus
Change-Id: Ifb1a9cede8c219d956ce438119ee789a69507679
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140468
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
...for better gradient visualization, see task
for details.
Change-Id: Idccd569b0e95763f6dbf6ad0a2204b62460c66d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140354
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
that takes a SwPosition and keeps the nNode and nContent fields there in
sync.
this is part of the process of hiding the internals of SwPosition.
Change-Id: I1996e588703ca2400fa84e979c72cc5382e5b700
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140435
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The fact that `SwEditWin::GetSurroundingText` etc.
use an internal-only helper cursor is an implementation
detail and should not result in a11y events getting sent
from LibreOffice to the platform a11y layer.
Therefore, introduce a flag to `SwCursorShell`
that indicates whether or not sending of
accessible cursor events is enabled and set that
to false during the use of the helper cursors.
As described in Sebastian Keller's very
helpful analysis on what was happening on the
gnome-shell magnifier side (s. tdf#149952 comment 11),
sending those a11y events resulted in the
gnome-shell magnifier jumping to the right
when typing empty paragraphs:
> Regarding the issue of jumping to the right, it looks
> like there is a 'object:state-changed:selected' for the
> paragraph when pressing enter multiple times. This causes the
> magnifier to center the entire paragraph, which has the width
> of the entire page according to the extents, so this will be
> further to the right compared to caret.
Change-Id: I514aa2dad5cfffbe5e8d4b7e9d7d383e70470b18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137104
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
part of the process of hiding the internals of SwPosition
Change-Id: Ieaaeafdbef6cdd715d1d8610cf6094d1bbf08b09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140434
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This reverts commit fd2ca96074,
since it causes a regression when copying a chart.
Change-Id: I5d40de6f46b4b3e68531257d27f9a81540a06da4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140427
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
soffice.bin: include/rtl/ustring.hxx:842: sal_Unicode rtl::OUString::operator[](sal_Int32) const: Assert ion `index >= 0 && static_cast<sal_uInt32>(index) < static_cast<sal_uInt32>(getLength())' failed.
when editing a paragraph (line) longer than the first, because the
string was always obtained from the first paragraph but the
position from the current selection.
Also match parentheses in the current paragraph, not somewhere
else in the first paragraph.. still we're matching only within one
paragraph.
Change-Id: I955fd371c1e248ce58735a5b61603bbce6c997db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140446
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Three invalid files are hitting this assert.
They had invalid XML, so I couldn't even
xmllint --format --recover content.xml
Removing the assert - it has outlived its usefulness.
Change-Id: I93d6d6e1d5ce53f9dd1ee46ce3881183993827c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140447
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
The bugdoc has a text frame 42 immediately following a section which
contains a nested table, both inside a table cell 29.
The problem is that with soffice --convert-to pdf, the height of frame
42 ends up as 0, after a single layout action; this does not happen when
loading it from UI.
When the frame 42 is formatted, it calculates the needed height, and
grows, but in SwTextFrame::AdjustFrame() it doesn't fit into its upper
cell frame with a negative nRstHeight at this point, and the text frame
is reduced to height 0.
The odd code in SwContentFrame::MakeAll() exists unchanged since CVS
initial import and is poorly motivated. It is highly suspicious that it
simply grows the upper frame, without invalidating the size of the
current one (which was already shrunk), and/or clearing the
m_bUndersized flag.
If this code is removed, on formatting the next frame 43, it goes up and
formats the cell frame, which grows and at the same time importantly
invalidates the text frame 42, so it will be formatted again and full
height.
At the point when the frame 42 was formatted, its upper cell frame was
size-invalid, so it looks like that will be formatted eventually in any
case and then invalidate 42.
(regression from commit e7874c936d
but unclear why)
Change-Id: I1ac0999a8fda39f7717bc183a10e3b513fbb8911
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140355
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
if we eventually are forced to pick a final paper size which has the
orthogonal orientation than that requested, then swap the orientation of
the jobdata too
and re-init the orientation to defaults in Printer::SetPaperSizeUser
when we set a new user paper size rather than keeping the orig
Change-Id: Ie9e783575734c7f9eec3984efd1357cae5375130
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140358
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
* Update helpcontent2 from branch 'master'
to a9fed471fe915e0ad8053cf21227c5a4d8a31108
- TRUE/FALSE are functions
Samples using them as constants simply don't work
Change-Id: I1cc6199fa418363b3176dd3c2f18d9cc6620957a
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/140385
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
I.e. use "ugly" macros to make code more nice.
Change-Id: I053dd2313c140dbc6b25073d67155a1284c6b310
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140398
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Input data to this function is not required to be sorted, so implementing
this would mean sorting it in opencl, which is not exactly trivial and
not worth the effort. There also exist algorithms that find the median
without sorting an array, but they work by guessing it and looping until
their guess is right, so again, not worth the trouble. I'd say there's
nothing to be gained here from using opencl.
Change-Id: Ic6d6efdfc59b9058bdae50d07d8039db481dfb75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140397
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
These mostly exist in "old" and _new variants which are more or less
the same, sometimes there are minor differences. Keep just the _new
ones, everything still seems to work, all tests pass.
Change-Id: I903ea3f11bad6c5e1301febe03974469eb414368
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140396
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
As one of the code comments said the code used string hashes to represent
strings and this was a broken idea. But the basic idea of that is actually
valid, so just implement that properly and use it only for comparing
strings. See the code comment in opbase.cxx for technical details.
Change-Id: I113d6b4d5e1e78bbe2c05aafc0572605e2595ad8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140395
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This is what core does, it also extends the range (the casting to int
variant limited to the range of the int, which the core variant doesn't).
Change-Id: Ib93bc57b38c0927f9732742d116d0f40700a0abb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140394
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
They are listed in the SC_OPCODE_START_BIN_OP group, but AND(A1:A30)
is fine.
Change-Id: I397d1f8dc6bff450116dd46b6b1da7ffe447efb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140372
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
