summaryrefslogtreecommitdiff
path: root/writerfilter/source
AgeCommit message (Collapse)Author
2023-01-20related tdf#125038 FORMTEXT/REF:fix spurious text outside IF fieldJustin Luth
This builds on top of commit d09336fbdceaafd9320466b660a2b32a07dcc16a (tdf#125038 DOCX import: fix lost MERGEFIELD result inside an IF field, 2019-10-31), and extends it for FORMTEXT and REF. With this, all unexpected content is gone from the paragraph. Actually this is all somewhat irrelevant since DOCX doesn't import IF fields at all anyway - they are just left blank. So AFAICS, we should ALWAYS return false at this point. I also took the opportunity to be able to remove multiple spaces from the front of the command. Change-Id: Ib7e7971bce86bdda545166e398fbb620ca515b91 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145832 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-01-20NFC writerfilter: avoid unnecessary code processingJustin Luth
Early return on useless parameter, and conditional processing on missing ID. Change-Id: Iecf2d7522bd0c1e958f826214368966399be311c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145831 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-01-19Fix typoAndrea Gelmini
Change-Id: Iba92ac9d7093b7fd8d6d61be2496333ad1d8b59d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145815 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-01-18tdf#153082 writerfilter,sw: import/export locale-dependent TOC ...Michael Stahl
... \t style name separators. OOXML says in 17.16.5.68 TOC: \t field-argument Uses paragraphs formatted with styles other than the built-in heading styles. text in this switch's field-argument specifies those styles as a set of comma-separated doublets, with each doublet being a comma-separated set of style name and table of content level. The reality is documented in Word online help: https://support.microsoft.com/en-us/office/field-codes-toc-table-of-contents-field-1f538bc4-60e6-4854-9f64-67754d78d05c?ui=en-US&rs=en-US&ad=US Note: Syntax shown here uses a comma (,) between the Style and Level parameters. A semicolon (;) is also valid, depending on which character is specified as the list separator in your operating system's regional and language settings. Because of language-specific dependencies, we recommend not using the \t switch in templates or documents that are intended for users across multiple language configurations. It's easy enough to recognize both ',' and ';' as separators on import, and unlikely that anybody would use these characters inside a style name; for export, both can't be written and a decision must be made. So do the same thing on export as Word does, assuming most document exchange is between users in the same locale; currently only for "de" locales but more can be added. Interestingly WW8 used to write ';' before 2009 when CWS hb32bugs01 changed it to ','. Change-Id: I2dcfdd009f448f6fae37cbd28929d0bbe504acf9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145744 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-01-18tdf#153082 writerfilter: import locale-dependent TOC \t style namesMichael Stahl
The bugdoc contains this style: <w:style w:type="paragraph" w:styleId="IntensivesZitat"> <w:name w:val="Intense Quote"/> <w:basedOn w:val="Standard"/> <w:next w:val="Standard"/> <w:link w:val="IntensivesZitatZchn"/> ... which is referred to by: TOC \o "1-3" \h \z \t "Intensives Zitat;3;Custom1;3;_MyStyle0;3" Word in an "en" locale is unable to match the "Intensives Zitat" in the TOC field with the style "Intense Quote", which is a built-in style in Word (no equivalent in Writer). At first glance nothing in styles.xml matches the localised built-in style name in the TOC field. But it looks like the w:styleId value is somehow generated from the localised style name by omitting certain characters like SPACE and non-ASCII letters. Change-Id: I2050f7cf7f8d80bee1f667ee53b7f9981bbf7b49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145745 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-01-18tdf#119229 docx: Preserve w15:paraIdParent attribute in commentsExtendedParis Oplopoios
w15:paraIdParent attribute indicates that the comment is a reply to the value id Change-Id: I9e6eca6a656594c956629c1434b8e5c3aa573c60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145314 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-01-13tdf#131386 writerfilter: RTF import paragraph mark formattingMichael Stahl
One obstacle was remove in commit 02f53bd61222d7999b847a22fd24d65195f129e5 To fix it, when \par is handled, runProps() just has to be called unconditionally. Now one test fails with: rtfexport5.cxx:438:Assertion Test name: testTdf107413::Load_Verify_Reload_Verify equality assertion failed - Expected: 14578 - Actual : 14698 The spacing above the first paragraph in the table in the footer is not imported - because this is recorded in a buffer, and when replaying, getProperties() is called with Id 0, and not LN_Value_ST_StyleType_character as when it's called immediately without buffering. Change-Id: If86ed2fa88eb2ac0eafd7a8be411bbfa341619b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145490 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-01-13tdf#152952 sw: don't hyphenate URLs by defaultMichael Stahl
New compatibility flag HyphenateURLs, disabled by default for Word interop and enabled for old ODT documents. Change-Id: I1496819599deb5ed0fd736698d269ab9a22167fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145415 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-01-13ooxml: fix theme color type mapping: bg -> light, text -> darkTomaž Vajngerl
Change-Id: I19ad3ef7c911943075d7ddc01626047cdf11d5db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145070 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-13introduce {Char,Fill}ColorThemeReference which uses XThemeColorTomaž Vajngerl
Adds a unified UNO property for theme colors *ColorTheme (CharColorTheme and FillColorTheme) which uses XThemeColor, that replaces the properties *Theme, *TintOrShade, *LumOff, *LumMod. The properties are still present for backwards compatibility and to keep ODF support working in tests as that needs a bigger change. Reactor the code and tests to accomodate for this change. Change-Id: If7983decb4ba528b49fe7b5968aa9efc696a9efc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144783 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-12tdf#152425 Synchronize import and export style names mappingMike Kaganski
1. Make the mapping in StyleSheetTable::ConvertStyleName match the opposite direction mapping happening in MSWordStyles::GetWWId and ww::GetEnglishNameFromSti. Add missing styles, provide comments to clarify the process and find respective pool format ids. 2. Instead of appending " (user)" to conflicting style names, which is the method used by SwStyleNameMapper to disambiguate API names, append " (WW)", which allows to avoid unwanted merging conflicting styles. Change-Id: I47b1c7f570da6e6e21155669fdd1b77de5cc17da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145349 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-01-10tdf#103956: RTF import: fix for \cellx0 or no params.Vasily Melenchuk
If cell width is not given or zero lets not confuse it with too narrow cell. Lets keep zero to allow domain mapper define some width. This patch does not solves autofit issue completely, but finally tables with autofit are visible somehow and do not contain cells with minimal almost invisible width (41). Change-Id: I640228ed117f1d65dde9753a00b8403dda45dd40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145148 Tested-by: Jenkins Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
2023-01-09tdf#148578: Do not apply table shift for RTFVasily Melenchuk
Table shift based on cell lect margin should be applied for DOCX (earlier compat options) but not actual for RTF. Maybe earlier RTF version did behave this way, but nowadays this behavior does not match MS Word 365. Change-Id: Icdc4fa6298167fe5f263c85164d7c4c4176be25f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145088 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-01-06tdf#152784: RTF import: more default paragraph paramsVasily Melenchuk
If numbering is not explicitly mentioned in para properties it should not be used from referred paragraph style. So default value of 0 (no numbering) is used by default. Change-Id: If8e8f2aaf19190f64a557444188f67b24a699b54 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144839 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-01-06writerfilter: removed remains of GAP_HALF define and its usageVasily Melenchuk
Change-Id: I8dee16f923686f557c8213d9a7870392bd5fe9bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145090 Tested-by: Jenkins Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
2023-01-06tdf#152884 import alpha too for schemeClrRegina Henschel
Without fix the alpha child element was only read for w14:srgbClr but no for w14:schemeClr. Thus character colored by theme color had no transparency. Change-Id: I73c01b7142d3eab83400d2e5eb9dce01ff8d4a19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145099 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-01-05tdf#131203 DOCX import: fix lost table when w:tblGrid is missingLászló Németh
Load tables in case of incomplete text table definition, i.e. missing w:tblGrid and its w:gridCol elements, like MSO does. Note: Apache POI, and maybe old MSO versions generated such DOCX documents. divide_by_zero() was thrown from 975884fbbc3f80a634258ee562037688a42027a9 "ofz#7110 ensure join is called on std::exceptions as well as uno::Exception". See also commit 9279b0bb5397d0520b727ab0d271f328807c8749 "writerfilter: avoid divide by zero" and commit 116cadb5d2582532c69677a2f8499e8e9b7b9b80 "tdf#59274 DOCX import: fix tables with incomplete grid". Change-Id: I991807da13e22e551f81c3fb60580be7a9c0fb50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145069 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2023-01-05Revert all the recent loplugin:unocast changesStephan Bergmann
...as obsoleted by ef533553559fe09b4afab651fc692885d1acf4ed "Rudimentary support for dynamic_cast on UNO proxy objects". This reverts all of: 4cfcc9ac37b90ce64c8402a41eb4638adb185b5c "loplugin:unocast (framework::Desktop)" 03efbf72f4ddf7a84aa8aabef348331bd4b75e8a "loplugin:unocast (vclcanvas::TextLayout)" 80099fdd51a69eaa6c36ca88ef772810e4a777fa "loplugin:unocast (SalGtkXWindow)" cc147f576d8687fb79c77d47d41dc4ba1678a469 "loplugin:unocast (sdext::presenter::CachablePresenterView)" 40db42be1d8fd0f9c6c8c5ba3767ddb9ee2034c2 "loplugin:unocast (vclcanvas::CanvasFont)" 2d1e7995eae29e2826449eb5179f5fae181794a5 "loplugin:unocast (CairoColorSpace)" 4c0bbe4bd97636207cf71a6aa120c67698891da9 "loplugin:unocast (canvas::ParametricPolyPolygon)" 89803666621c07d1b1ac9d3bd883f0ca192a91a0 "loplugin:unocast (vclcanas::CanvasBitmap)" d5e0c2c8db71878d21c2a7255af08cf5f9a6dd04 "loplugin:unocast (sfx2::DigitalSignatures)" c0c4519e0d5b555f59bbc04cc616454edfd1f4ce "loplugin:unocast (VCLXAccessibleComponent)" feb8b833a6245d42400f42a0bc789dc84594ee6f "loplugin:unocast (VCLXDialog)" 1fa58cc6cc9c3849753342a5d9a6ddfa461b5e66 "loplugin:unocast (VCLXMultiPage)" f481f036deb1b1b46f3038074c4659f3a91b9c6c "loplugin:unocast (DocumentSettingsSerializer)" 73df933f5fa5932f94e5a1b338a3eda00a9ce354 "loplugin:unocast (css::embed::EmbeddedUpdate)" 420165ab0ef03c0467f9d17f504de2d2fc78f0e6 "loplugin:unocast (canvas::tools' StandardColorSpace, StandardNoAlphaColorSpace)" 9abe8ee067e6c00f19d8a13346d53c4641c27166 "loplugin:unocast (MutableTreeNode)" 9f3022ceb036f23b4b0994c3e2fbd1001bff225a "loplugin:unocast (VCLXTabPage)" 1be70dda02c12a60778b7607cff2520ae1aa611e "loplugin:unocast (vcl::unotools::VclCanvasBitmap)" d6a70bb641b96e8e5616448c2378131ed62658b4 "loplugin:unocast (basegfx::unotools::UnoPolyPolygon)" 5a14f009e6782c077463c8cbb8e9cea3d7950107 "loplugin:unocast (xmlsecurity::Certificate)" 99009c9535dfa3e0d838989ccc7d84bfa2320ff4 "loplugin:unocast (sd::Annotation)" 0c7585c5fa78887e5459885ed744e8044fd76137 "loplugin:unocast (sd::TextApiObject)" 24e14afd1bfcaed6c200ab081973fba7e47267ca "loplugin:unocast (SignatureVerifierImpl)" 1a7ad0c10d286ce9ae2700ceb2fd50eed1fb43a4 "loplugin:unocast (pcr::PropertyEventTranslation)" a97e2d2702d9a6f37775ccee2c08c4f3b2479c4b "loplugin:unocast (RangePageBreaks)" 19dfdf86ad1f5b08041d8b7a9f196caf881231ab "iloplugin:unocast (pcr::OFormattedNumericControl)" f9785ea595fd8e911f6370e836fa579225b9e571 "loplugin:unocast (frm::OInterfaceContainer)" 5e5f40a4a92a31b0932c690219d002fcf18598cf "loplugin:unocast (ScVbaShapes)" 27b35b2c215b4832d4378ec3a7ecbba926552d06 "loplugin:unocast (ScVbaShapeRange)" cb3108f860065928552a86cf8acc4b3a95718ecf "cid#1517812 Dereference null return value" feba0ddb1521d1142560fe54b7d7696ee910237f "loplugin:unocast (weld::TransportAsXWindow)" 4d6c23216559eb48f9943bb49d6e475a6d64ba15 "loplugin:unocast (oox::ForumlaImExportBase)" 4844c096a8ab6a9a620c410a0949d4499f12a504 "loplugin:unocast (cairocanvas::SurfaceProvider)" 9a0b523e0a84d403b9092176ccec4b3e3efe42d0 "loplugin:unocast (cairocanvas::CanvasBitmap)" 8a5648d8e59b4b007dbbf3824777c19a21efc61e "loplugin:unocast (cairocanvas::TextLayout)" 28c27a0623bc78a0590858f97d03b620985bc84c "loplugin:unocast (cairocanvas::CanvasFont)" 53bc223cb3288e32a417696ee61c29e5f01f209d "loplugin:unocast (cairocanvas::RepaintTarget)" 5f70b0b9f6bc4ab145ddbd9155590ed4a3b1b9ec "loplugin:unocast (SvXMLImport)" 068187a898cdd2e26e9b16c348ecc1ed2dee3f29 "loplugin:unocast (VCLXWindow)" 88b4f966202717cd4ad38a30a8eda22c3e69ed35 "loplugin:unocast (sfx2::sidebar::SidebarController)" f1b7a69b280aefe2f1b3b0f32193494fd765f2bd "loplugin:unocast (SvxLineStyleToolBoxControl)" ba76f0ba7e8de4d2953739c952004b7d9af47197 "loplugin:unocast (i18npool::Calendar_gregorian)" 840154daf934d8df52ead1cb7acd798c4d30f007 "loplugin:unocast (framework::AddonsToolBarWrapper)" b0e9c4c5f063cefa9557810e3349bdb9c7493091 "loplugin:unocast (GrammarCheckingIterator)" 8ee6cfc9655ce9de4617cea1a0d9cb9d7a4fbfac "loplugin:unocast (ucb::ucp::ext::Content)" 5b8cd77c112bc8c0e92b8fec215c3c8e802bbc0a "loplugin:unocast (basic::SfxScriptLibraryContainer)" 9e73ff9fce12e102bb3c3cea8d8bb96c88f2c9ad "loplugin:unocast (sdext::presenter::PresenterNotesView)" a98acca8fbc38d3fd5600ae5056a8e42b6d8a40d "loplugin:unocast (SelectionChangeHandler)" c0b59ad6e35b0cb0dea0821e95f95569739078c1 "Consistently use comphelper::getSomethingImpl<I>(aIdentifier, this)" 276e3ccbdd3259ec3daf8a1a98fa7f406b14e21c "loplugin:unocast (vclcanvas::RepaintTarget)" Change-Id: I37c73e3422a5154bf6cb647640d2d3f23db8bc34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145063 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-03docx: Preserve w15:appearance SdtPr attributeofftkp
Now roundtrips the w15:appearance value which dictates whether there's an effect when hovering a placeholder. Change-Id: I3c911a0cfe31e235b9d981bbff0c1bb5827a85ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144845 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-01-01sw: read theme from OOXML file and set it to the draw pageTomaž Vajngerl
This change extends writerfilter to use oox::ThemeFragmentHandler to read the theme properties, and sets that to the one and only draw page of a Writer document. This change also removes ThemeTable and replaces it with the ThemeHandler, which takes theme font data from svx::Theme instead. In addition, a test has been writen, which loads a document with a theme, and asserts the draw page has the theme and the theme properties currently supported. Change-Id: Iff0048cd21ea030ac55287707852acc463ec3cb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143699 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-29ms format import: better handling for invalid stylesVasily Melenchuk
If referred paragraph style is not found or it is not a paragraph style, this can lead to exceptions in writer core and thus current paragraph can be not corretly initialized. For example, numbering can be not applied because of exception of not found style earlier. This is not a critical error, we should just not apply a style we could not resolve. Of course such documents are invalid but bit more tolerance to errors will not harm. Change-Id: I9150786e6357a7d6098440bac29ec501fc6aa802 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144852 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2022-12-29Properly print floatsStephan Bergmann
...avoiding > /writerfilter/source/dmapper/PropertyMap.cxx:324:71: runtime error: -2539 is outside the range of representable values of type 'unsigned int' > #0 0x7f80e9a3b6c3 in writerfilter::dmapper::PropertyMap::dumpXml() const /writerfilter/source/dmapper/PropertyMap.cxx:324:71 > #1 0x7f80e928eccb in writerfilter::dmapper::DomainMapperTableHandler::endTableGetTableStyle(writerfilter::dmapper::TableInfo&, std::__debug::vector<com::sun::star::beans::PropertyValue, std::allocator<com::sun::star::beans::PropertyValue> >&, bool) /writerfilter/source/dmapper/DomainMapperTableHandler.cxx:434:40 > #2 0x7f80e92b4b8f in writerfilter::dmapper::DomainMapperTableHandler::endTable(unsigned int, bool) /writerfilter/source/dmapper/DomainMapperTableHandler.cxx:1377:30 > #3 0x7f80e9c289de in writerfilter::dmapper::TableManager::resolveCurrentTable() /writerfilter/source/dmapper/TableManager.cxx:409:33 > #4 0x7f80e9c297a1 in writerfilter::dmapper::TableManager::endLevel() /writerfilter/source/dmapper/TableManager.cxx:427:9 > #5 0x7f80e936a997 in writerfilter::dmapper::DomainMapperTableManager::endLevel() /writerfilter/source/dmapper/DomainMapperTableManager.cxx:497:19 > #6 0x7f80e9c256d1 in writerfilter::dmapper::TableManager::endParagraphGroup() /writerfilter/source/dmapper/TableManager.cxx:338:9 > #7 0x7f80e9205974 in writerfilter::dmapper::DomainMapper::lcl_endParagraphGroup() /writerfilter/source/dmapper/DomainMapper.cxx:3511:35 > #8 0x7f80e984598e in writerfilter::LoggedStream::endParagraphGroup() /writerfilter/source/dmapper/LoggedResources.cxx:108:5 > #9 0x7f80e9d9addf in writerfilter::ooxml::OOXMLFastContextHandler::endParagraphGroup() /writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:452:23 > #10 0x7f80ea042658 in writerfilter::ooxml::OOXMLFactory_wml::endAction(writerfilter::ooxml::OOXMLFastContextHandler*) /workdir/CustomTarget/writerfilter/source/ooxml/OOXMLFactory_wml.cxx:7574:19 > #11 0x7f80e9d8822a in writerfilter::ooxml::OOXMLFactory::endAction(writerfilter::ooxml::OOXMLFastContextHandler*) /writerfilter/source/ooxml/OOXMLFactory.cxx:157:19 > #12 0x7f80e9d944eb in writerfilter::ooxml::OOXMLFastContextHandler::lcl_endFastElement(int) /writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:242:5 > #13 0x7f80e9d941da in writerfilter::ooxml::OOXMLFastContextHandler::endFastElement(int) /writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:225:9 > #14 0x7f80f44ffe2a in (anonymous namespace)::Entity::endElement() /sax/source/fastparser/fastparser.cxx:515:27 > #15 0x7f80f44ff818 in sax_fastparser::FastSaxParserImpl::callbackEndElement() /sax/source/fastparser/fastparser.cxx:1343:17 > #16 0x7f80f44ef554 in (anonymous namespace)::call_callbackEndElement(void*, unsigned char const*, unsigned char const*, unsigned char const*) /sax/source/fastparser/fastparser.cxx:339:18 > #17 0x7f8179cde54a in xmlParseEndTag2 /workdir/UnpackedTarball/libxml2/parser.c:9742:2 > #18 0x7f8179c8ced0 in xmlParseTryOrFinish /workdir/UnpackedTarball/libxml2/parser.c:11642:14 > #19 0x7f8179c7acc9 in xmlParseChunk /workdir/UnpackedTarball/libxml2/parser.c:12351:13 > #20 0x7f80f44ea4f1 in sax_fastparser::FastSaxParserImpl::parse() /sax/source/fastparser/fastparser.cxx:1099:21 > #21 0x7f80f44e4146 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun::star::xml::sax::InputSource const&) /sax/source/fastparser/fastparser.cxx:904:9 > #22 0x7f80f4505300 in sax_fastparser::FastSaxParser::parseStream(com::sun::star::xml::sax::InputSource const&) /sax/source/fastparser/fastparser.cxx:1482:13 > #23 0x7f80e9d46e98 in writerfilter::ooxml::OOXMLDocumentImpl::resolve(writerfilter::Stream&) /writerfilter/source/ooxml/OOXMLDocumentImpl.cxx:508:18 > #24 0x7f80e9cfed05 in (anonymous namespace)::WriterFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /writerfilter/source/filter/WriterFilter.cxx:208:24 > #25 0x7f8149202866 in SfxObjectShell::ImportFrom(SfxMedium&, com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) /sfx2/source/doc/objstor.cxx:2272:34 > #26 0x7f81491c2434 in SfxObjectShell::DoLoad(SfxMedium*) /sfx2/source/doc/objstor.cxx:739:23 > #27 0x7f81493c9870 in SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /sfx2/source/doc/sfxbasemodel.cxx:1937:36 > #28 0x7f8149b20d71 in (anonymous namespace)::SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) /sfx2/source/view/frmload.cxx:720:28 > #29 0x7f810e00256b in framework::LoadEnv::impl_loadContent() /framework/source/loadenv/loadenv.cxx:1167:37 > #30 0x7f810dff896b in framework::LoadEnv::start() /framework/source/loadenv/loadenv.cxx:403:20 > #31 0x7f810dff0dec in framework::LoadEnv::startLoading(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, rtl::OUString const&, int, LoadEnvFeatures) /framework/source/loadenv/loadenv.cxx:308:5 > #32 0x7f810dfec180 in framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/loadenv/loadenv.cxx:168:14 > #33 0x7f810e0b541d in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/services/desktop.cxx:604:16 > #34 0x7f810e0b5646 in non-virtual thunk to framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/services/desktop.cxx > #35 0x7f812a050c25 in unotest::MacrosTest::loadFromDesktop(rtl::OUString const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /unotest/source/cpp/macros_test.cxx:70:62 > #36 0x7f81444fcad9 in UnoApiTest::load(rtl::OUString const&, char const*) /test/source/unoapi_test.cxx:115:11 > #37 0x7f812a8ae042 in SwModelTestBase::loadURL(rtl::OUString const&, char const*, char const*) /sw/qa/unit/swmodeltestbase.cxx:449:20 > #38 0x7f812a8b9452 in SwModelTestBase::load(char const*, char const*) /sw/qa/inc/swmodeltestbase.hxx:351:16 > #39 0x7f812a8af516 in SwModelTestBase::loadAndSave(char const*) /sw/qa/unit/swmodeltestbase.cxx:502:5 > #40 0x7f814fcfe242 in testTableThemePreservation::TestBody() /sw/qa/extras/ooxmlexport/ooxmlexport3.cxx:888:5 during CppunitTest_sw_ooxmlexport3 (<https://ci.libreoffice.org//job/lo_ubsan/2629/>). (The overload for is_integral parameters is needed now to avoid ambiguity errors when integer types other than sal_uInt32 could also match the newly added float overload.) Change-Id: I6482bccef2442655359c71e13f0c9bfe7e4d9dd4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144855 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-25sw: support for reading back theme color from OOXMLTomaž Vajngerl
OOXML supports theme colors and tint/shade value that additionally changed the theme color. Read back which theme color + tint/shade value was applied in the resulting color and add this attributes as properties to be used by writer. In sidebar theme panel the changing the theme colors now doesn't takes this into account and changes the colors correctly. Change-Id: I3a2d49d485fd37a1611483ee0bb5e6034ac5f88e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143697 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-21ofz#54461 Null-dereferenceCaolán McNamara
seen since: commit 96a856f87f16cca2e039c973c18d57c8b9dca362 Date: Fri Dec 16 13:20:25 2022 +0100 tdf#152206 DOCX import: fix mixed first footnote Note: tdf#152506 is the correct issue identifier. Change-Id: I6e66db1a6a87cfce444346f193a418880750e03c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144692 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-20writerfilter: fix crash in DomainMapper_Impl::convertFieldFormula()Miklos Vajna
Crashreport signature: program/libwriterfilterlo.so writerfilter::dmapper::SettingsTable::GetListSeparator() const writerfilter/source/dmapper/SettingsTable.cxx:489 program/libwriterfilterlo.so writerfilter::dmapper::DomainMapper_Impl::convertFieldFormula(rtl::OUString const&) include/rtl/ustring.hxx:226 program/libwriterfilterlo.so writerfilter::dmapper::DomainMapper_Impl::handleFieldFormula(tools::SvRef<writerfilter::dmapper::FieldContext> const&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&) include/rtl/ustring.hxx:527 program/libwriterfilterlo.so writerfilter::dmapper::DomainMapper_Impl::CloseFieldCommand() writerfilter/source/dmapper/DomainMapper_Impl.cxx:6458 Change-Id: I7f48f76cacffa00d633d92f0a51b2d82f96d1e74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144592 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-12-19loplugin:unocast (oox::ForumlaImExportBase)Stephan Bergmann
(See the upcoming commit introducing that loplugin:unocast on why such dynamic_casts from UNO types are dangerous.) Change-Id: I11bc363447c44319bc47f7eebb7084f64ea85511 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144400 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-19tdf#152206 DOCX import: fix mixed first footnoteLászló Németh
Also the first footnote can be at arbitrary place in footnote.xml. Follow-up to commit 09ae3c01940bbc25ffde51963683b04e3cb4bb6a "tdf#152203 DOCX import: fix mixed footnotes/endnotes". Change-Id: Iab356f7373483d812f0e802a994357fdad831d9d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144380 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2022-12-18Combine oox::FormulaIm-/ExportBaseStephan Bergmann
The original classes were both only used as base classes of SmModel, and combining them will make it easier to replace the existing dynamic_casts to those classes with XUnoTunnel. (And see the upcoming commit introducing loplugin:unocast on why those dynamic_casts are dangerous.) Change-Id: I4b1e0594fb202e3423d57db6457aa0e1b1b0b612 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144353 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-16Revert "fix math export/import in docx/rtf"Stephan Bergmann
This reverts commit 2b5953a19e36a02040f2ff08bc87efe4785f80bd. Whatever that "gcc4.4 (and 4.3 and possibly older) have a problem with dynamic_cast directly to the target class" issue actually was: For one, our GCC 7 baseline presumably would no longer have such an issue. And for another, the added asserts that the results of the dynamic_casts must be non-null were presumably all bogus (and have in part been reverted again in the meantime), as all the sources are UNO interface types that can presumably point at implementation objects of other than the expected C++ class types. (Those dynamic_casts from UNO interface types will be addressed in a follow-up commit. See the upcoming commit introducing loplugin:unocast on why such dynamic_casts are dangerous.) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport.cxx sw/qa/extras/rtfexport/rtfexport.cxx sw/source/filter/ww8/docxattributeoutput.cxx sw/source/filter/ww8/rtfattributeoutput.cxx writerfilter/Library_writerfilter.mk writerfilter/source/ooxml/OOXMLFastContextHandler.cxx writerfilter/source/rtftok/rtfdocumentimpl.cxx Change-Id: I0c330a3541e64ce08bfe30ff15d51a2fd8a243b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144336 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-16sw content controls: enhance preserve idJustin Luth
Follow-up to 100c914d44ae8f362924fe567d7d41d0033ae8ad which added the initial id preservation for DOCX. adding DOCX block SDT grabbaging, ODF import/export [content controls can't exist in DOC format] The ID field is CRITICAL to preserve for VBA purposes. This patch adjusts BlockSDT to also round-trip the id instead of just creating a random one. m_nRunSdtPrToken <never equals> FSNS(XML_w, XML_id) since 2021 with 5f3af56b2c0ef6c628a7cfe5ce6e86f8e1765f5f, so I removed that part of the clause. I had thought about changing the ID to use a string instead of an int, but then the integer version was adopted to fix a regression in the commit mentioned earlier. I think it is AWFUL to have a number as the identifier when it will be used in StarBASIC. The VBA guys have to deal with it, but it would be nice to do something reasonable for LO native access to content controls. However, the concern would be if we allow VBA macro content created in LO to be exported to DOCX format - that would cause problems converting from a string ID to a number ID. VBA editing already is happening to some extent, and mmeeks seems interested in enabling it. So over-all it seems best to just stick with an integer ID. I used the commits for <w:alias> and <w:tag> to compose this patch. XML_ID already existed in include/xmloff/xmltoken.hxx and "id" already exists in xmloff/source/token/tokens.txt The ID can be used in VBA to select a specific control. The id (which is a positive or negative integer in DOCX) specifies a unique control - either by passing the number as a string (of the UNSIGNED value) or by passing as a float (specified with #). For example: msgbox ActiveDocument.ContentControls(2587720202#).ID msgbox ActiveDocument.ContentControls("2587720202").ID but not as an integer since that is used for index access. dim index as integer index = 1 msgbox ActiveDocument.ContentControls(index).ID make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf151912 make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport Change-Id: I5c4022dc932d941fad9da6d75ce899ee1ff66ff5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142818 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-12-14tdf#151548 sw content controls: preserve tabIndexJustin Luth
This has to be vital to keyboard navigation. Certainly it is good to have it imported before we start to consider tab-movements for form controls. All tabIndex 1's are processed (in placement order) and then the 2's etc. 0's are to be done last. XML_TAB_INDEX already existed in include/xmloff/xmltoken.hxx and "tab-index" already exists in xmloff/source/token/tokens.txt make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport No existing unit test found containing blockSDT with tabIndex. Change-Id: I8a958844e6192b079a2b22a62dedfd8739021f4a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143603 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-12-13tdf#151548 sw content controls: preserve lockJustin Luth
DOCX SdtControls can be locked in two ways: -Content Control cannot be deleted (sdtLocked) -Contents cannot be edited (contentLocked) or both (sdtContentLocked) make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText make CppunitTest_sw_ooxmlexport4 CPPUNIT_TEST_NAME=testSimpleSdts make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate make CppunitTest_sw_macros_test CPPUNIT_TEST_NAME=testVba make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport Change-Id: I5a82d9f6b5103a4902f59af66cd8a99addd4e690 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143542 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-12-13tdf#148035 sw content controls: cursor-move for runSdt onlyJustin Luth
For normal documents, just doing a Push/PopSdt on a block SDT seems to work out-of-the-box for checkbox/dropdown/date content controls. Apparently that is not the right way to do it though. When I was trying it, the first control was always "lost". This patch takes care of that. At the moment it does nothing since only runSdt's even call push/pop, but at least it might save some trouble later on when block SDTs are turned into content controls. Change-Id: I6bf68f296ca919dc09dec660c052ddbdb59d56bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144007 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2022-12-10tdf#152203 DOCX import: fix mixed footnotes/endnotesLászló Németh
Footnotes (like endnotes) were imported in the order of their w:footnote elements in footnotes.xml, resulting mixed footnote text content during loading documents exported from Google Docs. Import them in the order of their w:id attributes. Regression from commit 9b39ce0e66acfe812e1d50e530dc2ccdef3e1357 "tdf#76260 DOCX import: fix slow footnote import". Change-Id: I7d9ed36fe96b2b90c4d62fb1ca7201318581775d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143824 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2022-12-09Fix typoAndrea Gelmini
Change-Id: I96297815043ea213f67d0ccc4224b12d7bcf7d36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143887 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-12-09tdf#143311 offapi,oox,writerfilter,xmloff,sw: decorative flag on flysMichael Stahl
* sw core RES_DECORATIVE as a FRMATR * sw API SwXFrame property "Decorative" * UI checkbox "Decorative" * ODF import/export as loext:decorative on draw:frame * DOCX export * DOCX import - very non-obvious how to get it from model.xml to dmapper * PDF/UA export: tag flys with this flag as Artifact * test for DOCX filters, ODF filters, PDF export Change-Id: I1ceb67fdd4e1cfa212aafdeb1c5f4ccd873d433e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143815 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-12-09tdf#151548 sw content controls: preserve tag for block SDTsJustin Luth
The tag is critical for VBA access. Although we do not yet import blockSdts as content controls, losing this would break any VBA macros for MS Word. So make sure it round-trips. I can't imagine why it wasn't treated the same as alias. I guess because Alias is seen, while tag appears to have no valuable function (until VBA, where it becomes the most likely ID field.) Change-Id: I05a04faa9d2314c7b37c5b86f107bd1a16019509 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143830 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-12-09tdf#149240 docx content controls: round-trip showingPlcHdr betterJustin Luth
ShowingPlaceHolder causes all the text in the control to be selected when the control gains the focus. Otherwise, just a cursor is placed at the click point. While round-tripping this attribute worked for inline SDTs, it was lost for block SDTs. But BlockSDTs are very easy to create. The MS templates are full of them. Also, these are boolean, but it could have a val=0 specified, in which case it is off, but we were importing it as on. Change-Id: I167afa935311a63bba408ecd489ae819485a5cb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143818 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-11-30related tdf#152305 writerfilter: avoid comment-related exceptionsJustin Luth
a comment anchored in a table sees m_nTableDepth, but while in the comment it shouldn't affect the table itself. I did a search for m_nTableDepth and added !m_bIsInComments everywhere that looked reasonable. Change-Id: Iaaaf2f2b5a9f409146111b2e8546573c264e75ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143510 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2022-11-30tdf#152289: implement external glossary relations roundtripMike Kaganski
Change-Id: I20f4439abfbf73485734fd8373fffb2916d390f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143470 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-11-24tdf#152200: tolerate begin/end fldChar context mismatchMike Kaganski
We generate such files currently. Fixing that will be another commit. Change-Id: I788501e346cba63c08a767c0e05e063bc1172089 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143223 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-11-24tdf#151954 DOCX import: fix text moving before paragraph endLászló Németh
Tracked text moving before paragraph end was extended to the paragraph end, too. Follow-up to commit 11071d95f4f3cbe578c3393729c42b7cce011b45 "tdf#149711 sw_redlinenum DOCX: import moveTo paragraph mark" and commit d32d9a2b3c5e3963f4a18f6c7bbf50fab2e9b2be "tdf#123460 DOCX track changes: moveFrom completely". Change-Id: I668a3ef83482bded9ab94dcd0111f8ed05e8471c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143231 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2022-11-24Introduce ParagraphProeprtiesPropertyMapStephan Bergmann
StylePropertyMap and ParagraphPropertyMap should be has-a, not is-a ParagraphProperties. (I came across this with a tentative new loplugin flagging uses of dynamic_cast that implement cross casts between unrelated classes. This would silence that plugin, but also IMO makes intent more explicit here.) (And PropertyMap and ParagraphProperties no longer need their base classes to be virtual now.) Change-Id: Id89547f7824262b80e8a23c9c1d5ea6406dfcc9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143203 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-24No need for the base class to virtual hereStephan Bergmann
Change-Id: Ie8078340ece235c52529770bf393b264d8ca31db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143202 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-23cleanup SdtControlType::plainText - same as the other controls.Justin Luth
For a while, plainText needed special handling added in commit 9700c1b2170ad04453a361ed5647937833ac3c18 Date: Mon Jul 25 09:13:03 2022 +0200 sw content controls, plain text: add DOCX import But now it is treated the same as all the others and so can be lumped together with the other case statements since commit de90c192cb8f1f03a4028493d8bfe9a127a76b2a Date: Mon Sep 19 10:01:36 2022 +0200 sw content controls, plain text: enable DOCX filter with data binding Change-Id: Ie1ebe3873e8f49ae9747f1a77d08bfc0dec2d9f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142953 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2022-11-22DOCX filter: fix <w:id> creating both grab-bag and content control for <w:sdt>Miklos Vajna
Exporting the DOCX bugdoc back to DOCX resulted in a document that can't be opened in Word. Examining the output, the problem is that the document had 2 inline <w:sdt> elements with <w:id>, and we mapped such <w:sdt> elements to both grab-bags and content controls, leading to duplicate <w:sdt> elements on export. This is schema-valid, but it goes against the intention of the spec and Word can't open it. The initial fix was just a writerfilter/ tweak to avoid grab-bagging <w:id> for inline <w:sdt>, but CppunitTest_sw_ooxmlexport4's testSimpleSdts points out that in other cases we already require preserving <w:id>. Fix the problem by storing <w:id> in the content control, which is essentially a subset of <https://gerrit.libreoffice.org/c/core/+/142818>. Thanks to Justin Luth! - he prototyped the DOCX filter for <w:id>. Change-Id: I9f002b770049ce8be30253d0b39410d9a58981dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143117 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-11-18rename IsStarSymbol to IsOpenSymbolCaolán McNamara
Change-Id: If525ba9826f5bc2d860233cbabf58d1d290be054 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142936 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-11-18sw content controls: fix SdtHelper missing clear() itemsJustin Luth
Found during a code read, while attempting to add another property. Change-Id: I342c51c81f23e1e3178e7d412f9af685f3fd4ae2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142839 Tested-by: Justin Luth <jluth@mail.com> Reviewed-by: Justin Luth <jluth@mail.com>
2022-11-14Add some missing member operator== const qualifiersStephan Bergmann
...that were only detected now by GCC 13 trunk after <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=431be04b8b6e31d950ddab340ed866d197d23d4d> "c++: implement P2468R2, the equality operator you are looking for", > sc/source/core/tool/interpr4.cxx: In member function ‘void ScInterpreter::ScTableOp()’: > sc/source/core/tool/interpr4.cxx:3608:58: error: C++20 says that these are ambiguous, even though the second is reversed: [-Werror] > 3608 | bool bReuseLastParams = (mrDoc.aLastTableOpParams == aTableOp); > | ^~~~~~~~ > In file included from sc/inc/document.hxx:32, > from sc/inc/externalrefmgr.hxx:23, > from sc/source/core/inc/interpre.hxx:28, > from sc/source/core/tool/interpr4.cxx:22: > sc/inc/tabopparams.hxx:76:10: note: candidate 1: ‘bool ScInterpreterTableOpParams::operator==(const ScInterpreterTableOpParams&)’ > 76 | bool operator ==( const ScInterpreterTableOpParams& r ) > | ^~~~~~~~ > sc/inc/tabopparams.hxx:76:10: note: candidate 2: ‘bool ScInterpreterTableOpParams::operator==(const ScInterpreterTableOpParams&)’ (reversed) > sc/inc/tabopparams.hxx:76:10: note: try making the operator a ‘const’ member function etc. Change-Id: I0c55daabbce61aefd762862f3b0e2e5d235c34b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142698 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-14tdf#151993 DOCX import: convert decimal comma only if neededLászló Németh
E.g. convert en_US document with decimal comma, but not de_DE document with decimal comma. Regression from commit 94bf4908a6661101c270ef647e33dde09f16ac08 "tdf#148799 DOCX import: fix invalid formulas with comma". DOCX allows to set decimal symbol independently from the locale of the document, so if the DOCX document uses comma, but its locale ("language") has got a default decimal point in Writer, Writer formulas must contain decimal points instead of commas, otherwise automatic update of the formulas, e.g. moving text cursor in the table, results ** Expression is faulty ** instead of the recalculated value. The only way to get standard Writer formulas is to replace the commas with points in numbers in writerfilter, if document language has a default decimal point in Writer. Note: not only document language, but area setting of LibreOffice installation modifies formula handling. I.e. plain numbers recognized with comma only if area setting is modified to a language, which uses decimal comma (but formulas still need decimal points, if the language of the document is a locale with default decimal point). E.g. an en_US DOCX document with decimal comma, or a de_DE document with decimal comma loaded correctly now, but recognizing cell content with a single number with comma needs to set also the correct area setting. Change-Id: I16dba1e10bf4271a44c435b5b09345d8d698b91d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142611 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>