summaryrefslogtreecommitdiff
path: root/sw/qa
AgeCommit message (Collapse)Author
2017-09-29tdf#112741 sw split sections inside table cells: fix table re-layoutMiklos Vajna
The bugdoc has a section large enough that it is split across 4 pages. The section is inside a nested table. First we lay this out properly, but when later laying out the footer we need to redo the body frame layout, which first undoes the split of the table/nested table/section. This fails, the master second and its 3 follows are expected to be moved back to the first page (and merged together), but SwSectionFrame::MakeAll() did this only for the first follow, which was moved to the first page, not for the other 2 follows which were on other pages. Fix the problem by merging not only follows which are also next to the section frame, but also the ones which are follows (but not nexts). Change-Id: I7a69aa58336a50d4f37808ccb105b443c2f6993c
2017-09-28loplugin:stringconstant: Simplify construction of non-ASCII OUStringStephan Bergmann
Change-Id: If80c53978106789824e6154db396baeecc1969dd Reviewed-on: https://gerrit.libreoffice.org/42876 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2017-09-27tdf#112679 sw: fix copying of fieldmarksMichael Stahl
Aha, now we know that the reason for the defensive programming in lcl_AssureFieldMarksSet() was that there are actually 2 different use-cases for it: usually a new mark is inserted, so there are no dummy characters and they must be inserted. However when copying text, the dummy characters are copied too, so they must not be inserted, or we get duplicate fieldmarks. This also reverts commit d4036d3a89b65a4912f62e3930eb1a31cd90a16b which fixed the problem only for CHECKBOX_FIELDMARK in a different way. (regression from bb069fe7b8b6a24f9ff4df4c7052961e17ea3a8c) Change-Id: I3c99b8c6d720951655198e682018794337859373
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-26Better way to detect Apple Xcode 9 ClangStephan Bergmann
...without also accidentally affecting any upstream Clang 9.0 Change-Id: Ie52413e2e53a2ce01f55b97677fe9878d498b076 Reviewed-on: https://gerrit.libreoffice.org/42809 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-09-26Rename the basegfx::tools namespace to basegfx::utilsTor Lillqvist
Reduce potential confusion with the global tools namespace. Will hopefully make it possible to remove the annoying initial :: when referring to the global tools namespace. Unless we have even more tools subnamespaces somewhere. Thorsten said it was OK. Change-Id: Id088dfe8f4244cb79df9aa988995b31a1758c996 Reviewed-on: https://gerrit.libreoffice.org/42644 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2017-09-26Blind fix for Xcode 9Stephan Bergmann
...which started to run into the same undefined reference issue as 5a55bef38b047b9c60d1b219c572287938265610 "Temporary fix for Clang on F26". (Unfortunately, Apple's Xcode Clang uses version numbers that can be confused with upstream Clang version numbers, so this patch will also affect users of upstream Clang 9.0 on macOS, when that eventually gets released.) Change-Id: I721f01f76d93c044fdbc02e68002b60b17b5e9fb
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-25sw: split section frames inside table cells, handle nested tablesMiklos Vajna
Commit 3d1bb76ebf5c51141018cfd76eccdb63472de8de (tdf#112109 sw: split section frames inside table cells, ignore nested tables, 2017-08-31) explicitly disabled this, but the underlying problem is now fixed with commit ec262cbc56822d8fffccd6e983848df196cf5c44 (tdf#112160 sw: audit GetNextLayoutLeaf() calls in SwFrame::GetNextSctLeaf(), 2017-09-04), so we can have it again. Change-Id: Ic17c4921de2c69e4cc16ae82cfed58d096879db7
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-21Clean up construction of one non-ASCII-literal OUStringStephan Bergmann
...in preparation of a change coming there soon Change-Id: I8861dbd47d0e514cd1c5dc0bb978724ae687f01c
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-18allow events to accumulate past limit if an exception is pendingCaolán McNamara
Change-Id: Ic54c31961b887e06267aba1ceb0378508d24ded0 Reviewed-on: https://gerrit.libreoffice.org/42411 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-09-18tdf#109310 ooxmlexport: write Xnote character styleJustin Luth
LibreOffice will just ignore the defined style on import (since that is statically defined by the footnote code). Microsoft Office, however, requires the character style be provided for the footnote number. It doesn't have any built-in formatting for footnotes. So, this patch is strictly for MSO's benefit. Change-Id: I6631dd0eb697589cfd3c13d7838fe14c31a71bbf Reviewed-on: https://gerrit.libreoffice.org/42035 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-09-15convert SvxCellVerJustify to scoped enumNoel Grandin
Change-Id: I9d1cdb4ddfee43b7a0990624d7d16e06679343c4 Reviewed-on: https://gerrit.libreoffice.org/42276 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-14clang-tidy modernize-use-emplace in swNoel Grandin
Change-Id: I92fd035824f247dc61edfb18c54b960a7733fdf7 Reviewed-on: https://gerrit.libreoffice.org/42244 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-13Actually no need to make GetASCWriter public.Jan Holesovsky
Change-Id: I6f0f18629c6a61b6a4c52c2b16cc7b45525a5259
2017-09-13tdf#112191: Unit test.Jan Holesovsky
This was the hard part of the fix :-) Change-Id: Iae335c9d41d9b3420472b5d02113e2b42ab825da Reviewed-on: https://gerrit.libreoffice.org/42203 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2017-09-13tdf#75539 ww8import: fix horizontalLine percentageJustin Luth
The formula previously divided by 1000, which was a common dxaGoal width from MSO2003 (based on round-trip testing). But for the bug document, that formuala didn't work. An "assert (false)" with "make check" indicates that only unit test n757118.doc contains a percentage-derived width, and that test also has dxaGoal == 1000. So, my pool of test documents is pretty small, but it seems logical that this is a better formula since it fixes an obviously bad example, and explains why it "worked before". Change-Id: I7bf666e88e7e59e06bbfa3c0961fa8eabbc80310 Reviewed-on: https://gerrit.libreoffice.org/41957 Reviewed-by: Justin Luth <justin_luth@sil.org> Tested-by: Justin Luth <justin_luth@sil.org>
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-11loplugin:unusedvariablecheckTor Lillqvist
Change-Id: Iaeed1da4ec76075271b48147e3f9372d966e6f99
2017-09-11tdf#97648 vml import: fix horizontalLine percentageJustin Luth
o:hrpct (horizontal line width as a percentage) was overwriting valid widths with an invalid string since 2012. For some reason, commit 96c7ab19b77c2f90acd4c34552474b0f616f48a7 thought it would be a good idea to set the width as a percent string, even though the code doesn't seem to handle percent strings. (like "100%"). The logic was that since 100% width is saved as nWidth=0 by Microsoft, so it doesn't make a difference. Well, it does make a difference for every other percentage, since nWidth IS provided for those. That width value is the only thing LO can currently handle - it does nothing with the maWidthPercent for these horizontal lines. Saving hrpct to maWidthPercent seems like the proper variable for this data, but once again, this doesn't in fact change much in LO. It certainly doesn't affect the width of the line. Since this patch only affects o:hr shapes, this is a pretty safe change, for the benefit of all <100% o:hrpct's. An "assert false" and "make check" only showed docs containing 100%, width=0 samples. I added a unit test for several other lengths. I also hacked that test to provide a width value for the 100% line - even though that is not natural - just so it can be seen in LO. Change-Id: I9d6ddbbaa99ec8df32abb1047a80522322a1f631 Reviewed-on: https://gerrit.libreoffice.org/42088 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-09tdf#112074 ww8import: replace m_nOrgDxaLeft with GetMinLeft()Justin Luth
Followup to commit 176a723876b0138debb20f824103b2ab0c910401. In those comments (https://gerrit.libreoffice.org/#/c/41664) I said I'd leave the existing use of m_nOrgDxaLeft even though reading through the code suggested GetMinLeft() might be better. Well, round-tripping shows that MSWord properly reads the indent, but LO doesn't - unless using GetMinLeft(). So now I have my proof document and I can make the desired change with confidence. Change-Id: Icbe12b50c4f2dcf3a0d78f87685f1dfba53a375b Reviewed-on: https://gerrit.libreoffice.org/42113 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-09-08tdf#112074 doc export: re-calculate indent for RTL tableJustin Luth
In MSO tables, the only side that can have an indent is the logical left orientation. In right-to-left tables, the indent is measured from the physical right margin. So, we need to re-calculate LO's physical LEFT_AND_WIDTH indent to measure the distance from the right margin to the table. Importing already expects this recalculated indent. Change-Id: I9b8b7078aea8b7800cd31fbc11e2f27bd051be7d Reviewed-on: https://gerrit.libreoffice.org/41666 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-09-07unotest.py: refactor confusing mess of openDoc functionsMichael Stahl
Change-Id: I148332c639510c55dea2d09bc7aa695708fbf34c
2017-09-07sw: oops, forgot to amend that before pushingMichael Stahl
Change-Id: Idaf3d066a61dcf30019eda9f84bb7442362ab57d
2017-09-07sw: fix text_portion_enumeration_test.py on WNTMichael Stahl
This fails, mostly because of confusing native paths and URLs, and because of deleting the temp. directory before closing the file that the test wrote into it. Also, why open the document as a template. Change-Id: I6da2f3f2c47308c4956444869b5b100a124b8db0
2017-09-07tdf#103090 replace spaces by underscore in bookmark names for DOCX.Vasily Melenchuk
Bookmarks containing spaces are incorrectly interpreted by MS Word, so spaces are replaced in bookmark names and bookmark references in fields. Change-Id: I4e23c6b8740b54e94a1ec7e3385cffbe3ba01709 Reviewed-on: https://gerrit.libreoffice.org/41954 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-09-07tdf#112074 doc export: for RTL tables, LEFT_AND_WIDTH is RIGHTJustin Luth
In MSO tables, the only side that can have an indent is the logical left orientation. In right-to-left tables, the indent is measured from the physical right margin. So, we need to save the table's orientation as RIGHT aligned. In LO tables, only the physical left orientation can specify the indent. Importing already calculates the corrected index size. On export, the indent size will need to be re-calculated to account for the reversed the margins, but that will come in a separate patch. Change-Id: Ie2457791f913af2360af96f5038063d305e366de Reviewed-on: https://gerrit.libreoffice.org/41665 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-09-06tdf#112074 doc import: use real width if no preferred widthJustin Luth
If the document did not specify a preferred table width, then the indent was completely wrong. I don't think the "else" clause ever provided a correct value. See https://bz.apache.org/ooo/attachment.cgi?id=63705&action=diff These documents don't round-trip at all, so making changes here ought to be fairly regression-safe since the documents are read-only anyway. Change-Id: I6308ffd22b6f7ce60b9780e00b68bc6f8b09a6fa Reviewed-on: https://gerrit.libreoffice.org/41664 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-09-05tdf#112164 add test documentDinh Le
Change-Id: Iacf2bec62a8eff3c9b4e6a5971ee8e63ae00567e
2017-09-05tdf#112164 sax: handle errors on last call to XML_Parse()Michael Stahl
If XML_Parse() is called with isFinal=1 and there are open tags, that is an error (XML_ERROR_NO_ELEMENTS) that must be converted to an exception. This reveals that we already had an incomplete input document, which needs to be moved to "fail" now. Change-Id: I7ce3b51bd87923b5edde621508cf38d7ebbc2b14
2017-09-05tdf#97362: TextPortionEnumerationTest partially migrated to python (last part)jmzambon
Convert tests: - test_meta_xtextattach_toxmark - test_meta_xtextattach_refmark - test_meta_xtextattach_textfield - test_meta_xtextattach_footnote - test_meta_xtextattach_meta - do_meta_xtextattach - test_metafield_xtextfield - test_metafield_xpropertyset - test_load_store - test_load_store_xmlid Change-Id: I471329e8088b533eedec6a55c521ed313f1960b4 Reviewed-on: https://gerrit.libreoffice.org/41863 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-09-05tdf#104936 RTF export: implement ZOrder of TextFrames / shapesMiklos Vajna
This used to work by accident for the particular textbox, but broke with commit 38f2b8b3b16aab19a2564ec699d253d3dccecc3c (tdf#88811 SwXText::convertToTextFrame: handle shapes anchored to us, 2015-02-03), so write ZOrder explicitly, like other filters already do. Change-Id: Ie8f11f4ec77707fb5aec7a597544d589a99bf6ca Reviewed-on: https://gerrit.libreoffice.org/41921 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
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-04tdf#111891 unostyle: use default handler for non-page styleJustin Luth
LO 5.1 commit 664197d95becd516c3dac25a50439078ba61e051 introduced a handler for RES_TEXT_VERT_ADJUST to handle page styles, but that meant that the default handler was no longer called for frames (the only other item currently using RES_TEXT_VERT_ADJUST). Change-Id: I33827160fe64dc4cc2107afc26f7ac2e698007e1 Reviewed-on: https://gerrit.libreoffice.org/41538 Tested-by: Justin Luth <justin_luth@sil.org> Reviewed-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-04tdf#37153 ConsiderWrapOnObjPos: always affect anchoring cellJustin Luth
MSO doesn't make a distinction where the object is located - whether it is contained within the boundaries of the anchoring cell or not. It always affects the anchoring cell's vertical orientation. Both DOC and DOCX enable this compatibility setting. Change-Id: Ifa066d3549b1a6183360b5b01c659e41c681d492 Reviewed-on: https://gerrit.libreoffice.org/41821 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-09-04just blow through the hierarchy to find the polylinesCaolán McNamara
Change-Id: I080243911e07d46a1ecc3f935df8ec86b54931e9 Reviewed-on: https://gerrit.libreoffice.org/41889 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-09-04tdf#112160 sw: audit GetNextLayoutLeaf() calls in SwFrame::GetNextSctLeaf()Miklos Vajna
GetNextLayoutLeaf() returns the next container, not the follow one, so calls to that without checking first if we are in a table are always suspicious. This leads at the end to strange content move, as described in the bug. There appears to be only a single place in SwFrame::GetNextSctLeaf() which may be executed for split sections and called GetNextLayoutLeaf() unconditionally. Change-Id: I759d9ef63660f3d2ffe006c88b18cba7dba99f33 Reviewed-on: https://gerrit.libreoffice.org/41882 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-09-03Resolves: tdf#112145 pdf export of editengine highlight color fails sometimesCaolán McNamara
When setting a fill or line color on the outputdevice, put it back to its previous setting when finished with the record, PRIMITIVE2D_ID_POLYPOLYGONCOLORPRIMITIVE2D was the one in this case but protect the other similar ones here too Change-Id: Ifb9b182d72bb6c48a9d9480270fde4384be6291e Reviewed-on: https://gerrit.libreoffice.org/41761 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-09-03Fix typosAndrea Gelmini
Change-Id: I0ce33d497d405398145653b9b7da81bd066f68e1 Reviewed-on: https://gerrit.libreoffice.org/41868 Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2017-09-03tdf#112169: Crash while saving character background color to DOCXTamás Zolnai
Change-Id: Iff12b9587b639166caef86f895fb841e83596817 Reviewed-on: https://gerrit.libreoffice.org/41857 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2017-09-02tdf#37153 ConsiderWrapOnObjPos: also affect wrap-thru objsJustin Luth
MSO doesn't make a distinction when the wrapping is THROUGH. Both DOC and DOCX enable this compatibility setting. Change-Id: I123801fc83b5f4ac6a26a5ea77ba6dba2c60ec39 Reviewed-on: https://gerrit.libreoffice.org/41795 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-09-01Insert blank page when first page number is evenLuke Deller
When the page number is explicitly changed at a page break, LibreOffice will insert a blank page if necessary to ensure that even page numbers appear on "left" pages. This commit fixes a case that was missed: the case where the page number of the very first page in the document is explicitly set to be an even number. Also: - adjust a couple of unit tests which were referring to specific physical page numbers, that were not expecting this blank page to be there - enhance SwModelTestBase::parseDump to support xpath expressions evaluating to simple values rather than nodes, for use in a test case for this change Change-Id: I1f41760c3bb17bdffb868cf32a1331de87d1d0e1 Reviewed-on: https://gerrit.libreoffice.org/39858 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-08-31Resolves: tdf#112122 Use EndElement instead of dtor to call throwing methodsCaolán McNamara
Change-Id: I1cc3b9af4089f1e657c5c63e0911aac8bdce04f3 Reviewed-on: https://gerrit.libreoffice.org/41756 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-08-31tdf#108765 DOCX: after import, allow default styles againJustin Luth
During import, we don't want LO's style defaults to intermingle with those of MSO [1]. However, if any styles are NOT defined by the document itself, then we want to use that new style with appropriate defaults. For example, if footnotes were never used, that style might not be defined in the .docx file. Later, if a user inserts a footnote for the first time, we certainly don't want the "default paragraph" settings. Instead, we want the default "Footnote" settings. [1]: see commit b95d203bc17c83ec0fe5139f519d53ed1d842d3a Change-Id: Ia71490e795885d3c16f764d0f716f6499765cb67 Reviewed-on: https://gerrit.libreoffice.org/41546 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
generated by cgit (git 2.34.1) at 2025-02-11 19:56:39 +0000