1. Edit sc/res/xml/styles.xml adding <style:style style:name="Default" style:family="table-cell"> <style:text-properties fo:font-size="10pt"/> </style:style> 2. Run make check (make sc.check might not be enough the first time) Result is three failed assertions: ScExportTest::testTdf136721_paper_size finished in: 2703ms xmltesttools.cxx:194:Assertion Test name: ScExportTest::testTdf121716_ExportEvenHeaderFooterXLSX equality assertion failed - Expected: &Lodd/right&Cpage&Rheader - Actual : &L&Kffffffodd/right&C&Kffffffpage&R&Kffffffheader - In <>, XPath contents of child does not match xmltesttools.cxx:194:Assertion Test name: ScExportTest::testTdf134459_HeaderFooterColorXLSX equality assertion failed - Expected: &L&Kc06040l&C&K4c3789c&Rr - Actual : &L&Kc06040l&C&K4c3789c&R&Kffffffr - In <>, XPath contents of child does not match xmltesttools.cxx:194:Assertion Test name: ScExportTest::testTdf134817_HeaderFooterTextWith2SectionXLSX equality assertion failed - Expected: &L&"Abadi,Regular"&11aaa&"Bembo,Regular"&20bbb - Actual : &L&"Abadi,Regular"&11&Kffffffaaa&"Bembo,Regular"&20bbb - In <>, XPath contents of child does not match This unexpected content is only seen in the ScDocShell and not in the final exported file. The unit test file is sc/qa/unit/subsequent_export-test.cxx The documents are in sc/qa/unit/data/ods and sc/qa/unit/data/xlsx I was looking into bug 112559 "FILESAVE: ODS - Default cell style font size not set". It is indeed possible to solve it by editing sc/source/core/data/stlpool.cxx so it has #include <editeng/fhgtitem.hxx> and in ScStyleSheetPool::CreateStandardStyles() pSet->Put( SvxFontHeightItem( 200, 100, ATTR_FONT_HEIGHT ) ); // 10pt However, I thought that as we have support for defining cell styles in sc/res/xml/styles.xml since the 2016 GSoC project, I would try that approach as well (more human-readable and the expected place to look for it). With the cell styles present in the source, in the exported ODS the styles.xml will get <style:style style:name="Default" style:family="table-cell"> <style:text-properties fo:color="#000000" fo:font-size="10pt" fo:font-style="normal" fo:font-weight="normal" /> </style:style> These additional attributes for color, font-style and font-weight are added in ScOrcusStyles::font::applyToItemSet in sc/source/filter/orcus/interface.cxx When using the stlpool.cxx approach, the only attribute will be font-size. In this case there are no test failures. I would appreciate any tips in debugging what is going on in the ScDocShell.
I resumed debugging, but was unable to determine how I can inspect the contents of the cells in ScDocShell. I went into sc/qa/unit/helper/qahelper.cxx and ScDocShellRef ScBootstrapFixture::saveAndReload( ScDocShell* pShell, sal_Int32 nFormat ) The m_aDocument in pShell seemed relevant, but I could not find cell contents. Here is what I did in GDB: p *pShell.m_aDocument.mpCellStringPool $9 = {mpImpl = std::unique_ptr<svl::SharedStringPool::Impl> = {get() = 0x555556729e00}} p *(svl::SharedStringPool::Impl *)0x555556729e00 $13 = {maMutex = {mutex = 0x555556729e80}, maStrMap = std::__debug::unordered_map with 0 elements, mrCharClass = @0x555556735330}
First, the Default cell style is NOT SUPPOSED to be present in styles.xml as it is internally generated and all other cell styles inherit from that as parent and I guess that redefining it in styles.xml probably will not work as intended and wreak havoc sooner or later (I'd say it's completely untested at least). I also think that setting the Default style's font to a fixed 10pt size is not the proper approach. If the problem is that font size is not written to file then the export should check for it and add it to the document's default style instead. I'm not sure at the moment where this internally used 10pt actually originates and why export omits it, but the Default standard style never defined a hard 10pt font size. For your debug problem, I don't quite get what the "cell contents" should be at the ScDocShell::m_aDocument. The mpCellStringPool is the pool of all shared strings in the document, yes, and then? What are you looking for? Really cell content, i.e. a string contained or displayed in a specific cell? You'd have to obtain that from the document via ScDocument::GetString(), so you could call m_aDocument.GetString(0,0,0) to obtain the OUString for the top left cell on the first sheet.
(In reply to Eike Rathke from comment #2) > First, the Default cell style is NOT SUPPOSED to be present in styles.xml as > it is internally generated and all other cell styles inherit from that as > parent and I guess that redefining it in styles.xml probably will not work > as intended and wreak havoc sooner or later (I'd say it's completely > untested at least). Thanks, I was hoping to hear a confirmation. > I also think that setting the Default style's font to a fixed 10pt size is > not the proper approach. If the problem is that font size is not written to > file then the export should check for it and add it to the document's > default style instead. I'm not sure at the moment where this internally used > 10pt actually originates and why export omits it, but the Default standard > style never defined a hard 10pt font size. Cool, I will mention this in bug 112559 > For your debug problem, I don't quite get what the "cell contents" should be > at the ScDocShell::m_aDocument. The mpCellStringPool is the pool of all > shared strings in the document, yes, and then? What are you looking for? > Really cell content, i.e. a string contained or displayed in a specific > cell? You'd have to obtain that from the document via > ScDocument::GetString(), so you could call m_aDocument.GetString(0,0,0) to > obtain the OUString for the top left cell on the first sheet. Apprently after 1 month I forgot what I was doing and that there is no content in the cells, but it was about headers and footers. Sorry for the noise, but thanks for the lessons.