this reverts 6c719c1585 "n#615223 local nbyte1
should have been class-level nByte1" which was to fix the use seen
in valgrind og the uninitialized nByte1
So additionally remove the use of the uninit nByte1 entirely
Change-Id: I5b3f4fa00d74e545f207a11a5e90935f14a23a8e
Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
Lots of stuff still either ended up in the wrong place, or was looked up from
the wrong place, or both. Fix most cases.
Change-Id: I06ebbce207c219f3cd82b4387dd9b3fdb83420d4
Git history shows it was like this since first commit (2009-12-15)
Moreover I noticed these lines:
220 if ( mpCGM->pElement->nAspectSourceFlags & ASF_FILLCOLOR )
221 nFillColor = mpCGM->pElement->pFillBundle->GetColor();
222 else
223 nFillColor = mpCGM->pElement->aFillBundle.GetColor();
even if nFillColor can have another value in case below
249 case FIS_GEOPATTERN :
250 {
251 if ( mpCGM->pElement->eTransparency == T_ON )
252 nFillColor = mpCGM->pElement->nAuxiliaryColor;
253 eFS = drawing::FillStyle_NONE;
254 }
this change is still safe since it's just a simplification.
Change-Id: Icf41dbeee6405780483649e0968dd30e8a533882
This enables saving of MS 2007 spreadsheet documents with a password.
The encryption used is the same as used in Office 2007 (however
different than in Office 2010 and 2013 which use "agile" encryption).
Change-Id: I3539e811d95b6f9178246ab269d13bb385a48bd2
Trying to reproduce rhbz#98977, temporarily changing TRANSFORMATION_TIMEOUT_SEC
(filter/source/xsltfilter/XSLTFilter.cxx) to zero, loading a dummy "Microsoft
Excel 2003 XML (.xml)" file shows a "General input/output error" msg box and
"Cancel" leads to a crash due to duplicate calls to m_tcontrol->terminate() from
both XSLTFilter::importer and XSLTFilter::endDocument (both
filter/source/xsltfilter/XSLTFilter.cxx).
Change-Id: Ia103d944f3e1f14ca2cf5552ca3a48348132d38e
The result of osl_getCurrentSecurity () should always be deleted again
with osl_freeSecurityHandle ().
Change-Id: If0991937fcb24207d1f78166f61c4be22d423629
Reviewed-on: https://gerrit.libreoffice.org/4947
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
I deleted TempFile class and changed it to utl::TempFile class
-which in unotools/tempfile.hxx- in the followings: Storage,
StgTmpStrm, SwXMailMerge classes; and RenderAsEMF function.
I modified header in precompiled_sw.hxx.
Change-Id: I3dae5333dc42538e1b905f6a6bbc85534c591dc1
Reviewed-on: https://gerrit.libreoffice.org/4938
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
When a new DffPropertyReader is created and assigned to pSecPropSet
make sure the old one is deleted first.
Change-Id: Idd14fdf4e3a03a625a10a89dde71ad66cbdba792
Reviewed-on: https://gerrit.libreoffice.org/4761
Reviewed-by: Petr Mladek <pmladek@suse.cz>
Tested-by: Petr Mladek <pmladek@suse.cz>
...in files generated by gperf; an alternative could be to use -isystem instead
of -I in gb_Library_use_custom_headers.
Change-Id: I316684ab5342977655a5642903b13e127adaf95c
Ealier version of PDF standard allowed for not embedding the so called
standard PostScript fonts in the PDF files and all PDF readers had to
include them or a "suitable substitute". This behaviour had many issues
and is deprecated for 10 years now. The current version of PDF spec
says:
Beginning with PDF 1.5, the special treatment given to the standard 14
fonts is deprecated. Conforming writers should represent all fonts
using a complete font descriptor. For backwards capability, conforming
readers shall still provide the special treatment identified for the
standard 14 fonts.
This commits removes support for not embedding these fonts, and the, now
redundant, option to embed them.
This has the side effect of elimanating the cause of fdo#66108 and
fdo#41547.
Change-Id: I4f1fc4137a2de7baeef9e504f2e4f84fbec0a491
Reviewed-on: https://gerrit.libreoffice.org/4495
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
