summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
7 daystdf#160706 speed up loading conditional formatting rule in XLS (4)Noel Grandin2-27/+119
speed up the matching of duplicates in CellAttributeHelper by using std::set and partial sorting by name Takes my time from 33s to 6s Change-Id: I06376c1e253981cb5a3020142d24fa5776513d4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166262 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
8 daystdf#160706 speed up loading conditional formatting rule in XLS (3)Noel Grandin4-9/+13
the comment when calling MakeCellStyleSheet does not match the implementation, so make the implementation match the comment. i.e. if there is an existing stylesheet with that name, just return it. Reduces load time for me from 47s to 33s Change-Id: If1bd08baf8515933b87c075d9eef04bc0a125357 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166241 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
8 daystdf#160706 speed up loading conditional formatting rule in XLS (II)Noel Grandin4-15/+35
Reduce the work we do in IndexedStyleSheets::Reindex takes my test document from 117s to 48s Change-Id: I2e23b05684d0f2e3a9dc05c0a0fc4e9bbea7008d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166180 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-19fods2xls fuzzerNoel Grandin8-0/+238
Change-Id: I095178b1b3c61829abf5c08b8b81cd7415e3e795 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162747 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-03-16slightly speed up XLS importNoel Grandin1-2/+2
we can use an unordered_map here Change-Id: I445521d9dec2d49d9df7d2a733a43330d0996ecb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164924 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-13tdf#148170 - Convert print range to an excel cell rangeAndreas Heinisch4-3/+44
During export from Calc to XLS, ensure that the print range is converted to a valid XLS print range. If the print range exceeds XLS format limitations, it will be appropriately cropped to fit within the constraints. Change-Id: I2b233e4d57dfbe30f491448d2ee2972b8b717ea3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164469 Tested-by: Jenkins Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
2024-02-17sc: Show warning for a XLS document with unknown encrypted partTomaž Vajngerl6-4/+40
If a document contains a "DRMContent" section that we don't know how to decrypt, show a warning before showing the un-encrypted content. Change-Id: Id7f48b68e1d65ce46434906b2fb3c7912dcc5f49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163513 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-02-17sc: Handle xls documents with unknown DRM encryption betterTomaž Vajngerl1-1/+3
If we can't decrypt the document, don't set the SotStorage to an empty SvRef. It is possible the document contains a "fallback" un-encrypted document, which we can show. This is typical for some Excel add-ons, which encrypt the document, but also add a part that is un-encrypted to write the instructions on how to get the add-on. Change-Id: I6079786b1d0dce3a819a70e057699d0a461a5be5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163511 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-02-15tdf#159707: sc: Add UItestXisco Fauli2-0/+33
I tried to create this test as a Cppunittest but it fails with Run: 1 Failure total: 2 Failures: 1 Errors: 1 warn:vcl:428912:428912:vcl/source/app/svmain.cxx:494: DeInitVCL: some top Windows are still alive text = "" type = "14FloatingWindow", ptr = 0x5608715e49e0 text = "tdf159707.xls (read-only) — LibreOfficeDev Calc" type = "10WorkWindow", ptr = 0x5608709ab420 Change-Id: I1b9e16d57050fe07f74c632d441e3a06f49e9438 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163363 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-07-11tdf#123026 xlsx import: recalc optimal row height on importJustin Luth6-13/+21
This patch depends on the previous patch for this bug report, which allows each sheet to hold its own default row height. The given height for the row might not be enough to fit the content. If the row is set to use optimal height, that will be corrected as soon as the row is edited. Obviously, it should not require an edit to be correct on FILEOPEN, so this patch recalculates after loading the document. This might have a very negative effect on the time needed to open a file. I couldn't duplicate the XLS method because Library_scfilt.mk doesn't link to ScSizeDeviceProvider. The existing UpdateAllRowHeights wasn't designed to allow any performance improvements, so I made a new one. The new one is based on the newer ScDocRowHeightUpdater class - so perhaps the older method can be phased out. This new UpdateAllRowHeights could replace the XLS bSetRowHeights clause - with hopefully some performance benefit. I'm not sure I'm ready for the regression hate that would come from the inevitable performance implications. Testing however doesn't suggest a huge slowdown. I tested with time make sc.check before the fix I was getting 16m 4s +- 10s after the fix I was getting 16m 25s +- 10s Specific test showing the need for these patches: make CppunitTest_sc_subsequent_filters_test2 \ CPPUNIT_TEST_NAME=testTdf123026_optimalRowHeight Impacted unit tests (without the previous patch) are documented in earlier patchsets. make CppunitTest_sc_subsequent_export_test \ CPPUNIT_TEST_NAME=testMiscRowHeightExport make CppunitTest_sc_subsequent_export_test2 make CppunitTest_sc_jumbosheets_test CPPUNIT_TEST_NAME=testTdf134553 Change-Id: I6d020c1a5137dd4f05e20e82b1764a102b7f56d0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140260 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-30crashtesting: assert/crash on export of fdo66241-1.ods to xlsCaolán McNamara2-0/+38
and others, e.g. ooo101471-3.odf fdo68105-1.ods fdo66241-1.ods fdo68105-2.ods fdo64646-4.xls ooo101471-2.sxc Change-Id: I5a639cc6539130bc6a7ada00652d02529544f650 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153800 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-04-27tdf#151715 sfx2: do not use FORCERELOAD for document stored in /tmpMichael Stahl1-1/+4
This does not fix the actual bug, but is a workaround for a bug somewhere in the Notebookbar code that was exposed by commit 5b5fb5e9c0580ecb70cf65882865bdaf16498fa5 "sfx2: do reload on SID_EDITDOC in SfxViewFrame::ExecReload_Impl()". For an ODF file, the Notebookbar is switched to editable by the call to SetReadOnlyUI() from ReadOnlyUIGuard, but the XLS file takes a different path and SetReadOnlyUI() is called in line 819. Here the SfxViewFrame is not yet connected to the SfxObjectShell so unsurprisingly it does not affect the UI; more surprising is that moving the call to around line 859 leads to the SfxHintId::ModeChanged event being handled in SfxViewFrame::Notify() with lots of things invalidated, but the NotebookBar is entirely unimpressed by that. Change-Id: I16f321bb3444eeae76348e20816af02938c3f46b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151089 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-04-18sc drawstyles: Assign the Note style to imported commentsMaxim Monastirsky4-7/+21
... that don't have a style assignment. Typically in ods files created by older versions or by 3rd party. - For hidden comments this should make no difference, as we used to apply the default comment formatting as DF underneath their defined DF, just now we do that as a style assignment instead. - Same for comments from xlsx and xls files. - For visible comments from ods files created by OOo/LO, there should be no difference either, as such files typically include the shape formatting in them. - For visible comments from ods files created by Excel, there will be a difference, as Excel used to not include the full shape formatting (known to be the case with Excel 2007 and 2016; can't test any other version). This resulted with a weird look, e.g. a line instead of an arrow, a default blue fill color and too distant shadow, which clearly not how comments supposed to look. Moreover, the comment will turn to transparent after hiding or copying the cell, and will revert to the default look anyway with resaving. Given that we were already enforcing the default formatting for hidden comments and for foreign formats, I think it's reasonable to do that for visible comments too (and in general it's unclear to me why the ODF import treats visible comments differently than hidden ones). The main motivation of this change is to aid solving the shadow issue - see the next commits. Regarding the comment height change in the testCommentSize test: This does *not* mean there is a change in that comment's import. What this test does is to replace the existing comment with a new comment, and that use the default formatting instead of inheriting the formatting of the old one. But while the current default formatting is whatever defined in the Note style, the old default formatting was actually the draw pool defaults. This is because we used to apply the comment formatting as DF, and the relevant svx code (in SdrTextObj::NbcSetText) wasn't aware of the fact that part of the DF was considered as default in this case. Which means that this test was actually asserting a buggy behavior. Change-Id: I37723cce3c719ecaa9c57bef25bcb168e353c55c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150489 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2023-03-29crashtesting: Null-deref on export of forum-mso-en4-274729.xls to odsCaolán McNamara1-0/+2
and others, probably since: commit f02ec0d8489404966596cb0e949bf969e8e66fa2 Date: Wed Mar 22 08:50:15 2023 +0200 move hasUnhiddenData inside chart2::DataSeries Change-Id: Icf59439f00a40ef036decaa36f3d5af68787c864 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149688 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-02-20Remove exec bits on xls fileAndrea Gelmini1-0/+0
Change-Id: I2082eb3d09ce5f85432807124a80d591e33574d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147344 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-02-07crashtesting: crash in ScInterpreter::ScCountIfsCaolán McNamara1-2/+8
seen on importing forum-mso-en4-253817.xls and others Error: attempt to advance a dereferenceable (start-of-sequence) iterator which falls outside its valid range. presumably since: commit 7674399aac661eb503d7badc53b9a4d68bd9839d Date: Fri May 27 19:51:40 2022 +0200 try to range-reduce even COUNTIFS if not matching empty cells bodge this to fill in 0 for missing ranges Change-Id: If77d8ab887859f11b240975bb837a27785f500a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146604 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-01-24tdf#117266 tdf#120374 sc oox: export correct vml button name #2Justin Luth3-9/+23
So the actual name is more important than I knew. For example, VBA maps click macros based on the button name. So use the MS-provided name and use the SPID to connect to the shape id. Of the existing unit tests that were affected by this: -macro-button-form-control.xlsm: button now launches hello macro -tdf117266_macroButton.xlsm - same file as ^^^ -button-form-control.xls nearly same file as ^^^ -tdf134769.xlsx - checkbox still exists on round-trip -tdf106181.ods - checkbox still exists, but link to cell still lost. -checkbox-form-control.xlsx - nearly same as ^^^ All looks good. Change-Id: If83cf17d60b73c46d55a21b1a46ed320513044cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145961 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2022-12-13crashtesting: (assert) fix treatment of "#FMT" input line valueEike Rathke1-2/+3
For "#FMT" test the original format type for not being NUMBER, the current format type may be different from finding an edit format. This constellation did not matter until commit 4fd1333ba4bb4f2311e9098291154772bd310429 CommitDate: Thu Mar 25 15:00:31 2021 +0100 tdf#140968 tdf#140978 XLSX import: fix lost rounded filters introduced the bFiltering parameter in which case the edit format is not used (and bFiltering is also set when collecting the filter entries for .xls export). In fact the logic should be changed such that obtaining the edit format isn't even executed in that case. For now just fix the "#FMT" case to be backported. Also, the bool return of SvNumberformat::GetOutputString(double,OUString&,Color**) does not indicate success or failure, but whether the "star" asterisk spreading was inserted or not. Contrary to SvNumberformat::GetOutputString(double,sal_uInt16,OUString&) ... cough. Change-Id: Ic8cbbd283a80c654a9ff22ea36897c9b72b8837d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144110 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2022-10-11tdf#148806 tdf#151393 xls vba: no Auto_Open from ThisWorksheetJustin Luth3-8/+33
Unlike Word, ThisWorksheet cannot hold auto-running subroutines for Open/Close/New. This fixes a LO 7.4 regression caused by commit beb6c62e990599d91ac5d9183164c94d269027d3. Change-Id: Idb8f72775d9392b306cb924ee776821272b12f3b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141127 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2022-10-05tdf#151283 calc hangs when try to open XLS fileNoel Grandin1-1/+1
regression from commit 258a8d133d0548c7af51f4852260e9969df288fc Author: Noel Grandin <noel.grandin@collabora.co.uk> tdf#150034 very slow opening pathological chart if nNewLen is < 10, we can get stuck in an infinite loop because the calculation will not actually decrement nNewLen Change-Id: I98920deaa087713c44531a7f6506d1d5d32b2e98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140949 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-09-21tdf#75702 ODS import: send text:line-break to editengJustin Luth2-2/+3
A cell with a line-break specified is no longer a simple string, so send the string to editeng where it can be properly displayed. This already works fine for XLS and XLSX. This change effectively means that text:line-break will disappear, and become two separate paragraphs. Given the nature of spreadsheets, the precidence in various other patches and the failure to properly display without this, I think I'm fine with unilaterally changing one paragraph into two. Change-Id: I7abcbc6f698a4cb319aea5465a8b0393cf63f31f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140262 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2022-09-08tdf#150832: Revert "tdf#150034 very slow opening pathological chart"Xisco Fauli1-2/+1
This reverts commit 613f6e75fbfcc024fc9c3732261cbf2cda6f4ad8. Reason for revert: it seems all charts in XLS files are affected. At least I could reproduce it with all the XLS files I tested it with. Change-Id: I68d13d6f609521ce6af759cf25249656176b66cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139557 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-09-07crashtesting: prevent nullptr accessEike Rathke1-2/+14
There's a xlsx export crash on *2nd* export with data pilot data of forum-en-38962.ods. We export without crash this .ods to xlsx *once*, but on saving again to xlsx it crashes. It also crashes with an export to .xls and then an export to .xlsx. Repeated exports to xls are crash free. Already on the first export there are loads of warning messages of ScDPMember::GetItemData: what data? nDim 0, mnDataId # ScNameToIndexAccess getByIndex failed com.sun.star.container.NoSuchElementException message: "at sc/source/core/data/dptabsrc.cxx:2267 The pivot tables are broken on both exports. This smells like some sort of data pilot cache corruption/insufficiency during .xlsx export but the root cause is yet unknown. This only fixes the crash symptom. Change-Id: Ie479f7f0abc4af284e61f6aa5a69943ccdd72eab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139611 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2022-08-30tdf#90299 Fix saving external links as relativeŁukasz Leszko3-24/+129
In current build some links to external xls files are not saved as relative even if "Save URLs relative to file system" option is checked. This patch aims to solve this issue. Change-Id: I6d0984bdcdeef57b227c8ab1353e002fa4355fc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131711 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-08-02tdf#150034 very slow opening pathological chartNoel Grandin1-1/+2
revert part of commit 10c934147d469965dba6abc78efd02759a010b8e Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Tue Apr 23 09:26:46 2019 +0200 tdf#113266 slow opening XLS with 45 MB drawing in this situation, avoiding setting all the rects dirty speeds up the load from 70s to 1s. Change-Id: Ia35119ff20ef5bded9a34f12cce453434dea4383 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137688 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-06-30tdf#99514 - implement Value2 for compatibilityHannah Meeks4-11/+36
Value2 ignores date formatting in a way that Value does not. Extended vba.xls to test this too. Change-Id: Id75a3dafae2166221731847b7c81e93e8ad835fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133645 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-05-09tdf#148993 XLS export: fix broken formula regressionLászló Németh2-2/+6
Exported XLS documents lost their formulas opened in MSO. Regression from commit 12ee423c7549ddd2b86dfc3fc6fed2c617dcca7f "tdf#144397 tdf#144636 XLSX: cache external named ranges and their formulas". Change-Id: I009630a41b29bb21349711cc07d0ed181f816374 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134075 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2022-02-26do not fail import if there are only warningsLuboš Luňák3-14/+28
When opening CVE-2012-4233-4.xls or ofz5527-1.xls in LO UI, they show a warning about too many columns (presumably because Excel as of now supports 16k and LO only 1k columns by default), but besides stripping the extra columns they otherwise actually load normally. But ScFiltersTest::testCVEs() fails loading them just because of the warning. And if 16k columns are forced for the tests, the files unexpectedly load fine, making the test fail. ScDocShell::ConvertFrom() is rather inconsistent on whether only a warning results in a failed load or not, but most seem not to return failure on only warnings, and I think that makes sense, so make code paths for all formats consistently handle it that way. Change-Id: I202f29f5a5a44aecd34b84cf2f8180222e8d870a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130500 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-26tdf#142010 XLS import: fix bad calculation after editingLászló Németh4-51/+2
Inserting a column messed up formulas in the test document of tdf#142010. This was a regression resulted by the tdf#89281 fix for a performance regression in XLS import related to shared formulas. Revert of commit ba686b9bd2596811141e4028947334f10799c356 "tdf#89281 fix performance regression of XLS import - cleanup" and commit b18b5b7edf3d14ef5f0efe53e367f88a423088c4 "tdf#89281 fix performance regression of XLS import". Change-Id: I96636fb1d84939385efbe7054a4271ff10b88907 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124151 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-08-12tdf#95549 speed up xls openNoel Grandin2-88/+58
Remove the m_wThis field, and instead just check the ref count to know if we are being called from our own destructor. Also re-order ScCellRangesBase::Notify so we do the cheap checks first. This shaves 2% off the load time Change-Id: Ie95a4ff46bacba583ec4b3a934f98a9aac3551b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120385 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-06XLSX export: handle macros on button form controlsMiklos Vajna5-11/+72
This builds on top of commit 1e3263a677b61c718d0fd1be15c066b933f7de18 (XLSX export: handle button form controls, 2021-07-01). The binary XLS export already had code to turn Calc macro names into Excel ones, reuse that for XLSX purposes. Also fix the unwanted named range on export, oox::xls::FormulaParser::importMacroName() mentions how XLSX doesn't have matching named ranges for vba macros (while XLS has), mirror this on the export side as well. Change-Id: I877b6ba2c2e834a2327482da5cadcddf1b4672bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118485 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-05-10tdf#127301 XLSX import: hide hidden named range of autofilterBalazs Varga5-18/+45
Create but not insert/add hidden FILTER_CRITERIA (_xlnm._FilterDatabase) to ScRangeName, because no need for them, so avoid of creating extra named ranges by autofilter re-range (shown in Sheet -> Named Ranges and Expressions -> Manage...). See also commit 3a2263a20629b0a3e9b4935dd43dc59817d0241c "mib17: #163146# XLS import: do not skip hidden names[...]". Change-Id: Ibfd86942a99b251a59394955bc890e6dbe0390f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115189 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-03-15xls load: suppress secondary [~gengou] calendar modifier in format codeEike Rathke2-4/+31
ja-JP Gengou calendar is an implicit secondary calendar switched to and from by format codes. Change-Id: Iea268310ac5e917f2168fec0166754424baa925d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112511 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-03-15xls save: fix writing inline calendar modifiers as format code, don'tEike Rathke1-3/+6
E.g. ja-JP GGGE [~gregorian]YYYY saved as OOXML ended up as [$-411]ggge\ gregorianyyyy which when reloaded became GGGE GREGoRianYYYY displaying 令和3 R033Ro03ian2021 (whatever Xcl might have done with that). Change-Id: If8a7d5b837b69c32afacc7a8d7646fedc84ab87a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112510 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-12-08Update git submodulesgar Soul1-0/+0
* Update helpcontent2 from branch 'master' to a097662d6678263bb91b6a1dc1f5494fbf47bf38 - tdf#95147 Add note to use Optimal Height with wrapping in XLS files Change-Id: Ia7a0f3a1cdbb514f95a19cf1496b0b82bd1626cd Reviewed-on: https://gerrit.libreoffice.org/c/help/+/107308 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2020-10-28tdf#123476 filter: try to detect 0-byte files based on extensionMiklos Vajna8-10/+108
A 0-byte ("empty") pptx file is obviously junk input, so it's not surprising if the catch-all generic_Text filter is chosen to open it in Writer at the end. But we can do better: if we really get an empty file URL with an extension we can recognize, that we can fake the filter type / filter name, so the empty "presentation" opens in Impress, and also a re-save works as expected. This builds on top of commit 8a201be240b6d408d15166be7ffc576b9e123634 (fdo#68903 Import .tsv and .xls plain text files in Calc by default, 2013-10-27), just the new way works for all supported file extensions and also with filters which would not handle empty input (e.g. pptx refuses the import if the ZIP storage is broken). Change-Id: Ie01650a5eb6ca42c35e090133965467b621bb526 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104939 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-07tdf#132796: use LO language settings to set default XLS languageMike Kaganski4-10/+12
This partially reverts fixes for i#63105 and i#71033, i.e. parts of commits 6ca96e7aee937affef218e0bb892e6904f4ef358 and 35777f0b401ba7bee21a24c32739e86598ba608b. Instead of using hard-coded Win-1252 for Excel files by default, use LibreOffice locale language or default document language (as used for old WMF, DXF and RTF files - see 20f6a6b159c69771dc0e087f63b6c701908e32e2, 1a9a77f84cac68bd5374df3e9ee4df88dc87a0ac, and f26bbdb386f9e66b1a154d0589b1a446ea2dd8d5). When a font in XLS specifies ANSI_CHARSET (0), allow using the default encoding, not the corresponding Win-1252. This mimics Excel behaviour for such fonts. Do not use first font's encoding as file default encoding, as Excel doesn't do that. Do not consider font-specified encoding in ImportExcel::Rstring to mimic Excel behaviour for cell number formats (but keep using it in ImportExcel::ReadLabel for cell content). Change-Id: I9860013a1244dc12f06f30c81a67909012c04913 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93612 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-12-30Decrease SplitVertical value to pass on small screen sizeMike Kaganski1-0/+0
Testing on Windows with UI scaling set to 150%, having screen size 1920x1080, ScMacrosTest::testVba failed in window2.xls (SplitColumn) because it tried to split at pixel position 486, while maximum split position was 460. This changes tested SplitColumn value in the test from 243 to 193. Change-Id: Iec9b25dc7b2a700adf23d7ec8983f393ba603191 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85983 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-12-20tdf#129228 speedup load xls file with lots of commentsNoel Grandin3-0/+16
by locking the underlying SdrModel while the comments are added, so we avoid the reformatting that happends when the model is unlocked Takes the time from 3m30 to 1m for me. Change-Id: Ibc3d2b1ded548d5eee7715d9a655a0af61b0eb2b Reviewed-on: https://gerrit.libreoffice.org/85523 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-24tdf#128976: properly calculate default value when writing XLSMike Kaganski5-12/+52
XLS stores default column width as 16-bit unsigned integer in the range from 0 to 255 inclusive ([MS-XLS] 2.4.89 DefColWidth), unlike in OOXML where any floating-point value is valid. Additionally, some correction is used, introduced in commit 555d702903fb0857122024e1ab78a72d122d3f16 (basis of empirical formula in XclTools::GetXclDefColWidthCorrection is unclear). So in XLS, when the default is calculated, we need to take into account if the resulting stored value will actually represent our calculated value. If not, then just ignore the calculated value, and use arbitrary 8 as the default. With that, following IsDefWidth will correctly check if passed width is represented by the stored default or not. All widths that can't be represented as integral count chars in DefColWidth will have fUserSet set in corresponding ColInfo records, thus correctly keeping widths. Change-Id: Iedcc5583c861f5b18a422a9b279c48cff729cbc5 Reviewed-on: https://gerrit.libreoffice.org/83613 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-10-30writerfilter: rtftok: filter control charactersMichael Stahl1-0/+25
... in RTFDocumentImpl::checkUnicode(); see ooo86460-1.xls [sic] for an example. There is another caller of text() in rtfdispatchdestination.cxx:311 but it turns out that buffered text was created by text() in the first place. This shouldn't be a problem for DOCX because XML 1.0 doesn't allow the bad control characters anyway so the sax parser should report an error in that case. Change-Id: Ice45e1c3c8c7db668a4cfb8364e42addea1777ce Reviewed-on: https://gerrit.libreoffice.org/81697 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Michael Stahl <michael.stahl@cib.de>
2019-10-25tdf#126021 speed up saving xls with lots of stylesNoel Grandin2-21/+85
extend the find-map so we can do partial-match searching. Makes it 10x faster for me. Change-Id: I1952a221a919707af078fac9fd1eb63781d9188d Reviewed-on: https://gerrit.libreoffice.org/81488 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-13warn on load when a document binds an event to a macroCaolán McNamara30-65/+236
a) treat shared/Scripts equivalently to document scripts This doesn't automatically warn/block running those scripts when used in a freshly loaded document on its own however because DocumentMacroMode::checkMacrosOnLoading will see at... if ( m_xData->m_rDocumentAccess.documentStorageHasMacros() || hasMacroLibrary() ) that the document contains no macros and flip the allow macros flag to true so that potentially new uses of macros added by the user during the edit are allowed to run b) so, add an additional flag to indicate existence of use of macros in a document c) for odf import, set it when a script:event-listener tag is encountered d) for html import when registerScriptEvents or SwFormatINetFormat::SetMacroTable is called e) for doc import when Read_F_Macro or StoreMacroCmds is called as well for good measure f) for xls import when registerScriptEvent or ScMacroInfo::SetMacro is called g) for oox import when VbaProject::attachMacros is called Change-Id: Ic1203d8ec7dfc217aa217135033ae9db2888e19b Reviewed-on: https://gerrit.libreoffice.org/77131 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-07-08tdf#126192 (Related) Translate automatic chart axis labels in xlsGabor Kelemen2-1/+2
Automatic axis labels in xls format are created on a different code path than the ones in OOXML, translate these too Change-Id: Id1e8a10accf765d40d71c4fcdfec2c1acee832a2 Reviewed-on: https://gerrit.libreoffice.org/75202 Tested-by: Jenkins Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
2019-06-28tdf#126030 (related) Translate automatic chart title in XLS chartsGabor Kelemen2-1/+4
The same string for XLS format is on a different code path localize it too, just in case Change-Id: Iacaf59080cc320498867680fc13836edbe9afe49 Reviewed-on: https://gerrit.libreoffice.org/74820 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2019-06-15Avoid -fsanitize=float-divide-by-zeroStephan Bergmann1-1/+4
...when loading xls/tdf117254-4.xls as obtained by bin/get-bugzilla-attachments-by-mimetype (i.e., the attachment at <https://bugs.documentfoundation.org/show_bug.cgi?id=117254#c5>): > chart2/source/tools/PolynomialRegressionCurveCalculator.cxx:189:32: runtime error: division by zero > #0 in chart::PolynomialRegressionCurveCalculator::recalculateRegression(com::sun::star::uno::Sequence<double> const&, com::sun::star::uno::Sequence<double> const&) at chart2/source/tools/PolynomialRegressionCurveCalculator.cxx:189:32 > #1 in chart::VSeriesPlotter::createRegressionCurvesShapes(chart::VDataSeries const&, com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, bool) at chart2/source/view/charttypes/VSeriesPlotter.cxx:1343:22 > #2 in chart::AreaChart::impl_createSeriesShapes() at chart2/source/view/charttypes/AreaChart.cxx:539:17 > #3 in chart::AreaChart::createShapes() at chart2/source/view/charttypes/AreaChart.cxx:965:5 > #4 in chart::ChartView::impl_createDiagramAndContent(chart::CreateShapeParam2D const&, com::sun::star::awt::Size const&) at chart2/source/view/main/ChartView.cxx:1608:25 > #5 in chart::ChartView::createShapes2D(com::sun::star::awt::Size const&) at chart2/source/view/main/ChartView.cxx:3037:41 > #6 in chart::ChartView::createShapes() at chart2/source/view/main/ChartView.cxx:2506:5 [...] Leaving aRSquared initialized to 0.0 when the divisor is zero is in line with the code prior to 00cb825ab3f16a94f1e8311ba0c24f72588e788e "fdo#75538 R^2 calculation for trendline similar to LINEST function" and with the recent nearby change f44d14e5f3909a4271034ba02da92ed2dee7b89c "Avoid -fsanitize=float-divide-by-zero". Change-Id: If2c17ad178788982729f647b4c695d3788fad500 Reviewed-on: https://gerrit.libreoffice.org/74068 Tested-by: Jenkins Reviewed-by: Laurent BP <laurent.balland-poirier@laposte.net> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-06-14Avoid -fsanitize=float-divide-by-zeroStephan Bergmann1-1/+4
...as happens with `--convert-to pdf xls/rhbz499466-2.xls` with xls/rhbz499466-2.xls as obtained by bin/get-bugzilla-attachments-by-mimetype (i.e., the attachment at <https://bugzilla.redhat.com/show_bug.cgi?id=499466#c1>): > chart2/source/tools/PolynomialRegressionCurveCalculator.cxx:73:14: runtime error: division by zero > #0 in chart::PolynomialRegressionCurveCalculator::recalculateRegression(com::sun::star::uno::Sequence<double> const&, com::sun::star::uno::Sequence<double> const&) at chart2/source/tools/PolynomialRegressionCurveCalculator.cxx:73:14 > #1 in chart::VSeriesPlotter::createRegressionCurvesShapes(chart::VDataSeries const&, com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, bool) at chart2/source/view/charttypes/VSeriesPlotter.cxx:1341:22 > #2 in chart::AreaChart::impl_createSeriesShapes() at chart2/source/view/charttypes/AreaChart.cxx:539:17 > #3 in chart::AreaChart::createShapes() at chart2/source/view/charttypes/AreaChart.cxx:965:5 > #4 in chart::ChartView::impl_createDiagramAndContent(chart::CreateShapeParam2D const&, com::sun::star::awt::Size const&) at chart2/source/view/main/ChartView.cxx:1608:25 > #5 in chart::ChartView::createShapes2D(com::sun::star::awt::Size const&) at chart2/source/view/main/ChartView.cxx:3037:41 [...] Change-Id: I1ef70aa90256a5fcc84151d869d8ffc6acfbbb0e Reviewed-on: https://gerrit.libreoffice.org/74055 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-06-14Avoid -fsanitize=signed-integer-overflowStephan Bergmann1-1/+1
...as happens when loading xls/fdo76137-3.xls as obtained by bin/get-bugzilla-attachments-by-mimetype (i.e, the attachment at <https://bugs.documentfoundation.org/show_bug.cgi?id=76137#c6>): > chart2/source/view/charttypes/PieChart.cxx:1110:81: runtime error: signed integer overflow: 2025540036 + 157276681 cannot be represented in type 'int' > #0 in chart::PieChart::rearrangeLabelToAvoidOverlapIfRequested(com::sun::star::awt::Size const&) at chart2/source/view/charttypes/PieChart.cxx:1110:81 > #1 in chart::ChartView::impl_createDiagramAndContent(chart::CreateShapeParam2D const&, com::sun::star::awt::Size const&) at chart2/source/view/main/ChartView.cxx:1651:23 > #2 in chart::ChartView::createShapes2D(com::sun::star::awt::Size const&) at chart2/source/view/main/ChartView.cxx:3037:41 Change-Id: I52a8363db2ca37dbcf56e1c136d9ee2223add945 Reviewed-on: https://gerrit.libreoffice.org/74048 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-06-14Avoid -fsanitize=float-divide-by-zeroStephan Bergmann1-1/+1
...as happens with `--convert-to pdf xls/fdo53482-2.xls` with xls/fdo53482-2.xls as obtained by xls/fdo53482-2.xls (i.e., the attachment at <https://bugs.documentfoundation.org/show_bug.cgi?id=53482#c25>): > chart2/source/tools/PolynomialRegressionCurveCalculator.cxx:190:38: runtime error: division by zero > #0 in chart::PolynomialRegressionCurveCalculator::recalculateRegression(com::sun::star::uno::Sequence<double> const&, com::sun::star::uno::Sequence<double> const&) at chart2/source/tools/PolynomialRegressionCurveCalculator.cxx:190:38 > #1 in chart::VSeriesPlotter::createRegressionCurvesShapes(chart::VDataSeries const&, com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, bool) at chart2/source/view/charttypes/VSeriesPlotter.cxx:1341:22 > #2 in chart::AreaChart::impl_createSeriesShapes() at chart2/source/view/charttypes/AreaChart.cxx:539:17 > #3 in chart::AreaChart::createShapes() at chart2/source/view/charttypes/AreaChart.cxx:965:5 > #4 in chart::ChartView::impl_createDiagramAndContent(chart::CreateShapeParam2D const&, com::sun::star::awt::Size const&) at chart2/source/view/main/ChartView.cxx:1608:25 > #5 in chart::ChartView::createShapes2D(com::sun::star::awt::Size const&) at chart2/source/view/main/ChartView.cxx:3037:41 The division aSumError/aSumTotal is there ever since the code's introduction in e6a0cc2d6cb37bf4e04861173c7e55b307513778 "fdo#35712 polynomial and moving average regression lines", and quikee suggested this fix on IRC. Change-Id: Ic9cd7b8aaa8451e1230fca8137bad29e28f6477f Reviewed-on: https://gerrit.libreoffice.org/74036 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-06-14Extend debug-mode timeoutStephan Bergmann1-3/+7
`--convert-to pdf xls/fdo37212-1.xls`, with xls/fdo37212-1.xls as obtained by bin/get-bugzilla-attachments-by-mimetype (i.e., the attachment at <https://bugs.documentfoundation.org/show_bug.cgi?id=37212#c0>) needs a timeout of more than 5 min for my plain --enable-dbgutil build and a timeout of more than 10 min for my ASan+UBSan --enable-dbgutil build. Change-Id: Ia20140049a2f95c4ac006860599e07687cc594eb Reviewed-on: https://gerrit.libreoffice.org/73997 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-26 09:22:47 +0000