Age | Commit message (Collapse) | Author |
|
Change-Id: I107cf27ea36e092ba3be45d255cc8622eb1c726f
|
|
No idea how this ever compiled for me!
Change-Id: I7bfe5df755594448fbe6892873a7cedb2b235d98
|
|
Follow UTR#50 and set vertical direction based on character orientation,
not the resolved script.
Change-Id: I54f047e1720e8e4de14ce16a57e5d2d3f6cd2ca2
|
|
See http://unicode.org/reports/tr50/#vo
ICU does not support getting this property yet, so I stole some (heavily
redacted) Perl script from Mozilla that reads the data file and
generates property tables. The original Mozilla script:
https://dxr.mozilla.org/mozilla-central/source/intl/unicharutil/tools/genUnicodePropertyData.pl
Change-Id: I2800711c3db3564515139227bdbd3b4d732917eb
|
|
Drop useless typedef and use more general nomenclature as I’m going to
extend this in the next commits.
Change-Id: I12aa01fe9f5a6c9aca67f850f36b81661ee14913
|
|
Previously we used a symetric image to test JPEG import. This has
the flaw that we doesn't warn if the orientation of the JPEG
image was not correct. This commit fixes this flaw by making all
test images non-symetrical.
Change-Id: If87d257ae44d85b6a9042d09d62ba785ffc5c426
Reviewed-on: https://gerrit.libreoffice.org/30709
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I8f2963c9b6b1c8717ea4d19453815fffa6e68484
|
|
This way it's a bit smaller for large files and our output is closer to
what Acrobat produces.
Change-Id: Ide5f7b58a74a9d6ad7d806814eb57cb6931023cc
Reviewed-on: https://gerrit.libreoffice.org/30726
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
So that when we have a single signature with ID="Signature2", then we
use "Signature3" for the next ID, not "Signature2". (Acrobat uses that ID
for the first signature.)
Change-Id: I7032fbf014184da2a5be24730a92abc32a9a1258
Reviewed-on: https://gerrit.libreoffice.org/30725
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
In case the input document used a PDF 1.5 xref stream, not an old xref
table, then write that as part of the incremental update. Acrobat seems
to require this.
Change-Id: I9f1f73140c26308f8720aa1ffe1b905d0e60ede0
Reviewed-on: https://gerrit.libreoffice.org/30724
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Normally it's a direct dictionary, but it's OK to have it as a reference, and
then the referenced object is a dictionary.
Change-Id: If09edaf23501883be68148e430c42e721ec68247
Reviewed-on: https://gerrit.libreoffice.org/30719
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Sure, using a namespace means we have to decorate each function with the
XMLSECURITY_DLLPUBLIC, but who cares.
Change-Id: If9a364d1be9c5f4cd02f3f146e8b01bd608b373e
|
|
The password-to-modify misfeature does not actually provide any
security, but it may induce users to re-use passwords, so at least make
it harder to crack the passwords.
Change-Id: I0adf0e8e11b222fc469013e17a2695bd7122ad01
|
|
Given recent elections we need to build a higher wall to keep the
government out of our documents, and we will make the government
pay for it.
These iteration counts were considered appropriate a decade ago.
http://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pkbdf2-sha256
We get similar numbers on SandyBridge-E desktop and Haswell i7-4600U laptop:
* with 10k iterations ~20 msec per derivation
* with 100k iterations ~195 msec per derivation
* with 150k iterations ~290 msec per derivation
We can't go too high though because in ODF every package stream gets
its own derived key with a different salt, so a document with embedded
images may need a lot of these.
Change-Id: I6894e71ed399f8c340eff97a9191c8d8419789a6
|
|
Change-Id: Id9daf4f5e3208eca8d3d845983b58ab056557621
|
|
Change-Id: Ie00840e0b8cff747e131b6bc9def0ddaf57edea7
|
|
Change-Id: I0970a86d65aa905cbd02d892be08de8962731e8b
|
|
Change-Id: Ica8a5a2f6046eabf4fa8081db0aa50ade23b5b3a
|
|
Change-Id: I2ad83dec1e409cd7b12009c31fbe4cc9d73223c1
|
|
Seen a Jenkins build fail in JunitTest_framework_complex as below, and the only
remotely plausible scenario I can think of is that a call from
Frame::contextChanged -> ToolBarManager::frameAction started the timer after
Frame::close -> dispose -> ... -> ToolBarManager::dispose had been called but
before Frame::close -> dispose -> ... -> ~ToolBarManager had been called. (And
tracing the calls to Frame member functions, there indeed appear to be call
patterns during JunitTest_framework_complex where Frame::contextChanged is
called from within Frame::close -> dispose -> ...)
Any other calls to m_aAsyncUpdateControllersTimer.Start() in ToolBarManager
appear to already check for !m_bDisposed.
<http://ci.libreoffice.org/job/lo_tb_master_linux_dbg/9049/console>:
> #7 0x00002b2653546566 in __assert_fail_base () at /lib64/libc.so.6
> #8 0x00002b2653546612 in () at /lib64/libc.so.6
> #9 0x00002b2676f23777 in framework::ToolBarManager::~ToolBarManager() (this=0x3a48710, __in_chrg=<optimized out>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/framework/source/uielement/toolbarmanager.cxx:198
> #10 0x00002b2676f23978 in framework::ToolBarManager::~ToolBarManager() (this=0x3a48710, __in_chrg=<optimized out>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/framework/source/uielement/toolbarmanager.cxx:201
> #11 0x00002b2655fd5328 in cppu::OWeakObject::release() (this=0x3a48710) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppuhelper/source/weak.cxx:233
> #12 0x00002b2676ec7138 in cppu::WeakImplHelper<com::sun::star::frame::XFrameActionListener, com::sun::star::lang::XComponent, com::sun::star::ui::XUIConfigurationListener>::release() (this=0x3a48710) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/cppuhelper/implbase.hxx:113
> #13 0x00002b2655ef353a in com::sun::star::uno::cpp_release(void*) (pCppI=0x3a48738) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/com/sun/star/uno/genfunc.hxx:48
> #14 0x00002b2655c5d4ab in cppu::idestructElements(void*, _typelib_TypeDescriptionReference*, int, int, void (*)(void*)) (pElements=0x32c5a28, pElementType=0x1670d90, nStartIndex=0, nStopIndex=5, release=0x2b2655ef3517 <com::sun::star::uno::cpp_release(void*)>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/uno/destr.hxx:238
> p = 0x3a48738
> nPos = 4
> #15 0x00002b2655c5d64f in cppu::idestroySequence(_sal_Sequence*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*)) (pSeq=0x32c5a20, pType=0x24a6cf0, pTypeDescr=0x24a6cf0, release=0x2b2655ef3517 <com::sun::star::uno::cpp_release(void*)>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/uno/destr.hxx:284
> __PRETTY_FUNCTION__ = "void cppu::idestroySequence(uno_Sequence*, typelib_TypeDescriptionReference*, typelib_TypeDescription*, uno_ReleaseFunc)"
> #16 0x00002b2655c8952f in uno_type_sequence_destroy(uno_Sequence*, typelib_TypeDescriptionReference*, uno_ReleaseFunc) (sequence=0x32c5a20, type=0x24a6cf0, release=0x2b2655ef3517 <com::sun::star::uno::cpp_release(void*)>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/uno/sequence.cxx:916
> #17 0x00002b2655f31ba6 in com::sun::star::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::uno::XInterface> >::~Sequence() (this=0x2679070, __in_chrg=<optimized out>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/com/sun/star/uno/Sequence.hxx:113
> rType = invalid uno::Type
> #18 0x00002b2655f2ef92 in cppu::OInterfaceIteratorHelper::~OInterfaceIteratorHelper() (this=0x2b26785beaf0, __in_chrg=<optimized out>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppuhelper/source/interfacecontainer.cxx:103
> bShared = false
> #19 0x00002b2655f2fb98 in cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const&) (this=0x32bd280, rEvt=...) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppuhelper/source/interfacecontainer.cxx:288
> aGuard = {pT = 0x0}
> aIt = {rCont = @0x32bd280, bIsList = 1 '\001', aData = {pAsSequence = 0x2679070, pAsInterface = 0x2679070}, nRemain = 0}
> #20 0x00002b2655f308d7 in cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const&) (this=0x38bc030, rEvt=...) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppuhelper/source/interfacecontainer.cxx:477
> i = 0
> nSize = 3
> ppListenerContainers = std::unique_ptr<cppu::OInterfaceContainerHelper *> containing 0x2f7c650
> #21 0x00002b2676e37180 in (anonymous namespace)::Frame::disposing() (this=0x38bbf30) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/framework/source/services/frame.cxx:2242
> parent = uno::Reference to (com::sun::star::uno::XInterface *) 0x2b26785beca0
> xThis = uno::Reference to ((anonymous namespace)::Frame *) 0x38bbfa0
> layoutMgr = uno::Reference to (framework::LayoutManager *) 0x2fa5190
> aEvent = {Source = uno::Reference to ((anonymous namespace)::Frame *) 0x38bbfa0}
> xDisposableCtrl = uno::Reference to (com::sun::star::uno::XInterface *) 0x2b26785beca0
> xDisposableComp = uno::Reference to (com::sun::star::uno::XInterface *) 0x2b2676e34200 <(anonymous namespace)::Frame::isActive()+160>
> disp = 0x2f7c650
> xDispatchHelper = uno::Reference to (com::sun::star::uno::XInterface *) 0x2b26785bec80
> old = Application::Off
> contWin = uno::Reference to (com::sun::star::uno::XInterface *) 0x2b26785bf050
> #22 0x00002b2655f2b262 in cppu::WeakComponentImplHelperBase::dispose() (this=0x38bbf30) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppuhelper/source/implbase.cxx:107
> aEvt = {Source = uno::Reference to ((anonymous namespace)::Frame *) 0x38bbf30}
> aGuard2 = {pT = 0x39553a0}
> aGuard = {pT = 0x0}
> #23 0x00002b2676e3f0a6 in cppu::PartialWeakComponentImplHelper<com::sun::star::lang::XServiceInfo, com::sun::star::frame::XFrame2, com::sun::star::awt::XWindowListener, com::sun::star::awt::XTopWindowListener, com::sun::star::awt::XFocusListener, com::sun::star::document::XActionLockable, com::sun::star::util::XCloseable, com::sun::star::frame::XComponentLoader, com::sun::star::frame::XTitle, com::sun::star::frame::XTitleChangeBroadcaster, com::sun::star::beans::XPropertySet, com::sun::star::beans::XPropertySetInfo>::dispose() (this=0x38bbf30) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/cppuhelper/compbase.hxx:94
> #24 0x00002b2676e34edb in (anonymous namespace)::Frame::close(sal_Bool) (this=0x38bbf30, bDeliverOwnership=0 '\000') at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/framework/source/services/frame.cxx:1829
> xSelfHold = uno::Reference to ((anonymous namespace)::Frame *) 0x38bbf30
> aSource = {Source = uno::Reference to ((anonymous namespace)::Frame *) 0x38bbf30}
> pContainer = 0x33c4ba0
> aWriteLock = {m_bCleared = true, m_solarMutex = @0x16529c0}
> #25 0x00002b26752971a1 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) (pThis=0x38bbfd0, nVtableIndex=5, pRegisterReturn=0x0, pReturnTypeRef=0x165a1b0, bSimpleReturn=true, pStack=0x2b26785bf1a0, nStack=0, pGPR=0x2b26785bf2c0, pFPR=0x2b26785bf2f0) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:133
> data = {pMethod = 47444203360446, pStack = 0x2b26785bf1a0, nStack = 0, pGPR = 0x2b26785bf2c0, pFPR = 0x2b26785bf2f0, rax = 47444228043088, rdx = 47444228043040, xmm0 = 4.9549649932863477e-314, xmm1 = 2.3440563169523938e-310}
> pMethod = 47444209328504
> #26 0x00002b26752960bc in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void*, void**, uno_Any**) (pThis=0x2f330e0, aVtableSlot=..., pReturnTypeRef=0x165a1b0, nParams=1, pParams=0x3200050, pUnoReturn=0x0, pUnoArgs=0x3a70260, ppUnoExc=0x2b26785bf478) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:245
> pStack = 0x2b26785bf1a0
> pFPR = {2.34405631697769e-310, 2.3440546323697648e-310, 1.0609978954826362e-313, 2.3440563169796168e-310, 2.5903774855902888e-316, -9.6283901862001054e-07, 2.3440563169800615e-310, 0}
> __PRETTY_FUNCTION__ = "void cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void*, void**, uno_Any**)"
> pCppArgs = 0x2b26785bf170
> pStackStart = 0x2b26785bf1a0
> pGPR = {59490256, 0, 47444228043568, 47444174450194, 0, 52429824}
> nTempIndices = 0
> nFPR = 0
> pAdjustedThisPtr = 0x38bbfd0
> ppTempParamTypeDescr = 0x2b26785bf180
> nGPR = 2
> pReturnTypeDescr = 0x165a1b0
> pCppReturn = 0x0
> bSimpleReturn = true
> pTempIndices = 0x2b26785bf178
> #27 0x00002b2675296ada in bridges::cpp_uno::shared::unoInterfaceProxyDispatch(_uno_Interface*, _typelib_TypeDescription const*, void*, void**, _uno_Any**) (pUnoI=0x2f330e0, pMemberDescr=0x3200400, pReturn=0x0, pArgs=0x3a70260, ppException=0x2b26785bf478) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:436
> nMemberPos = 5
> aVtableSlot = {offset = 0, index = 5}
> pThis = 0x2f330e0
> pTypeDescr = 0x2590e40
> __PRETTY_FUNCTION__ = "void bridges::cpp_uno::shared::unoInterfaceProxyDispatch(uno_Interface*, const typelib_TypeDescription*, void*, void**, uno_Any**)"
> #28 0x00002b267653517a in binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) const (this=0x3aba970, returnValue=0x2b26785bf8a0, outArguments=0x2b26785bf920) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/binaryurp/source/incomingrequest.cxx:242
> exc = <error reading variable: Cannot access memory at address 0x3aba87808>
> pexc = 0x2b26785bf4a0
> retType = {_pTypeDescr = 0x165a1b0}
> nSize = 0
> retBuf = std::__debug::vector of length 0, capacity 0
> outBufs = empty std::__debug::list
> args = std::__debug::vector of length 1, capacity 1 = {0x3a331c0}
> __PRETTY_FUNCTION__ = "bool binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny>*) const"
> isExc = false
> #29 0x00002b2676533f7a in binaryurp::IncomingRequest::execute() const (this=0x3aba970) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/binaryurp/source/incomingrequest.cxx:77
> resetCc = true
> oldCc = {m_pUnoI = 0x0}
> ret = {data_ = _uno_Any(void)}
> outArgs = std::__debug::vector of length 0, capacity 0
> isExc = false
> #30 0x00002b2676554a88 in binaryurp::(anonymous namespace)::request(void*) (pThreadSpecificData=0x3aba970) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/binaryurp/source/reader.cxx:85
> __PRETTY_FUNCTION__ = "void binaryurp::{anonymous}::request(void*)"
> #31 0x00002b2655c27f0b in cppu_threadpool::JobQueue::enter(long, bool) (this=0x398ea80, nDisposeId=39254816, bReturnWhenNoJob=true) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/threadpool/jobqueue.cxx:107
> guard = {pT = 0x398ea80}
> job = {pThreadSpecificData = 0x3aba970, doRequest = 0x2b2676554a1f <binaryurp::(anonymous namespace)::request(void*)>}
> pReturn = 0x0
> #32 0x00002b2655c2cb57 in cppu_threadpool::ORequestThread::run() (this=0x256fb20) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/threadpool/thread.cxx:168
> #33 0x00002b2655c2d04d in osl::threadFunc(void*) (param=0x256fb30) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/osl/thread.hxx:185
> pObj = 0x256fb30
> #34 0x00002b2652f08340 in osl_thread_start_Impl(void*) (pData=0x2570ac0) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/sal/osl/unx/thread.cxx:240
> terminate = false
> pImpl = 0x2570ac0
> __PRETTY_FUNCTION__ = "void* osl_thread_start_Impl(void*)"
> #35 0x00002b26538e1dc5 in start_thread () at /lib64/libpthread.so.0
> #36 0x00002b265360eced in clone () at /lib64/libc.so.6
Change-Id: I27e15a72f6b96484cb45928eaabae589cf9d7ed7
|
|
Normally it's a direct array, but it's OK to have it as a reference, and
then the referenced object is an array.
Change-Id: I191150632c2d8317ee6fd8c8169a90996298faa4
Reviewed-on: https://gerrit.libreoffice.org/30718
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
New behavior of format # ?/??? gives for 3.5
3 1/2
instead of
3 1/ 2
Change-Id: I87f4a71fb13d8424017d557213bb4d279de28af5
Reviewed-on: https://gerrit.libreoffice.org/30167
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I0adf7d97f297a8fe1003c8e4cb9a08c9070ed92e
Reviewed-on: https://gerrit.libreoffice.org/30170
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Ibb408af7f989bf35faf13aa871917e7f4cb2aa6f
|
|
Change-Id: Ie167e5e5e953c3e8064b8e128d52f6aa6740575b
|
|
Moved the "Check for Updates", and "Add" buttons
to the new row, and started moving the buttons
from the ExtBoxWithBtns_Impl to the new row.
Needed to create new public methods to be able
to update button states of ExtMgrDialog from
within the ExtBoxWithBtns_Impl class.
Change-Id: Iea784d0b7237da3f8aa05862dbf1faf5acf98655
Reviewed-on: https://gerrit.libreoffice.org/30560
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
We don't need to read buffer in reverse scanline order if image
is bottom-up. This is handled by CopyScanline already.
Change-Id: Ibb20978c01115743de8a457e56003d28ef6dd6d9
Reviewed-on: https://gerrit.libreoffice.org/30710
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
this has begun crashing since...
commit 8f2dd1df1d6cc94ebbc1149de72bc6d6dffa6533
Author: Khaled Hosny <khaledhosny@eglug.org>
Date: Wed Nov 2 23:52:06 2016 +0200
"Enable the new text layout engine by default"
but its presumably blameless
Change-Id: I5d9bfcd3277ce6b71dce8dced6947ab38b12f148
|
|
VclPtr returned from CreatePasswordToOpenModifyDialog implicitly
converts to plain pointer then deletes the dialog.
(regression from some vclptr refactoring)
Change-Id: I4ccdeabcd6ee718104c0f7f65d67a20ce2c70ca3
|
|
Hooked up the tree control to do explicit handling of accelerator key
input.
Change-Id: I8b47fc2d651f7db2549c73c5314fbc4a7f4efecc
Reviewed-on: https://gerrit.libreoffice.org/30694
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
This reverts commit 0e0e3ea312dc09de6726318c3579671fec7de7ee.
and fixes the call to o3tl::sorted_vector::erase that causes a crash.
Change-Id: Ic8ef07eb045a63dc8eaaa33886895f1d8f73098c
Reviewed-on: https://gerrit.libreoffice.org/30715
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
of Elements window.
Change-Id: I221dacad297c7713f9cdde6d8ffdecf3caa2c3bd
Reviewed-on: https://gerrit.libreoffice.org/30714
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>
|
|
And a few more similar nitpicks.
Change-Id: Iac343800171658a9623bcc4d5b7aadaae56830ad
|
|
We can use a bit more RAM for graphics than we currently do, even on 32
bits, which should improve interactive performance as there will be less
swapping of bitmap data and re-parsing of SVGs.
Note that currently the value is effectively multiplied by 2, as the
limit is stored in GraphicCache::mnMaxDisplaySize, but there are 2
independent "counters" GraphicCache::mnUsedDisplaySize and
GraphicManager::mnUsedSize that are both checked against the same limit.
Change-Id: I4e33030af7dcd953c35672f80599188a1fbc4453
|
|
Change-Id: I8a36234068ce0818b7baaa3b6c68d789753db6de
Reviewed-on: https://gerrit.libreoffice.org/30711
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
(A related option would be to make those subclasses derive privately from Pair,
but there are a few places that generically operate on any Pair instances, like
Pair::Read/WritePair or SvxShape::ForceMetricToItemPoolMetric/100th_mm.)
Change-Id: I6c638fe65ee5684593fdeab29b144f547e173f4e
|
|
Change-Id: If844c07d0d50d1bb9b0a1877c0fde4a198bcf781
|
|
Change-Id: I6087a3eff46926646ac1637615a0af30b38956a4
Reviewed-on: https://gerrit.libreoffice.org/30712
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
since...
commit 3a543f1f57aed3beba8879ed46e1f92f657151cb
Date: Mon Oct 10 00:54:00 2016 +0200
Validate Kashida positions in CommonSalLayout
Currently checks only for ligatures, but that is a big improvement over
al code that didn’t do any validation except on Windows.
Change-Id: I0da70d274a2e532d1ce7e7817bddbeca03893763
|
|
Change-Id: Ic7fe13651e18b4eec90ef3fd8d7aab81197e0f39
Reviewed-on: https://gerrit.libreoffice.org/30707
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit c0c69ccd2aac45e4cca0de7d4deaa6d02ec27f4d.
because soffice --headless --convert-to odp ooo75571-1.odp crashes
after this change
|
|
Some intel drivers crash when areaScale shader with "large" array
is used. This adds a "reduced register" version of the areaScale
shader. We still use the first version of the shader for other
drivers and switch between the 2 implementations with a runtime
detection.
Change-Id: I1860f898c03b40a600eb1b41f7262719382a7171
Reviewed-on: https://gerrit.libreoffice.org/30571
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
since
commit 4bcf1872bbe9db1388769485a7e4c0cbcce3d53c
Date: Thu Oct 13 23:43:41 2016 +0200
chartx: fix sparse chart import
because
- Matrix< Any > aMatrix( rDataSeq.maData.size(), 1 );
+ Matrix< Any > aMatrix( rDataSeq.mnPointCount, 1 );
where rDataSeq.mnPointCount is -1
Change-Id: I4bb4805dd81a342d4c0ce24e3240154daf53b452
|
|
This reverts commit 81e3f5f2fdc9c573c83a37009080e4bb974c7955; had failed to
notice that there are already (Scheduler const & overloads of) copy member
functions (which MSVC complains about, but Clang didn't).
|
|
since we only care about appending to this container, and then
traversing it (normally once). So reduce the re-allocations that
std::vector requires
Change-Id: I206a7b82d9eefc1fa3762c4a03e7b5e21136951f
Reviewed-on: https://gerrit.libreoffice.org/30706
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaabc92061a1a49720f473d35251d892dd4b4f756
|
|
So we don't have to specify the source and destination type as often.
Change-Id: Id9e286417a1cb246d163cbc3c536b231a4a92624
Reviewed-on: https://gerrit.libreoffice.org/30700
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9ad8c68c1f0c72d0f985d6c0a3167a775d481a2c
Reviewed-on: https://gerrit.libreoffice.org/30696
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Caused by a bug in Glade.
Change-Id: I8acc923093f7ef1e8a2a5831bc96c63e4c7f0341
|
|
At least on my macOS 10.12.1, PTHREAD_STACK_MIN is 8192 (so stacksize was
substantially smaller than 12MB), and without this change there were randomly
looking failures in e.g. JunitTest_chart2_unoapi with a -fsanitize=address
build.
Change-Id: Icfe989a0e5097a9a0ae76c6e0f6ffcca18271245
|