Change-Id: I2acc5cd6a57bb6a18f3f20177b3bcf2b8469a834
Reviewed-on: https://gerrit.libreoffice.org/14272Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
Tested-by: Lionel Elie Mamane <lionel@mamane.lu>

Put the whole non-DESKTOP case in #if 0 for now. Unclear what we
actualy need to do there.

Change-Id: I89e71e03ede5175fabe1df949b8d3200f64757a0

Change-Id: Ibfa00b98bde90e1a84e19637179be83449b7743d

Change-Id: Ia6494c611e6596fa4811c2751bb96294a3950f17

Change-Id: Iabfe272e95e4f3517f3072dd6c36b8889c2fdbd1

==1739==    by 0x7A93F1C: SfxUInt16Item::Clone(SfxItemPool*) const (in core/instdir/program/libsvllo.so)
==1739==    by 0x7047E11: SfxShell::PutItem(SfxPoolItem const&) (shell.cxx:196)
==1739==    by 0x27FCA298: SdModule::GetSdOptions(DocumentType) (sdmod.cxx:172)

none of the other uses of pCache->SetState clone, and I don't see why this one
does.

Change-Id: I7d3cf6969c433c890776dfbcc1dc57d72420b6e2

Change-Id: I69d52554b531dab6fc12ffe16e6ca91241fda3a5
Reviewed-on: https://gerrit.libreoffice.org/14283Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>

Change-Id: I8da0a89b7d6e044af8188a87220c654cb7bf9d4d

guess we'll need them more often..

Change-Id: I0ef149fc5edceee765419764bf0efa571ba9d977

As explained in the following link, access mode should be set to
"EnableShareDenyNone" to avoid blocking others process to access the
file opened by the Property Handler.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd894084%28v=vs.85%29.aspx

Change-Id: I61cc251078c20f6a8cf7fa052c222a86e4e383b3
Reviewed-on: https://gerrit.libreoffice.org/13596Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>

Change-Id: Icdd126714b988517bdbbe49b203951afd92f8a17
Reviewed-on: https://gerrit.libreoffice.org/14297Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: Id8136d3d35436d5e81ff79b9c548474128e9c076
Reviewed-on: https://gerrit.libreoffice.org/14296Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I1bfd54fccc6a40a7a845317975a5d5e232b290e9
Reviewed-on: https://gerrit.libreoffice.org/14299Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I4949b9daaae183efcbab21dafca0c84838c2c6d0

Change-Id: I8ed7028f865bd4a6425859ab3b57ed8e928a78e4

Change-Id: Ibdbad2f8b5471698337fb7838dadd6188b1add7d

Could use a checkbox instead of listbox here, since our LB has only
2 values, but with listbox it'll be easier to add more fill types in
the future

Change-Id: I67cd94b9b49b06434e4a22788b032425c3728e7f

Change-Id: I4f96972255ca99debd53d4302073d1823cc27492

Change-Id: I5078e0e4df18d0aece3240dc537504c11cd623de

Change-Id: I37a0003ca321ca788f7885eb9fdea69ed388a35d

Change-Id: I2e7528cb374d621f148d559c51521013bba62477

Change-Id: Ie96cf3043b126577087eadae5900489a5eb84bcf

OutputDevice::getFallbackFont requires mpGraphics to be created/initialized.
Without the check and initialization OutputDevice::getFallbackFont will segfault.

Change-Id: I18225a24a6767933c8f1ff8f1cfd392543a95132
Reviewed-on: https://gerrit.libreoffice.org/14287Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Use buttons "Add Decimal Place" or "Delete Decimal Place" to change the
number of significant digits with scientific format (also works for
"General" format)
Improve format management for "red for negative"
to be compatible with tdf#88999

Change-Id: Id681afc4fc73674c9823172c6cd71925e63b867f
Reviewed-on: https://gerrit.libreoffice.org/14264Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Scientific format was excluded from being able to increase/decrease
number of decimals, red for negative or thousand separator in UI Format >
Cells > Numbers and Sidebar > Number Format

Change-Id: I56b175a26fc5ba46b9964390f9c098d5d93c73dc
Reviewed-on: https://gerrit.libreoffice.org/14293Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

As part of commit 'fdo#82259 we don't actually care about the ttf version here'
the font data table pointer was incremented presumably to skip
the version number. This results in reading past the end of the array, confirmed by DrMemory.

There is no need in changing the pointer as the parsing is done using absolute offsets.
Furthermore, by moving the pointer, the parser reads incorrect fields (everything shifted 4 bytes).

However, moving the pointer had the desired side-effect (at least on Windows)
that the hints on the right side of most of the fonts were gone
for most cases (the purpose of fdo#82259).

It seems that this was accidental and not the proper fix to that issue.
This patch does make most of the hints show up again on win, and I don't have a mac
to verify if the fonts with the nonsensical hint texts still suffer the issue in fdo#82259.

Change-Id: Idf3bfa292fa063fa05e0ff62920a6bdfa4c94647
Reviewed-on: https://gerrit.libreoffice.org/14281Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Ib6b4f7d5323ea7e94c7b535c68bb6e0af2c49ffa

Theiry implementations were empty both for iOS (well,
TiledLibreOffice, our iOS test viewer app, anyway) and Android.  Part
of work to make TiledLibreOffice use LibreOffieKit instead of
<touch/touch.h> and the older Writer-specific tiled rendering API.

Change-Id: I602a1ebd58ec2c8d6b2d170d65e157d91e0bf521

Change-Id: I8b185ad37e1db3262c2533c0146e4fe7fb3ef3ea

Change-Id: I37b616b3b509c82551d9690c0313e09063a758bc

Change-Id: I824e977e99e8889e5cb69403feb0f1d5e1d0cc31

...and assumed to be merely performance optimizations (so removing them should
hopefully not break any functionality).

Change-Id: I9f40118f5a4bd1526e0cfbf74715455d543bfd54

Change-Id: I4bd2cf8a920c119d508e3316107fa2a616472ba2
Reviewed-on: https://gerrit.libreoffice.org/14259Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

DrMemory reports unaddressable write of 2 bytes (a single unicode character)
in GetClipboardFormatNameW.

While the API documentation do not imply that the buffer length excludes
the null terminator, the returned length does.
Even though in my case the format name was "HTML Format" which is
far shorter than the 256 character buffer size, DrMemory consistently
cought unaddressable write at the end of the buffer.

It's not clear why GetClipboardFormatNameW would need to access
beyond the length of the data it writes, but this fix is harmless
and at least will silence DrMemory, if not fix a genuine issue.

Change-Id: Ib8ac69a65d4fcff53e71f56f9a06c9c7299be1ba
Reviewed-on: https://gerrit.libreoffice.org/14286Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: I08206b7a185a133c18dbb7a09985e3a94736c1e9

Change-Id: Iab76060952ae8c1b64d3ff32e5ae8f5212e016b0
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>