and use the users preferred initials for impress annotations
i.e. the ones entered in the tools->options
and save and load those to/from odf similarly to
what we do for writer annotation initials
Change-Id: Iadc0e994bfaf58632ce25b8f7cdc737580ee97bc
Reviewed-on: https://gerrit.libreoffice.org/22143
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
+ Removed comment cruft
+ Tab formatting in number of files
+ Some commented out code removed
+ Tab characters replaced with spaces
+ Newline cleanup in quite a few files
+ Tweak header guard #endifs
Change-Id: I3208ff2f047da890edcc49b73389aca22442f5fc
Reviewed-on: https://gerrit.libreoffice.org/22221
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
... attributes that happen if both CharHighlight and CharBackColor
properties are used, because the CharBackTransparent property wasn't
taken into account, and combining the CharBackColor and
CharBackTransparent properties happens *after*
XMLTextExportPropertySetMapper::ContextFilter() runs.
Also, it looks like a transparent highlight wouldn't export properly but
apparently DomainMapper::getColorFromId() won't create such.
(regression from f880962f5b)
Change-Id: Ib628ef8bb377482f74fadb97c81afb95fbbf7184
the original looks odd, but the code was like that ever since it got introduced
with 44cfc7cb65 "re-base on ALv2 code. Includes
(at least) relevant parts of:"
Change-Id: I327c5a53a2634aca1b36367ee09c068ac610d3f4
... if a document contains foreign elements or attributes.
In fact since ODF 1.2 the office:version attribute is mandatory and any
document that omits it is therefore invalid, while "extended conforming"
documents are allowed to contain foreign elements and attributes.
This mysterious check was there since CVS initial import, but without
any justification.
Change-Id: Ifeafad2b7af41f06356461adb7ae65dbf7bae11d
7c3c3006de is apparently worse than it
appeared at first glance since there are numerous assumptions about
bookmarks, such as that if they were inserted successfully they may be
copied successfully, which isn't the case for duplicate cross reference
bookmarks.
So fix this differently, by eliminating the duplicates and mapping all
reference fields to refer to the surviving bookmark.
It was not possible to do this in SwXBookmark by checking the makeMark()
return as that would raise interesting problems such as it's currently
guaranteed to have 1:1 SwXBoomarks to core Marks so we can't just
connect 2 SwXBookmarks to the same core Mark, and we also can't leave
the SwXBookmark unconnected after attach.
Another alternative would be to temporarily allow inserting the
duplicate bookmarks and then eliminate them after the import, but what
is implemented now is to check from xmloff for duplicates, which is
reasonably simple.
Change-Id: I7ee4854d1c9d8bf74201089cbb7287b1bd8ee3b9
When importing SdrObjCustomShape for each an Outliner and a
VirtualDevice as RefDevice are created and held. On 32bit systems this
breaks the import with many such objects (in the bugdoc around 4300). On
64bit it works, but more memory as necessary is used. To avoid this,
flush the UNO API implementations at these objects after one page is
imported. Do not do this for each single object, that will break the
connector import which does some processing later.
Change-Id: I7296edd40f01c1a40258808d78bf39e6d4fe29bf
Reviewed-on: https://gerrit.libreoffice.org/19990
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
