The constructor of SvxNumRule initializes aFmts[i] with a format but
always sets aFmtsSet[i] to false, so SvxNumRule::Store()
and SvxNumRule::SvxNumRule(SvStream &rStream) need to be able
to round-trip that combination to prevent spurious numberings.
It is unlikely that this class is serialized in the table auto-format
files but i haven't checked; this change does not change the size of the
serialization so shouldn't cause trouble anyway.
(regression from a95cce2729)
Change-Id: I589ea108ac069624aaa7b26cdc3bfe8182b15851
Even if the symbol font bit isn't set, the oox import route lacks the ability
to state that the bullet font is a font of symbol encoding. If the font is not
available on the system we go into fallback logic to state that famous symbol
fonts are in symbol encoding. But there is a symbol font on mac so its not
unknown and that doesn't happen. And the mac symbol font is not actually in
symbol encoding (seeing as it's all rearranged into the correct unicode
positions) so the recode logic is skipped in this special case to map the
microsoft/adobe private use area chars to the modern code points where they
were moved in the apple font.
I guess one alternative possible solution is to lookup all the fonts used in a
openxml doc using the fonttable stream where the charset info is available. But
seeing as it should only affect one particular font lets just move the encoder
test outside the issymbol block.
Change-Id: Ic5bd3ec15c8d8d99e2cab0fb67cc4bc33081c756
e.g. when growing m_aRow from size 3 to size 10
(that is, columnIndex==9),
the old code was initialising only position 9
while it we need to initialise all new positions,
that is positions 3 to 9.
Change-Id: I6a51b816104e33fdd7773b68e254e9bea50110ef
fillColumn is the only caller of impl_getBookmark, so all necessary
setup (in particular ensureCacheForColumn) is already done, and
does not need to be done in impl_getBookmark again.
Change-Id: Ic78b7dabd7c536abd9ed956baa178d685a63f713
Currently the hsqldb and jdbc sdbc drivers are broken due to this.
Change-Id: Ib49cb2aac707a354f6de9e4c658f9baf288142fd
Reviewed-on: https://gerrit.libreoffice.org/5666
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
The bugdoc has a table with a single cell, and also a nested table in
that cell. Both tables have auto width. The problem was that the width
of the outer table was too large.
There is a trick in DomainMapperTableManager::startLevel() to get the
cell widths at the correct level: do the same in
DomainMapperTableManager::endLevel(), and that'll fix the table width
problem. (Because with that, the outer table will correctly have access
to its cell width.)
Change-Id: Ib750f0475364fd7e47c445cb54f2df34f3af085d
It allows to build only the common parts of the help, e.g.
bundle the helpcontent-related icons.
It is useful when the build content is built separately. For example,
it is used to speed up the build of the main package in openSUSE
Build Service.
embeddeddbList is only present in generalpagewizard.ui but not in
generalpagedialog.ui, hence it should be controlled by
OGeneralPageWizard and not OGeneralPage.
Change-Id: I7c52493e12b40d9043d80fb023cfc9eb9c9e42ec
Reviewed-on: https://gerrit.libreoffice.org/5654
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
Tested-by: Lionel Elie Mamane <lionel@mamane.lu>
