Setting it in environment overrides this setting.
The rationale is to avoid introducing warnings like these appeared recently:
zipfile.py:1517: UserWarning: Duplicate name: 'cmd/ar/sc_bulletsandnumberingdialog.png'
(see e.g. https://ci.libreoffice.org/job/gerrit_windows/71910/consoleFull)
Change-Id: I8ae42e039ec3d028c01dbc4bcf422feae9e46271
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100268
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
between data points and displaced data labels of a data series.
Follow-up of the following commits related to the new UNO property
ShowCustomLeaderLines for data labels:
commit e2f4e65a7b
(tdf#134571 chart2, xmloff: add loext:custom-leader-lines)
commit 5d67d70b26
(tdf#134563 Add UNO API for custom leader lines)
Change-Id: Id8a953b16ff737ca924c0c2c3241fba4e3ac904b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102221
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Regression from commit c56bf1479c
(tdf#105330 sw: fix lost cursor on undoing nested table insert,
2019-09-16), the problem was that the change reverted lcl_notifyRow()
back to its original state, because it seemed the conditional
notification is no longer needed. However, this broke the fix for
tdf#37606 (ability to select-all when the doc starts with a table).
Fix the problem by handling the starts-with-table case similar to a
normal table selection, so there is still no need to restore the nested
table visitor code but select-all works nicely with starts-with-table
documents again.
Change-Id: Icb823a39432d1774a63a0c633c172bba827ac76d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102694
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Adds three Windows gb_* variables:
- gb_MSBUILD_CONFIG_AND_PLATFORM can be passed as msbuild flags
- gb_MSBUILD_PLATFORM maps debug / release settings
- gb_MSBUILD_CONFIG maps the CPUTYPE to the default msbuild names
and converts the users in external projects.
Change-Id: Ie9b817721180d78d104db11c44241e4b3e46bba9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102701
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
with tracked changes of table structure (not only cell
text content), where text ranges of redlines aren't
connected to a cell. Support also different table names
of redline text ranges for sure.
Regression from commit 288db6eb47
(tdf#132271 DOCX: import change tracking in floating tables).
Change-Id: I58b1b21c8016d682a292409165991dec2f8cfa3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102655
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
This is basically just some refactoring. Most interestingly the
MacOS used to work with 257 glyphs. I couldn't find any
explaination for the 256 glyph limit. Sadly the PrintFontManager
is out of scope. That needs more inspection.
Change-Id: Ibfa0e905f5efeb7d4a609884d64b4ed2615a9d3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102688
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
Basically implement it the same way then Windows and MacOS.
Change-Id: I643581af49aeb9274505e90e12acbe5bcf0c98fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102687
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Since removed code in the previous commit is primary used in
CreateFontSubset and GetGlyphWidths, you have a high chance, that
the CMAP was already used for displaying a font, so it's already
decoded and can be forwarded. Also the lookup should be faster in
general this way.
Change-Id: Icf4d8a1a84ff6ccdaccb7e870abe5df3837f9541
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102686
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
This introduces a potential performance regression, because
FindCmap works on the existing font tables and just sets up
a lookup function, while ParseCMAP creates some optimized,
in-memory lookup table, which needs a bit more work, but
is faster in its usage, I think. At least the initial usage
is faster the old way, as the CMAPs aren't decoded at all.
As you can see, the old code is just used on Windows and
MacOS / iOS. Deep in the bowels of the PrintFontManager, the
CMAP is also decoded using ParseCMAP...
So I'm not sure this potential regression really exists. Most
fonts will already have a decoded CMAP, so my guess is this
is actually faster in the end. No idea, how to measure.
Change-Id: I52caac1264cd3ff11a2a3fa6e9c800f67f146a79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102685
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Now that GetFontChatMap is a member of PhysicalFontFace, we can
copy the common part of both architectures into a SalGraphics
helper function.
Change-Id: Iad379ea690a1c5346b69b5042188506ccf575cc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102684
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This makes GetFontCapabilities and GetFontChatMap members of the
PhysicalFontFace. These are implemented in all the real font face
classes anyway. Also provide dummies for the PDF buildin fonts.
Change-Id: Icb8cb14480ce1e020977b8f69892095d787982ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102683
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
Regression from commit bb97ecdbcc,
which had dropped storing chart doc (calling its storeOwn) while
loading back in 2012, to avoid performance problems when loading
XLS.
Funnily, in 2013, commit a666862def
was merged, that was expected to solve exactly the same problem as
this change, by calling storeOwn for charts being loaded; while
obviously not fixing the problem properly, it seems to had undone
the effect of the Markus's commit.
The latter commit had a side effect of updating views of modified
charts while exporting them inside storeOwn, which made respective
draw pages to be up-to-date right after loading, including those on
inactive sheets. Now, after this change, this is not so, thus unit
tests' getChartDocFromSheet was made to update the view explicitly.
Unfortunately, it's not yet possible to revert the change from
commit a666862def, because obviously
some dependency grew, which makes e.g. testTdf122594 fail if that
commit is reverted. Given that testTdf122594 has no charts, storing
the modified objects while loading has much wider side effects than
was expected by author of a666862def.
Change-Id: Iee1b9ef6f4d8c2dfa0a49680c5e2b465f1817a59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102534
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Miklos reported a Android configure error, which tried to run
autogen.sh for gb_Side=build, which is correctly forbidden. I
checked all the files timestamps for $(BUILDDIR)/config_host.mk
target - all ok, and somehow missed the JAVA_HOME test...
Since my commit 42aeb9f906
("cross-build: fix Java NI linking"), JAVA_HOME just makes
sense for the build side. So the tests just make sense for the
host side, if there was a --with-jdk-home supplied.
This results in a sensible, empty JAVA_HOME for the host side
and all Java builds I found already override JAVA_HOME with
JAVA_HOME_FOR_BUILD.
Change-Id: I1742a83466af70804f1700a1ca0cb6b6b77a7b12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102676
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Which defines that a data node has text properties as direct formatting,
so autoscale should not happen.
We decide autofit at a shape level, smartart defines custom text props
at a data node level. So take the shape, go to its first presentation
node, get its data node and see if it has custom text props. If not,
continue to scale text down till it fits.
smartart-autofit-sync.pptx is extended to contain a 3rd shape: the first
two have their autofit scaling synchronized, while the 3rd has a fixed
font size of 10pt.
Change-Id: I6caacdaab9a36072b9ad5021bd217c955b09b790
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102689
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
(see Tools->Detective) as plain shapes.
Co-authored-by: Balázs Regényi
Change-Id: I920445637a6be12169ae7d70295e4460d7f9b26b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101845
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
from file managers.
Native text, PDF and image file formats were supported,
but now spreadsheet and DOCX documents, too. The same
feature was already implemented in e.g. Impress.
Note: DOCX files inserted as OLE objects yet, and not
linked files in sections, as ODTs (but it's possible saving
and printing them via Save As option of the local menu
of the OLE object).
Change-Id: Ia2fafe4a0b79dc0c66eaec5ad073c994f98e1345
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102263
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Modified lcl_GetUniqueFlyName() is right now always marks
current fly format name number as used. Yes, this can
lead to some gaps in numbering is some cases, but meanwhile
guarantee that there will be no duplicates if format name
does not match SdrObject name.
Change-Id: If39ed993614ae1665deba21ae8d5e6bd542fb6e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102460
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Check that we get the right bullet character.
Change-Id: I2e6af6940606d3bacc71bcdf485f7c3b6fa7602b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102590
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Long ago, styles were read in starting in slot 1 and
slot 0 was backfilled using the last read rule.
That changed in 8a64144fdd when
stuff started at 0; unfortunately the back filling at 0
code was left in, overwritting level 0.
Remove it, fixing cases which used level 0; in particular
a shift-tab to go up a level ended up with the wrong
style.
Fixes: 8a64144fdd
Change-Id: Ic29f3fca9f1c809de69a1d83fca017bdafdd2447
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102542
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
