Age | Commit message (Collapse) | Author |
|
Needed to migrate UnitTest for Emf/Wmf import from
vcl to emfio. Corrected stuff based on gerrit build
feedback
Change-Id: I7fd2456f814ea19583072ba09730a07e9b9d4061
|
|
Change-Id: Ie085ad2610a306c7f9c44551114041d0950d1af5
|
|
More unifications, changed all Map*() methods to use a single
B2DHomMatrix which is created based on former stuff, XForm now
completely replaced. To check, added debug-only code and switches
to the VclPixelProcessor so that visual checks get easy when
using these modes (overlay of both methods with modded colors).
Also resynched to master.
Change-Id: I7b749f90bfde2ec1c2e49ee90ca2ef368da0547e
|
|
Corrected/streamlined more, added 1st rough geometry
creation to have a proof of concept. Checked the
helper classes based on EMFPObject and their derivates.
First versions of EMFPPlusDrawPolygon and
EMFPPlusFillPolygon, but the complex info in the data
objects needs more complex primitive creation. Not sure
if primitive creators like createHairlineAndFillPrimitive
will be usable, these are based on PropertyHolder info.
Also added usage of HandleNewClipRegion, that should be
usable
Change-Id: I96119be290140bee252ee21a3e1187fad60e9c7d
|
|
Change-Id: Ia931ca356fb079b9cb2395ba2311b91d2481e2d4
|
|
In the current state interpretation of the GDI+
data is needed in the MetafilePrimitive in the
drawinglayer project. Migrate helper stuff and
reader from cppcanvas to drawinglayer as tooling,
prepare tooling, prepare changing from direct
canvas rendering, isolate and migrate existing
tooling from MetafilePrimitive from reading emf/wmf
to places where it can be commonly used by both,
prepare cange of different graphic statue usages,
start changing XForm to B2DHomMatrix conversions,
...
Change-Id: I2d6954f69464653d111abb316fd9654ad3499c3f
|
|
Decided to keep the migrated/isolated Emf/Wmf reader
which are now hidden behind a Uno Api. Had to re-implement
WMF_EXTERNALHEADER (now WmfExternal, own file/header)
to not break anything. It *seems* to just scale something
and could be done after import, but I could not be sure.
Also needed a callback hook to allow getting the Metafile
out of a MetafilePrimitive in a lower module (vcl relative
to drawinglayer) which is needed as long as primitives
are not completely on Uno Api. Deleted all Emf/Wmf reader
stuff from vcl.
Change-Id: Ic5540defa8ec770728280df4df3f12e1f48cfc3a
|
|
Change-Id: Ice0f779f8026983fd0884c2a02e9fd7220b498dc
|
|
Change-Id: I1949e851c560a81a461ec42a992f3b2cb0d019f8
|
|
Complete redevelopent is too expensive, start with
adding a copy of the existing vcl importer which
will in the next steps be adapted to import primitives
instead of MetaFile(Actions). Adapted namespace, made
compile and added sample code to roughly use it
Change-Id: I79e7ea0d78099fbbe18e2a595457b2ab353f58ea
|
|
Change-Id: I0de82e0e431c0ce4527a909c2f98194f465ace8d
|
|
For development and to not be dependent of the progress
of the coming EMF+ importer, for now add fallback to
using the old Metafile importer, plus conversion to
primitive representation. That way the whole encapsulation
is ready and can already be used
Change-Id: I29afadaaaba71d75d0f5593852f4cc0cb3dd13f8
|
|
make complete turn around and internal buffering
for Emf/Wmf/Svg work, including images in ODF and
re-save from UI. The correct FileType has to be
determined. It has shown that *.wmf exist that really
contain *.emf, so this turn around will not alter
the binary data, but may change the mimetype
Change-Id: I4fd92629236c12114f7b7c30234a3d3a9917dfaf
|
|
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
|
|
Wallpaper in dialogs with fix font colors isn't a good idea
Change-Id: Ie97ebe6fd7ed3a52bcdc78204d7190b0e5683eb3
Reviewed-on: https://gerrit.libreoffice.org/39990
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Heiko Tietze <tietze.heiko@googlemail.com>
|
|
Change-Id: Ifb7bf759e87cb654401005914ed8906ef9456fdd
|
|
Although the containing shape is in the background (and thus the
normal paragraph text is still visible), the shape's text
was still painting over top of the normal paragraph text because
the textbox was set as opaque and not transparent.
Setting the textbox to sync the opacity value of its containing shape.
Change-Id: I02477e2fa7def1f13590afcaa7c6564dd79d6406
Reviewed-on: https://gerrit.libreoffice.org/39672
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
I get a warning under MacOSX of
argument unused during compilation -I . -Werror,-Wunused-command-line-argument
Change-Id: I0ae48783eefa52a829471e51a94c79d235dc2f38
Reviewed-on: https://gerrit.libreoffice.org/39988
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Documentation:
https://msdn.microsoft.com/en-us/vba/excel-vba/articles/application-filedialog-property-excel
https://msdn.microsoft.com/VBA/Office-Shared-VBA/articles/filedialog-object-office
Using FilePicker and FolderPicker uno services.
Change-Id: Ifd3b3fc9c135efb0663d2ef36ecbe2b2fbe6132f
Reviewed-on: https://gerrit.libreoffice.org/39806
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
|
|
... and not read after having been set in FillControls()
Change-Id: I09ae5655b6187bcedc95232797bddb24b9064847
|
|
Code is already confusing enough..
Change-Id: I5b6f5bce32342623374df67727c44cc50b77930c
|
|
Change-Id: I6794d134a6f0d1f1b1531782c5f8011ce322085b
|
|
Change-Id: Idc5e1e26fa1a98c6f96a1f0f15b6e5c3c9398402
Reviewed-on: https://gerrit.libreoffice.org/39957
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
reverts
commit 62ea355b2679073b8ee326df5793231996136da9
Date: Thu Dec 12 09:55:35 2013 +0100
fdo#72125: GetTextWidth() can get very expensive.
Let's just count an approximate width using a cached value when we have too
many entries.
The expert dialog got fixed by not populating it with all options on load
and instead by incremental disclosure as the users searches/expands it so
this optimization effort isn't needed
in the meantime there was another problem the above papered over with
commit b4bbb5e5d7b31caad2fbcc00382ad27df3c81001
Date: Sun May 17 22:56:46 2015 +0900
refactor how font, fg. and bg. are applied in widgets/controls
which was fixed (hopefully) in the previous commit
Change-Id: I8383d9cd7a9983a85c7f3acec0281d984c44f9e7
Reviewed-on: https://gerrit.libreoffice.org/39951
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
instead of when the font changes
since...
commit b4bbb5e5d7b31caad2fbcc00382ad27df3c81001
Date: Sun May 17 22:56:46 2015 +0900
refactor how font, fg. and bg. are applied in widgets/controls
Change-Id: I8c9ebeb8d85f2c8b5e5ddc0aa03b6d64b5348132
Reviewed-on: https://gerrit.libreoffice.org/39950
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I40d08932115e07470de73b0f0dc9b9b03e608fbe
|
|
This is a regression from commit
503eba23c9a199583eddee9e169a4fddbecf416f
Due to rounding errors, as the Scheduler uses milliseconds, but
the headless backend uses nanoseconds the StartTimer assumed it
would wake up this ms, but the headless check function would still
wait. This is more of a workaround, so instant wakeup for the
headless backend works again.
Change-Id: I2ba9b4ad2b67ec99eeb4dd098ded6457d3753127
|
|
It was valid, but not trusted.
We need to show the owner trust in another place.
gpg4libre
Change-Id: I344a7b064a22c16b647c73d52f7abd91cfc86be9
Reviewed-on: https://gerrit.libreoffice.org/39826
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Owner trust levels considered valid keys:
Marginal
Full
Ultimate
Owner trust levels considered invalid keys:
Unkown
Undefined
Never
Change-Id: I7338b587acfd105ca24e40b45960cea8d2c04ded
Reviewed-on: https://gerrit.libreoffice.org/39952
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Remove unnecessary "Long" literals in cui/source/tabpages.
Change-Id: Ia46cc027e2225ab7dcfdab2828f1fb4a60f4619a
Reviewed-on: https://gerrit.libreoffice.org/39881
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
There's a bit of a problem with XFillBitmapItem, which contains a
GraphicObject that can't be swapped because it's a poolable item.
Generally contemptorary hardware has enough RAM that we can easily
increase the cache size to 400M (effectively there's another factor
of 2x), but on legacy 32-bit platforms the address space is getting
scarce, so keep the existing size for those.
Change-Id: I8437f4e8c5421f8ec20e94e4cdf64f867d7760ca
|
|
Same as previous commit, but for sw.
Change-Id: Id678de3f512204437e37aaedf24e24aff7a9e592
|
|
These GraphicObjects clog up the GraphicManager cache so it's
effectively useless.
Round-tripping the ML bugdoc, this doesn't provide much of a
speed-up by itself, but together with the previous fix it goes from
3:00 to 1:30 (in an optimized build).
Change-Id: If52e176c790b94ffef9984be53376a34345b06e3
|
|
XMLShapeExport::ImpExportGraphicObjectShape() unnecessarily swaps out
the GraphicObject by calling setPropertyValue("GraphicStreamURL")
even if the URL didn't actually change from what was retrieved
just a couple lines earlier, incidentally swapping it in too.
Well actually it isn't really swapped out, it's marked as auto-swapped,
but nevertheless on getting the "ReplacementGraphicURL" property
its Graphic will be replaced by swapping it in again.
So don't do that, then it's only swapped in once.
This speeds up round-tripping the ML bugdoc from 3:20 to 3:00.
Change-Id: I65a211a0c225444c06d5516df9c6716360be46c0
|
|
Change-Id: Ia7afb5b9750704797ff8030688d0531c27d80836
|
|
No idea off the top of my head what is the problem here, seeing Linux
and Windows is happy; clang on Linux as well.
Change-Id: I56c79b37a5648d9afd02d8e161ea4a279cc89744
|
|
Odd things happen inside gpgme if the buffer is prematurely
truncated due to \n char and valid signature is then evaluated
as invalid
Change-Id: I24d4d22af06a3dde6eb7fdfc12953cf1b5f19c1e
Reviewed-on: https://gerrit.libreoffice.org/39945
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
This addresses the sub-problem described in comment 12 of the bug, i.e.
text frames are now moved to the first page from the second one when
text frames are deleted on the first page.
Change-Id: Ic0ede45381fb84b13d1ac02e4d1f39d817650616
Reviewed-on: https://gerrit.libreoffice.org/39946
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Negative sheet number injected by
sc::FormulaLogger::GroupScope::addRefMessage() wans't handled by lcl_Format()
#9 0x00007f292172c322 in ScGroupTokenConverter::convert (this=0x7ffc5b1940d0, rCode=..., rScope=...)
at /build/libo/dev/sc/source/core/data/grouptokenconverter.cxx:140
#8 0x00007f29224c54d8 in sc::FormulaLogger::GroupScope::addRefMessage (this=0x7ffc5b193ff0, rCellPos=...,
rRefPos=..., nLen=111, rArray=...) at /build/libo/dev/sc/source/core/tool/formulalogger.cxx:147
#7 0x00007f292181c071 in ScRange::Format (this=0x7ffc5b193dc0, nFlags=-32760, pDoc=0x4b1db70, rDetails=...,
bFullAddressNotation=false) at /build/libo/dev/sc/source/core/tool/address.cxx:2211
#6 0x00007f292181b9a9 in ScAddress::Format (this=0x7ffc5b193dc0, nFlags=-32760, pDoc=0x4b1db70, rDetails=...)
at /build/libo/dev/sc/source/core/tool/address.cxx:2111
#5 0x00007f292181ecf5 in lcl_Format<rtl::OUStringBuffer> (r="", nTab=-1, nRow=75, nCol=0, nFlags=-30968,
pDoc=0x4b1db70, rDetails=...) at /build/libo/dev/sc/source/core/tool/address.cxx:2018
#4 0x00007f29214471fb in rtl::OUString::operator[] (this=0x7ffc5b193c00, index=0)
at /build/libo/dev/include/rtl/ustring.hxx:668
Change-Id: I68ecfb11574644e9e5670431789ee42d37d27523
|
|
Change-Id: Iba449fc66423959340c7967c64bc422a28fc75dd
|
|
Change-Id: If5bdd1532be44a47ff7cc3b769be3ea585aea562
Reviewed-on: https://gerrit.libreoffice.org/39685
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I268b32270a17c0c3fcf8236c3e0eebac9a57cb5d
|
|
... by moving cursor in an Impress table
Table controller handles key and mouse events itself, but can't
do the invalidation of the slotids which would lead to update
sidebar corresponding widgets.
Change-Id: I0d1db58ecb714bb16dfb1b5662f0fba7ce69c06f
Reviewed-on: https://gerrit.libreoffice.org/39933
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: If43c8bfa906fc711ed8026a1e06add3d7ac166d9
Reviewed-on: https://gerrit.libreoffice.org/39941
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ice996c741e239767a7a15fe9b11147f5384150ba
Reviewed-on: https://gerrit.libreoffice.org/39940
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I362724911ac60df7ac699495bac852be9e7c6b13
Reviewed-on: https://gerrit.libreoffice.org/36684
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I6c5c9d885df7fa4032724861361957cb6981091c
Reviewed-on: https://gerrit.libreoffice.org/39939
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I859b77319f551eabd19dae54bd69c212221112a8
Reviewed-on: https://gerrit.libreoffice.org/39938
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6ff24f048bd8f75bf87a78b718f37b57855d4781
Reviewed-on: https://gerrit.libreoffice.org/39932
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8bc5c925f940283bc54698bbcba77efcca883273
Reviewed-on: https://gerrit.libreoffice.org/39937
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|