summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2017-10-23loplugin:includeform: writerfilterStephan Bergmann
Change-Id: Ic42219a7d733897ba47b26ffa0659c524798878e
2017-10-23overload std::hash for OUString and OStringNoel Grandin
no need to explicitly specify it anymore Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec Reviewed-on: https://gerrit.libreoffice.org/43567 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-21loplugin:redundantcast handle dynamic_castNoel Grandin
Change-Id: I7855c76e820efce96778b1c19ec71dffcc4b4abb Reviewed-on: https://gerrit.libreoffice.org/43621 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-10-20Resolves: tdf#113230 crash in finishParagraphCaolán McNamara
Change-Id: I94535a51a87be097ff7356edff935877b42c3272 Reviewed-on: https://gerrit.libreoffice.org/43598 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-10-19tdf#87533 Fixed initialization of writing mode for paragraphSerge Krot
During parsing of the docx the paragraph without w:bidi should take this value from style or from default paragraph properties, Change-Id: Ie33f0d1cd3551c4053a47e6faf7dcac71765db65 tdf#87533 explicitly set writing mode value based on default properties Change-Id: I3fcf514a901f0630d749ba0ddb6361d6db3ce1b5 Reviewed-on: https://gerrit.libreoffice.org/42895 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-10-19related tdf#87533: handle LN_EG_SectPrContents_bidi correctlySerge Krot
Change-Id: I90d220550d24fb964cf4e528a1f506033f05de95 Reviewed-on: https://gerrit.libreoffice.org/42896 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-10-18Fix typoAndrea Gelmini
Change-Id: Ie29a05fec90c0d81b4a0399505b0a6761dfdef69 Reviewed-on: https://gerrit.libreoffice.org/43463 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2017-10-18tdf#109306 ooxmlimport: consider table sizes < 10%Justin Luth
Change-Id: I336d5a498f4f4523e03b1316b7adaca21df4de82 Reviewed-on: https://gerrit.libreoffice.org/43385 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-10-17tdf#79272 ooxmlimport: support strict dxa tblWidthJustin Luth
This patch is also required for tdf#78508. ECMA-376-1:2016 indicates that MeasurementOrPercent is a union of ST_DecimalNumberOrPercent and ST_UniversalMeasure. For the elements that use MeasurementOrPercent, that is represented as 1/50 of a percent or in Twips. This patch adds support for the ST_UniversalMeasure component of the union. Change-Id: I1bac30707f118a3d1f0eab3c27f8dcec96470592 Reviewed-on: https://gerrit.libreoffice.org/43384 Tested-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-10-17tdf#104079 RTF import: fix handling fields inside TOC fieldsMiklos Vajna
The marker trick is not needed for these, but the paragraph margins are lost when using it, so avoid it. Change-Id: I3fc9644cb85138b5473cb1478196ae8538041fb1 Reviewed-on: https://gerrit.libreoffice.org/43446 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-10-16Inconsistent block / missing TblBorders_rightJustin Luth
Likely a copy/paste error, imported from OOo. Change-Id: I29713309164170e86f8e793e2f15a601ce2b5da7 Reviewed-on: https://gerrit.libreoffice.org/43431 Reviewed-by: Justin Luth <justin_luth@sil.org> Tested-by: Justin Luth <justin_luth@sil.org>
2017-10-11Fix typoAndrea Gelmini
Change-Id: Iab17008c8cc122176fb51b8766540d59cd681b35 Reviewed-on: https://gerrit.libreoffice.org/43316 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2017-10-10tdf#112211 RTF import: fix unwanted direct formatting for other indentsMiklos Vajna
Commit 56a695fddb915bcba13b088b5b2b4e0841d4acbc (tdf#112211 RTF import: fix unwanted direct formatting for left indents, 2017-09-26) fixed left indents, and given that it was a regression fix, left the other indent types untouched. As it has been pointed out in the bug comment, the original bugdoc actually needs the other indent types removed as well, so let's do that. Change-Id: Ia4ea7e2214b7df27536f46b046f90bd703c107be Reviewed-on: https://gerrit.libreoffice.org/43303 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-10-10tdf#66398 Parse and output permissions for DOCX using bookmarksSerge Krot
Change-Id: Id08998ae775c5f383edc4bf0410d16f88c70dfd6 Reviewed-on: https://gerrit.libreoffice.org/43275 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-10-10tdf#90789: DOCX paragraphs in shapes like frames do not belong to section.Vasily Melenchuk
Change-Id: I60644bd62e2a2ac97a97f0a492b146dc69456cd6 Reviewed-on: https://gerrit.libreoffice.org/43291 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-10-08Make Color a forward declarationChris Sherlock
Change-Id: Ib28833555661b119de8e967b05e3c8691fca826a Reviewed-on: https://gerrit.libreoffice.org/43227 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
2017-10-06related tdf#66398 remove useless breaksSerge Krot
Change-Id: I39caad06bcd645d582c180195a839113759b57a1 Reviewed-on: https://gerrit.libreoffice.org/43159 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-10-06tdf#66398 Import/export docx document protection propertiesSerge Krot
Added: + import/export of all doc protection properties + unit test Change-Id: I7b65cf4f5c7add2a96fef407c243081fcc2b6d8d Reviewed-on: https://gerrit.libreoffice.org/43156 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-10-05crashtesting: crash on import of abi3007-4.rtfCaolán McNamara
which started happending at... commit 56a695fddb915bcba13b088b5b2b4e0841d4acbc Date: Tue Sep 26 09:13:05 2017 +0200 tdf#112211 RTF import: fix unwanted direct formatting for left indents Change-Id: Id3e8c4452238b48495b1014eff14cdaddcb047ab Reviewed-on: https://gerrit.libreoffice.org/43172 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-10-05writerfilter: consistently use "" and <> in include directivesMike Kaganski
[cpp.include] tells that includes in <> are searched in implementation-defined places; includes in "" are searched in other implementation-defined places, and is unsuccessful, then as if they were in <>. MS VisualStudio IDE uses paths configured for the project for includes in <>, and starts with current file paths for includes in "". So, using <> for includes in current source file's directory missing from configured project paths makes IDE show unsuccessful includes and unknown identifiers. This fixes includes in writerfilter source directory. Change-Id: I0bc1147aa68c305afd0c119418f07b655783a466 Reviewed-on: https://gerrit.libreoffice.org/43138 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-10-04add << operator for css::uno::ExceptionNoel Grandin
Change-Id: Ia23dafd07133779144965682df3b7125a3214235 Reviewed-on: https://gerrit.libreoffice.org/43046 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>
2017-10-04loplugin:finalclasses in writerfilterNoel Grandin
Change-Id: I590de2fd15c630d5ea5e706ce9421ee8bfe19db7 Reviewed-on: https://gerrit.libreoffice.org/43116 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-03tdf#112507 RTF import: fix too narrow table cellMiklos Vajna
Commit e6ec0794858df1444f43659b568119bf126a90e6 (tdf#104937 RTF import: \trwWidthA is an absolute value, 2017-08-29) changed the handling of the fake empty cell at the end of table rows so that the parameter of the control word is an absolute, not a relative value. Turns out this wasn't correct, the DOCX equivalent of that bugdoc shows that the parameter is a relative value after all. The RTF spec also talks about a "width", which is assumed to be a relative value. So fix that bug in a different way again (by making sure that this additional fake cell contributes to the total width of the table, so column separators are counted correctly), this time without less side-effects. Change-Id: Ic64fd3a6abae8e0398e8e77123f0473d73f0c4b0 Reviewed-on: https://gerrit.libreoffice.org/43063 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-10-03new loplugin:blockblockNoel Grandin
Change-Id: I7b68b70fa4c7234e8882f7627026959a596968fd Reviewed-on: https://gerrit.libreoffice.org/43025 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-29remove some SAL_WARN in DomainMapper_ImplNoel Grandin
it's obviously not a real problem, because higher up code calls this even if it doesn't intend to use the result, and in the places where it does intend to use the result, it warns again, so this warning is redundant. And it's the 3rd largest number of warnings in our logs. Change-Id: I1a6c40bc99a3252594f87e121a81c661686c5348
2017-09-29Revert "writerfilter: convert loops to range-based-for"Miklos Vajna
This reverts commit 25cd067a82742210793e39708cc1de9ff84692a7, as it broke CppunitTest_sw_ooxmlexport4. The comment above the change suggests that perhaps the usage of indexes was intentional to avoid the usage of invalidated iterators.
2017-09-28writerfilter: convert loops to range-based-forSerge Krot
Change-Id: I424fd1bf8eef7112a8cff54ab46a07bb41596ca5 Reviewed-on: https://gerrit.libreoffice.org/42901 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-09-27tdf#75757 comphelper: avoid STL inheritance in SequenceAsHashMapMiklos Vajna
Change-Id: I5c7d107a05deb06749b4d04246ba183adfafb14d Reviewed-on: https://gerrit.libreoffice.org/42829 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-09-26tdf#112446 ooxmlimport: Orient=NONE when distance is givenJustin Luth
Prior to commit 9920a0bf9d783978cd6f7b97f7528d8aa2571143 the style could only contain the default of NONE. So when a position was specified, it was always paired with HoriOrient == NONE. So it never caused problems until that commit when the Frame's style orientation started overriding the unset paragraph default. When a position is specified, that needs to be paired with an orientation of NONE in order to take effect. Change-Id: Iab0057810270ba708a8855c2ec6db291cef17cfb Reviewed-on: https://gerrit.libreoffice.org/42499 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-09-26tdf#112211 RTF import: fix unwanted direct formatting for left indentsMiklos Vajna
Commit f528f9499bd91b700c549575e88fa102cfffede9 (tdf#106953 RTF import: fix missing paragraph left margin, 2017-05-16) fixed a problem around inheriting indents from numbering styles vs paragraph styles, but it turns out that document was rather special and in general the old behavior was correct. So fix that bug in a different way again, this time without less side-effects. The trick is that in case the level numbers group in a list definition ends with \u59 (instead of an ASCII ';'), then that group is considered to be invalid by Word. RTF import already was aware of this, but it wasn't known that when this invalid state is reached, that also means that the indents of the list level definitions should be ignored. So in general not putting direct formatting on a paragraph is a good thing: that way in case the paragraph style and the number style both has indent infos, then the numbering style wins, and that is what we want -- but in case \u59 appears in the list definition, then the indentation from the numbering style should be ignored. So fix up the tokenizer to import the indentation from list levels in general, ignore it for invalid list levels, and then we can remove the direct formatting from the paragraphs, which fixes this bug and keeps the old one fixed as well. This required fixing up two poor testcases, which tested paragraph properties, but in fact are interested in the real source of indentation, which is now the numbering style. Visually both bugdocs are unchanged. Change-Id: I6390aa870659a8ad02ba5512d84dea34dba29e9f
2017-09-26Map RTF codepage 0 to osl_getThreadTextEncoding()Stephan Bergmann
...instead of RTL_TEXTENCODING_DONTKNOW. (A file actually using that codepage is sw/qa/core/data/rtf/pass/CVE-2014-6357.rtf, processed by CppunitTest/sw_filters_test, where it caused OStringToOUString to be called with RTL_TEXTENCODING_DONTKNOW from writerfilter::rtftok::RTFDocumentImpl::resolveChars.) Change-Id: I41081c5df5c3aa80b4f1c7d52b158e73ef68cf38
2017-09-25RTF import: split this call into simpler onesMiklos Vajna
Hopefully with this it's easier to see which is the usual and which one is the exceptional case. Change-Id: Iac1b49b2a4f2b909db46155d1ff10d2ba99fd655
2017-09-24Map Windows code page 42 to RTL_TEXTENCODING_SYMBOLStephan Bergmann
<https://msdn.microsoft.com/en-us/library/windows/desktop/ dd374130(v=vs.85).aspx> "WideCharToMultiByte function" suggests that there now is CP_SYMBOL, "Windows 2000: Symbol code page (42)." And a little test program on Windows indicates that our RTL_TEXTENCODING_SYMBOL is working the same way as CP_SYMBOL, where MultiByteToWideChar maps 00..1F to U+0000..1F and 20..FF to U+F020..F0FF. At least CppunitTest_writerfilter_rtftok, when testing writerfilter/qa/cppunittests/rtftok/data/pass/EDB-18940-1.rtf, goes into case RTF_FCHARSET in RTFDocumentImpl::dispatchValue (writerfilter/source/rtftok/rtfdispatchvalue.cxx) with nParam matching aRTFEncodings[2] (i.e., a mapping from charset 2 to codepage 42, see writerfilter/source/rtftok/rtfcharsets.cxx), then passes 42 into rtl_getTextEncodingFromWindowsCodePage and obtains an unhelpful RTL_TEXTENCODING_DONTKNOW. testFdo72031 (sw/qa/extras/rtfexport/rtfexport2.cxx, CppunitTest_sw_rtfexport2) needed to be adapted, as the circled plus from the Symbol font is now internally represented as U+F0C5, not (somewhat bogusly) as U+00C5 (aka LATIN CAPTIAL LETTER A WITH RING ABOVE). But, when displayed with the Symobl font, the glyph that is actually shown remains the circled plus. Turns out changing rtl_getTextEncodingFromWindowsCodePage would start to make CppunitTest_sw_rtfimport fail: Sep 20 15:49:24 <sberg> vmiklos, with <https://gerrit.libreoffice.org/#/c/42477/>, testN823675 (sw/qa/extras/rtfimport/rtfimport.cxx) fails, the aFont.Name is not "Symbol"; sw/qa/extras/rtfimport/data/n823675.rtf contains a \fonttbl that specifies \f3 to have \fcharset2 (i.e., symbol font) and fontname "Symbol". However, RTFDocumentImpl::checkUnicode (writerfilter/source/rtftok/rtfdocumentimpl.cxx) converts m_aHexBuffer (containing "Symbol;") with nCurrentEncoding apparently being the encoding specified by \fcharset2 (i.e., now RTL_TEXTENCODING_SYMBOL instead of old RTL_TEXTENCODING_DONTKNOW), so the resulting OUString is garbage (instead of the byte-for-byte conversion to Unicode "Symbol;" that RTL_TEXTENCODING_DONTKNOW would do there); do you know whether such \fonttbl fontnames should actually be interpreted in the given \fcharset? Sep 20 15:49:24 <IZBot> gerrit: »Map Windows code page 42 to RTL_TEXTENCODING_SYMBOL« by Stephan Bergmann for master [NEW] Sep 20 15:51:15 <vmiklos> sberg: let me check if the spec covers that Sep 20 15:54:29 <mst_> sberg: i think the name is typically encoded in the font's encoding but probably they have to make a (likely undocumented) exception for symbol encoding Sep 20 15:57:46 <vmiklos> sberg: the spec only says that \fcharset is about the encoding of the content using that font, i don't see it described what would be the encoding of the font name itself Sep 20 15:58:51 <vmiklos> sberg: i'm not sure about if that encoding should or should not affect the encoding of the font name in general, but indeed at least for 2 (symbol encoding) you're right, Word doesn't encoding the font name with that encoding, either. Sep 20 15:59:30 <sberg> vmiklos, mst_, at the top of page 14 of Word2007RTFSpec9.docx I see "Note that runs of text marked with a particular font index (see \fN in the Font Table section) use the codepage for that font as given by \cpgN or implied by \fcharsetN, unless they use Unicode RTF described in the following section." Would that match what mst_ says? Sep 20 15:59:33 <vmiklos> so if it helps you case to handle at as e.g. ascii, just for that encoding, i think there would be no problem with that. Sep 20 16:00:07 <vmiklos> sberg: that still talks about the content using the font, not the strings (font names) in the font table itself, i think. Sep 20 16:01:17 <sberg> vmiklos, what's the control word to select such a font, also \fN? I don't see any such in n823675.rtf Sep 20 16:02:16 <mikekaganski> loircbot: e.g. \af3 Sep 20 16:02:31 <mikekaganski> sberg: ^ Sep 20 16:02:47 <mst_> 04d5a280beeeb6e056df68395dc9c3b3a674361b Sep 20 16:02:50 <IZBot> core - related: fdo#77979: writerfilter RTF import: read encoded font name - http://cgit.freedesktop.org/libreoffice/core/commit/?id=04d5a280beeeb6e056df68395dc9c3b3a674361b Sep 20 16:02:52 <mst_> sberg: ^ Sep 20 16:04:05 <sberg> mst_, thanks; so there's likely an (implicit?) exception for \fcharset2, as you say Sep 20 16:04:33 <mst_> that's most plausible, our own font code is full of exceptions for "symbol fonts" too Sep 20 16:05:19 <sberg> mikekaganski, ENOCONTEXT Sep 20 16:05:36 <mikekaganski> sberg: [17:01:16] sberg: vmiklos, what's the control word to select such a font, also \fN? I don't see any such in n823675.rtf Sep 20 16:06:32 <sberg> mikekaganski, so you say selection is done with \af3 instead of \f3? Sep 20 16:06:40 <mikekaganski> sberg: yes, in that case Sep 20 16:07:34 <mst_> i think there are several different keywords that apply fonts, but can't remember the whole list Sep 20 16:08:10 <mst_> \fN shoudl be one of them though Sep 20 16:22:18 <sberg> vmiklos, so who generated that sw/qa/extras/rtfimport/data/n823675.rtf, was it manually created and lacks a \cpgN before "Symbol"? Sep 20 16:29:17 <sberg> vmiklos, (after further reading of the RTF spec): disregard the "and lacks a \cpgN before 'Symbol'" part of my above question Sep 20 16:30:27 <mst_> sberg: i suggest not reading too much about encoding in RTF, it gets pretty lovecraftian pretty fast... Sep 20 16:32:58 <vmiklos> sberg: given how short that bugdoc is, i'm pretty sure i cut it down manually to something readable from a multi-MB real bugdoc Sep 20 16:33:07 <sberg> mst_, do you have a recommendation how I could get that "don't use symbol font encoding to read a symbol font's name" into writerfilter/source/rtftok/rtfdocumentimpl.cxx? RTFDocumentImpl::checkUnicode lacks the context to tell whether it is using m_aStates.top().nCurrentEncoding to convert a fontname, and the caller of checkUnicode (at the end of RTFDocumentImpl::resolveChars in this case) appears to lack the context, too Sep 20 16:33:12 <mst_> various Old Ones from The Time Before Unicode and their Backward Compatibility Tentacles etc. Sep 20 16:34:59 <sberg> vmiklos, anyway, that "so there's likely an (implicit?) exception for \fcharset2" hypothesis sounds sane, so we should probably implement it (if only you or mst_ can give me a good hint how...) Sep 20 16:35:13 <vmiklos> sberg: looking for a code pointer Sep 20 16:36:05 <mst_> sberg: m_aStates.top().eDestination == Destination::FONTENTRY should be the relevant check? Sep 20 16:36:17 <vmiklos> sberg: RTFDocumentImpl::text() is where the text is taken, Destination::FONTENTRY is the state on the parser stack which is a font entry in the font table. so to detect "your case" during decoding a byte array into a string, m_aStates.top().eDestination == Destination::FONTENTRY is what you want Sep 20 16:36:35 <vmiklos> ah good, two independent matching hints are promising ;) Sep 20 16:37:35 <sberg> mst_, vmiklos, ah; but what also looks dodgy is that checkUnicode operates there on "Symbol;" including the closing ";" of the full <fontinfo>, not just the <fontname> part of the <fontinfo> Sep 20 16:39:24 <vmiklos> sberg: i think we already assume that the only "token" in the font entry destination that is not bound to a control world (\foo) is the font name Sep 20 16:40:52 <vmiklos> sberg: writerfilter/source/rtftok/rtfdocumentimpl.cxx:1237 is where we simply strip away the trailing semicolon, there is no further separation between the font name and other character content inside the destination (apart from the control words and their arguments) Sep 20 16:42:18 <sberg> vmiklos, OK, thanks; I'll just pretend I haven't seen those dodgy details :) ...so I'm switching to (somewhat arbitrarily) RTL_TEXTENCODING_MS_1252 there now Change-Id: Iebd1bcecb7fa71c489798154d3356062b052775e Reviewed-on: https://gerrit.libreoffice.org/42477 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2017-09-22Fresh run of bin/update_pch.shMike Kaganski
Change-Id: I69d4157aaf6570cecd51ea59df20556914942e06 Reviewed-on: https://gerrit.libreoffice.org/42565 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-09-21attempt to fix android buildNoel Grandin
Change-Id: Ie3eede03b90db272d70e7cb383c7a69d9db0f2ae
2017-09-20unused bPageToggle in GraphicImport_ImplNoel Grandin
ever since commit 0929dfa83ca4dbc675c74854566ce4e25def0dbd Date: Sat Jan 11 11:54:14 2014 +0100 writerfilter: drop never generated rtf {XAlign,FHDR,YAlign,XRelTo,YRelTo} Change-Id: Icabe9ff848e3cc9918741e9c68d8f2312145fb74
2017-09-20unused bVertFlip/bHoriFlip in GraphicImport_ImplNoel Grandin
ever since commit 4a924576e415f16e0571542bb0d683529f9046ff Date: Wed Jan 15 20:24:41 2014 +0100 writerfilter: drop unused BlipDib and FSP in doctok Change-Id: I9bf644bdc4b37cb6c4a9a9ab7757c4a83a520cd7
2017-09-20unused m_xStorage in RTFDocumentImplNoel Grandin
ever since introduction in commit 328d154015f8cb733ed62d793bbbc31eb4cc971b Date: Fri Jun 10 18:56:08 2011 +0200 resolvePict: import the stream as a graphic object Change-Id: Ife03094d721621cc592be9cd94899a4e40550330
2017-09-19Related: tdf#112211 DOCX import: fix handling of missing first ind in <w:lvl>Miklos Vajna
Usually a DOCX numbering definition has multiple levels, each level containing a <w:ind ... w:hanging="..."/> element. When this is missing, we should default to the Word default, not to the Writer one. This makes the DOCX version of tdf#106953 imported correctly, in preparation of dropping the original fix that helped RTF only. [ The DOC version of the bugdoc is still not imported correctly. ] Change-Id: Ib7fc1de55316a73188c023665a585ac7056341f7 Reviewed-on: https://gerrit.libreoffice.org/42447 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-09-19Word 2013 and 2016 does not honor the <w:view> setting, let's ignore it too.Jan Holesovsky
In other words, let's open documents in the non-web view even when saved with <w:view w:val="web"/>. The behavior I see in Word 2013 (and it's documented that his happens in 2016 too) is that the setting is not a document setting any more, but user's setting. Ie. regardless of what is written in the file, the .docx document opens in the Print Layout if the Word was in the Print Layout until now, and in the Web Layout if it was that mode. We handle the non-web layout much better than the web layout, so let's just default to the normal layout on load. Change-Id: Ieba7ddc280b9b79501a6b89ff21b03a86356583c Reviewed-on: https://gerrit.libreoffice.org/42414 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2017-09-18Translate German comments and debug strings (leftovers in dirs w... and x...)Johnny_M
Translates leftovers found using a custom regex in directories beginning with "w" and "x". Additionally: - A few corrections of previous translations Change-Id: Ic30cf6792748a6bea8782a9a3711fa468b80bdaf Reviewed-on: https://gerrit.libreoffice.org/42378 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-09-15Fix loplugin:redundantcast's VisitCXXFunctionalCastExprStephan Bergmann
...when t1 is ElaboratedType sugar (which isn't only used when the type is written with an elaborated type keyword, but also when it is written with a qualified name). (I originally wrote testArithmeticTypedefs to track down a different issue, which turned out to be a non-issue, with this fix as fall-out. So that test doesn't quite match the theme of this commit, but is a worthwhile addition nonetheless.) Change-Id: Ic447da4399853d7d045e3e2e7ade8ddf52d89749
2017-09-14clang-tidy modernize-use-emplace in variousNoel Grandin
Change-Id: Id1bbd3f380c17beeaab11f7140d4df1304c3d0d8 Reviewed-on: https://gerrit.libreoffice.org/41750 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-13Fraction: make conversion operators and constructor explicitNoel Grandin
and simplify some of the calculations that needed to be changed. Which resulted in one unit test needing to change by one pixel, let's hope not an indication of a real problem. Change-Id: Ie56434f35f4e58d21ee6f671392e93dc7542fca3 Reviewed-on: https://gerrit.libreoffice.org/42240 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-12tdf#112346: take Word no-wrap limit into account also for ww8Mike Kaganski
This also makes ww8 floating-table conversion decision heuristics somewhat closer to OOXML code. Change-Id: I29ca2ebabd1758ad98e02aaf560cf2f44daec3a8 Reviewed-on: https://gerrit.libreoffice.org/42196 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-09-11tdf#112304 Revert "Watermark: not visible if page background was set"Szymon Kłos
This reverts commit 39c08074a286855dd014ce1c30b8f7ef95b10242. Fixed by: I69517efb7d82acd719d6a27a09ba61554dbf1ec9 Change-Id: Icd45b3f55292670ff7338a367eba212453a0687e Reviewed-on: https://gerrit.libreoffice.org/42155 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
2017-09-07writerfilter: size() > 0 -> !empty() and other small cleanupsMiklos Vajna
Change-Id: I808a3ed8180b6f2164f14d736e2c8dc4bb8948bc Reviewed-on: https://gerrit.libreoffice.org/42037 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-09-04tdf#112208 rtfimport: fix missing paragraph first line indentJustin Luth
This is a followup to commit f528f9499bd91b700c549575e88fa102cfffede9 adding ParaFirstLineIndent to that commit's Para(Left|Right)Margin. I also added code for hanging indents, but it doesn't look like that case will ever hit. Just added for completeness. My test unit was created in Word as a hanging indent, but it invokes the firstLine case... Change-Id: I2b04866b9eb4b085503f3b7d3b6e97d4f9e3d19c Reviewed-on: https://gerrit.libreoffice.org/41901 Reviewed-by: Justin Luth <justin_luth@sil.org> Tested-by: Justin Luth <justin_luth@sil.org>
2017-09-04Revert "tdf#111895 writerfilter: avoid hiding shapes behind background"Justin Luth
This reverts commit d21f67fa7fd0360688e083eeb2bbcd57f5414d71. A better fix is commit de0993097cad2fd5819f8bea5ff53cddce7cde41. This patch didn't properly describe the zOrder stuff anyway. The problem technically wasn't with the zOrder - the painting method only made it seem to be so. Thanks to the reviewers for their helpful comments that spurred further areas of research. Change-Id: I586edd189e5b0a25b6e1e64ca42fdf43305997da Reviewed-on: https://gerrit.libreoffice.org/41904 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-09-04loplugin:unnecessaryparen include c++ castsNoel Grandin
Change-Id: I132d3c66f0562e2c37a02eaf4c168d06c2b473eb Reviewed-on: https://gerrit.libreoffice.org/41874 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2024-07-11 15:13:18 +0000