Age | Commit message (Collapse) | Author |
|
...after a692cdf779dc998f58ebf9e9f84f22edf7dbe421 "LOK: tilebench improvements"
Change-Id: Ic19c97ab381dc339270b8d7072458b57755b5e0d
|
|
* Arguments for max number of parts and tiles to render (optional).
+ Automatic estimation of maximum tiles to render based on max parts
for Writer docs, since there is only 1 part, this caps the number
of pages to render, similar to other doc types.
* Fixed rendering of Writer documents over and over (as many times as pages).
+ Writer has a single part, unlike other doc types.
+ No point in rendering the whole document in writer to a single tile,
since that's completely unrealistic and impractical (it takes
forever for large docs and artificially spikes the memory).
* Rendering starts at the current part and not the first.
+ This gives the spreadsheet of interest priority (if saved as visible).
* The tile size is now more realistic as we use the same dimensions
as the Online client does.
* When rendering tiles at scale, we use the same dimensions as the
Online client rather than splitting the width by 4, for realism.
* Rendering of tiles is done rows-first, rather than columns-first,
which is similar to what the Online client does, which is more
cache friendly, therefore more realistic.
* Enabled compiling of tilebench when GTK3 is disabled, which
was erroneous, since tilebench doesn't have any dependency on GTK.
+ Now it's possible to compile with local Cairo/Pixman libs.
Reviewed-on: https://gerrit.libreoffice.org/44936
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 7db98521548de9eab955ee25a5aacaaef42df323)
Change-Id: I6ad2e97f39572778dd7d0c12d14550841c1d6963
Reviewed-on: https://gerrit.libreoffice.org/46984
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
Includes these fonts
* Amiri
* KACSTOffice, KACSTBook
* Reem Kufi
* Scheherazade
Change-Id: I2071c4c379b2dc88a205e2c284ae0a65cfdc76c9
Reviewed-on: https://gerrit.libreoffice.org/46624
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>
|
|
This reverts commit 111db5b992ae5870e76313f76e633a4edcccf010.
Change-Id: I1138592ab54865f4c2ac4599fab572c5666bf723
Reviewed-on: https://gerrit.libreoffice.org/46864
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
still not ready after all
This reverts commit 6fc7f85de7f0bfa8ee36f867e321a8816ad1e385.
|
|
Change-Id: I03a61421c477642548d9814610faeb570bd34c8d
Reviewed-on: https://gerrit.libreoffice.org/45970
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
... in InstallUISequense.
Use --with-vcredist-dir to point to a directory with vc_redist.x64.exe
and/or vc_redist.x86.exe. Use --without-vcredist-dir (or
--with-vcredist-dir=no) if you don't want to ship it as part of
installer and want to silence the configure warning.
VCRedist 2015 version 14.0.24215.1 is available at
https://www.microsoft.com/en-us/download/details.aspx?id=53840
Since VisualStudio 2015, VC redist merge module that we used before
started to work differently: it installs the UCRT only on WinXP,
but not on later OSes (Vista to 8.1) which may lack the UCRT (Win10
has it out of the box). The merge module only installs VCRuntime on
those systems, which still leaves us with "api-ms-*.dll is missing"
problem.
(https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
gives more information on VCRedist refactoring background.)
Since commit 71d9a61302e65fe091cf70c13fa72b3df09b7e3a, we use a
workaround described at the page mentioned above as "App-local
deployment of the Universal CRT". We just copy all UCRT DLLs to
LibreOffice/program. This has a drawback though, that our UCRT
is not updated by Windows Update, so users would rely on LibreOffice
updates in case of some vulnerabilities in UCRT (and they could
even not realize they have that problem).
MS recommends to install UCRT using EXEs they provide from their
site. The EXEs install both VCRuntimes and UCRTs, along with
required patches, for all Windows versions (Windows XP through
Windows 10, where they only install VCRuntimes); the installed
libraries are managed by system's update mechanism. But those EXEs
cannot be used in MSI custom actions inside InstallExecuteSequence,
because they use MSI themselves.
So this patch integrates the vc_redist.xXX.exe into MSI binary
table, and uses custom action to run the EXE after ExecuteAction
in InstallUISequence. This will show the user a VCRedist install
window after the main LibreOffice installation finishes; no user
interaction is required (except for one additional UAC request),
and errors are ignored.
Since this installation takes care of both VCRuntime and UCRT,
we can ultimately drop both the app-local workaround, and
vcredist merge module (so VCRuntime would also be updated by
system). The former is done here: this reverts commit
71d9a61302e65fe091cf70c13fa72b3df09b7e3a.
This approach has its drawback: if one wants to use unattended
installation (without UI; one example is deployment using
ActiveDirectory GPO), then InstallUISequence is not run, and so
VCRedist isn't installed. In this case, one should install
VCRedist separately. Supposedly this should not be huge problem,
because this is the case for many existing applications that need
separate VCRedist deployment in these scenarios, and unattended
installation is advanced stuff that requires prepared user. A
notice would be required in release notes and FAQ, though.
Change-Id: Ia6a16be60af8a08f41ea7c3dbd457d8f89006006
Reviewed-on: https://gerrit.libreoffice.org/46356
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Includes these fonts
* Alef
* David CLM
* David Libre
* Frank Ruehl CLM
* Frank Ruhl Hofshi
* Miriam CLM
* Miriam Libre
* Miriam Mono CLM
* Nachlieli CLM
* Rubik
Change-Id: Ib16a30c1f5b8fae372b3f9fc3f6de8a3be55bc85
Reviewed-on: https://gerrit.libreoffice.org/45101
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Iac1d572f19372465e9cc369454480d9b621bcd66
Reviewed-on: https://gerrit.libreoffice.org/45169
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
|
|
Change-Id: I14a1f496dfc94bf678112d67f63a2c0101013472
Reviewed-on: https://gerrit.libreoffice.org/45815
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I036538ab9df3dc3f9e3ace9df6b3ed89f6bb75b2
|
|
Change-Id: I4debf079be228e5ce5fae5f1a153f78800407a59
|
|
Change-Id: I3b13e6e29a0436ce18532ab4ef131229aa640d9b
|
|
Change-Id: If508e804da7ec945deb1034a797d3a11a7a2ca00
Reviewed-on: https://gerrit.libreoffice.org/45684
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I50495496914929f9279a455d1acbffab833bf3f5
Reviewed-on: https://gerrit.libreoffice.org/45482
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Icce1317dc3ccfb598ce07ee61eddd873f1f98222
Reviewed-on: https://gerrit.libreoffice.org/45481
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib9a3d8a97fbb6281e8ac3ac2cf6c52cf6819304d
Reviewed-on: https://gerrit.libreoffice.org/45216
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I867d9aa37f876532dd67dadff7cd76f6e35868ba
Reviewed-on: https://gerrit.libreoffice.org/44912
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Includes the regular, italic, bold and bold italic for
* Noto Sans, Noto Serif
Includes the regular and bold for
* Noto Kufi Arabic, Noto Naskh Arabic
* Noto Sans Armenian, Noto Serif Armenian
* Noto Sans Georgian, Noto Serif Georgian
* Noto Sans Hebrew, Noto Serif Hebrew
* Noto Sans Lao, Noto Serif Lao
Includes the regular and bold for
* Noto Mono
* Noto Sans Lisu
Change-Id: I2a423b7cac031e2e899df22ad902bd09d1da250d
Reviewed-on: https://gerrit.libreoffice.org/44128
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
|
|
Change-Id: I6f35cd5696ce6321ce5a729ffb9db9fdecfa61ac
Reviewed-on: https://gerrit.libreoffice.org/44526
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I74ab2c0d36b619fa3b7ed6d52129264930ea9553
Reviewed-on: https://gerrit.libreoffice.org/44368
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I11838f35c9c8ae5d754b129ac0fb30a2ca2b0ab2
Reviewed-on: https://gerrit.libreoffice.org/44201
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Move out of unx, as this will eventually compile on other
OS platforms. At least currently it doesn't contain platform
dependant code.
Change-Id: Iea0bebf574201881ea158381fe7ba8af2a9a6488
|
|
Something that compiles, basically just interface stubs.
All used Svp classes don't use any cairo.
Change-Id: I9a8858c930989438cc2a3f3346c01a7abc579d62
|
|
Change-Id: I7f57ad4f4294df43c3b9c8b3e6deb1641b102637
Reviewed-on: https://gerrit.libreoffice.org/44056
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
the universal crts redistributables are available as part of the Windows
10 SDK. Point to the dir (or a copy of the dir) using --with-ucrt-dir
Use --without-ucrt-dir (or --with-ucrt-dir=no) if you don't want to ship
them as part of LO and are annoyed by the configure warning.
Change-Id: I5487e3f6e583222fa053b2fc03176f061d57746c
Reviewed-on: https://gerrit.libreoffice.org/44074
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: Icd26ad96c0337844ef1463dabfbe791caa00dd2d
Reviewed-on: https://gerrit.libreoffice.org/43972
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
..."Install fc_local.conf only where used"
Change-Id: I3c10a77f37add8731d9844566c4ba364b34d8da1
|
|
Change-Id: Ib6c439fa8db7de0544c8ee3340c07a40bf10bcb6
Reviewed-on: https://gerrit.libreoffice.org/42582
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
At least for me on Linux since LO 5.3, 'soffice
sw/qa/extras/rtfexport/data/fdo72031.rtf' shows "Å" (rendered in "DejaVu Sans")
instead of "⊕" (rendered in "Standard Symbols L"). That's presumably because
47ea13ef8dc8ab9aeded6121845e3ebd1d28b292 "Kill the old Unix layout engines"
removed support for Type 1 fonts (see "Ignore Type 1 fonts" in
FontCfgWrapper::addFontSet, vcl/unx/generic/fontmanager/fontconfig.cxx), and my
(Fedora 25) /usr/share/fonts/default/Type1/s050000l.pfb "Standard Symbols L" is
a Type 1 font. So we fell back to fontconfig's generic (weak) suggestion of
"DejaVu Sans" as a substitute for "Symbol".
So extend our fc_local.conf to suggest our "OpenSymbol" as a substitute for
"Symbol".
As that fc_local.conf was originally brought along by --with-fonts, which is
enabled by default but can be disabled, compilation of fc_local.conf from the
various snippets is moved to postprocess.
macOS and Windows were never affected, as they both come with a "Symbol" font
installed in the system. (And we don't install fc_local.conf on Windows at
all.)
Change-Id: I8d6d87f24974577fd66f5f3989f606237ebb3d75
Reviewed-on: https://gerrit.libreoffice.org/42670
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3cc5a0d8bb24dd33b63ed82866a4acfb7a2dd043
Reviewed-on: https://gerrit.libreoffice.org/42459
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ifdc71fc4a1defbd5c07b93c844a8ccaa055969aa
Reviewed-on: https://gerrit.libreoffice.org/42451
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3e7edb5319ab2e2ec316204b917a7e29c1791b5b
|
|
Change-Id: I7436edc85f87d1f68b50d39bf29564ff498c9ab9
|
|
this was meant to go to a feature branch *sigh it must be Friday
|
|
this is largely based on jmux's work
Change-Id: I5897f3ecb90f83a29e0824bfe7a0ea875347e360
|
|
Change-Id: I46272f8a0b35776b9d14f72b1720e951458ab208
|
|
Change-Id: Ia0c00f6f978428d68b3c53051e26e1913b207dbe
|
|
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
|
|
Similar to the calc one. As a first step the Driver and the Connection
interfaces are implemented, though the later has some stubs.
Change-Id: Id043f7742fdb2006d4f88526ef4d055a6d8dee82
Reviewed-on: https://gerrit.libreoffice.org/40033
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
First steps to organize an importer that can read/interpret
wmf/emf/emf+ and deliver a primitive representation for
the content by parsing it. Use the same mechanisms as
already applied for Svg, so to reuse abilities to keep
original binary data to allow save again and embedding in
files and have an implemented replacement bitmap based
representation. For this, unify the used helper classes
to handle more than just Svg. For 1st try, add test code
and static bool switches
Change-Id: I6e0a82943541d811a8f8d65a84115569fcd8cee7
|
|
The only remaining difference is that in the system-xmlsec case we work
with the default key manager, not with the one that's only added by our
xmlsec patches.
This works for me for the uses I know of (see
<https://lists.freedesktop.org/archives/libreoffice/2017-February/076947.html>
for the motivation): signing and verifying of different signatures (bad
signature, good with non-trusted CA, good with trusted CA) with
software-based certificates all behave as expected.
Change-Id: If3f3e2b8373ab7397db3f98070a5a2ce51fa7c06
Reviewed-on: https://gerrit.libreoffice.org/39075
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
removed with 06d7dbb3568889aa50f46d6307a39fa53a17313b
Change-Id: I7e01cc1f3551cd18c8fe09e908b6dbab75e2ae2d
|
|
This used to require extra SDKs in days of yore but now just always build
those libraries on WNT.
Change-Id: I92c0a35917df42e136c022c762f0333f657a9ec6
|
|
It has ~no users, can't even be built on modern Linuxes, and it annoys
folks who want to refactor VCL.
Per ESC decision from 2017-06-08, remove --enable-tde and --enable-tdeab.
Change-Id: I51ce4786f29f8fcac2e2bb2a654c41fbfbbd8afd
Reviewed-on: https://gerrit.libreoffice.org/38718
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
... and add BUILD_X64 conditional.
Change-Id: Id512368dfd9dece583ead5aae1924db96f8a2a40
Reviewed-on: https://gerrit.libreoffice.org/38366
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ic9ba37af508eabce528ea57ae5839b1cd603b3e1
|
|
Change-Id: I96baefdb6511f4bd632a0044b26074834615bc57
|
|
Change-Id: Idc1d89a46031ae4d2151d96cc25e48945878fb03
|
|
This is quite confusing: the gb_Helper_register_packages_for_install
odk_headers does not actually use the Package odk_headers, but the
PackageSet odk_headers, because the name is the same and the PackageSet
directory comes first in the search path.
This means that the Package odk_headers_generated is installed despite
there being no obvious reason why.
The PackageSet doesn't provide much value here, so just remove it.
Change-Id: I564f3b9fc6acaabe700328bc8c3db70c3b2de0cd
|