This patch is based on Caolán's one at 68075a61c2
I've chosen the background color used in Windows program Paint.NET as
our default background color. It's a nice compromise that doesn't look
out of place anywhere.
Change-Id: I5081201043be4a7ad6152d1ce59451daa4ece1ac
Reviewed-on: https://gerrit.libreoffice.org/10527
Reviewed-by: Stefan Knorr <heinzlesspam@gmail.com>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-on: https://gerrit.libreoffice.org/10520
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Do build the cmdmail library, the uri-encode executable and do install
the senddoc script for OS X, too.
Note that in order for it to work, one needs to set the "E-mail
program" in Preferences:Internet:E-mail to /Applications/Mail.app. (Or
possibly some other application and/or executable.)
Change-Id: I5764c9891865983d46081edc854e321643c296cc
Issue :
- In issue file there were two runs(first run=SDT, second run=Image).
- These two runs were consecutive(no text/space/tab was there in between two runs).
- Due to such scenario, "SdtEndBefore" was not getting set.
- Hence at Export EndSdtBlock() was getting called form EndParagraph()
Instead EndSdtBlock() should ge called from EndRun() in order to end
sdt after first run(as in Original file)
Implementation :
- Set "SdtEndBefore" on Graphic in DomainMapper_Impl::ImportGraphic()
- Retrieved same property at export.
- Added export unit test case.
Change-Id: Id514b91f1831af371924f94388f0a404d762c042
Reviewed-on: https://gerrit.libreoffice.org/10827
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Argh, this is getting even uglier.
We cheerfully ignore for now the theoretical possibility that the URE
unorc used by build-time tools (i.e. the configure-expanded
ure/source/unorc) could be different for HOST and BUILD (in case they
use different --enable-canonical-installation-tree-structure), and use
the HOST one for the BUILD tools.
The right thing would probably be to construct the URE unorc in the
relevant Makefile, like we do for fundamentalrc? Or then to just
re-design the whole mess of rc files into some simpler (good luck).
Change-Id: I654309503d0e696778910acadcbf2f6b90ffa02a
Use DrawerLayer to show a side drawer with parts of the loaded
document. The dawer consists of an image (could be changed by a
thumbnail in the future) and the part name.
Change-Id: I27fb6112d9f11e19f3295ace97103b89816591aa
Because the tile view rect wasn't correctly calculated, some tiles
were deleted and in the same call immediately created again. With
this fix the performance increases.
Additionally inflate tile view rect by one tile to minimize the
undrawn tiles when scrolling.
Change-Id: I4b5b2bb31dd4f55babf87503dd37e396f6a5e200
The motivation is that once all the namespace aliases in
writerfilter/source/ooxml/model.xml match the ones in
oox/source/token/namespaces.txt, then the writerfilter copies could be
dropped.
Change-Id: I1f9abb8bb457189997f28c99b0f6b00660252c14
The problem is that the ure/source/unorc file is now expanded by the configure
script, and thus exists only in builddir. But a further complication is that
the uno.ini file is in srcdir. This is one way to handle it. Seems to work for
me, let's see what the srcdir!=builddir tinderbox slaves say.
Change-Id: I6fb456cf849ce5077e2c5bd25dc9149096aab241
Should also fix most of the reports of fdo#46635
(I have no idea regarding the original report,
because it predates the autosave feature.)
Change-Id: I006d62053a159ab3157438a57dee56d6d99990a8
Change them to choice, what was probably really meant here: allow one of
the values, not a whitespace-separated list of one or more values.
Also, clean up nested choices.
Change-Id: I87bc30b710569e317da05933502b36d8d97e4155
For <value> elements inside <resource> ones, the name attribute and the
text of the element was the same, but our scripts only parsed the text.
So remove the redundant code that's ignored anyway.
Change-Id: I0d96b485c9e095be51571f2d68eb395920c97bc8
In that case the dylibs won't be in the parent directory of where the
jars are (Resources), but in Frameworks.
Change-Id: I628d828ca820d07724947050f54f9f5f9148e159