summaryrefslogtreecommitdiff
path: root/sw/qa/extras/ooxmlimport
AgeCommit message (Collapse)AuthorFilesLines
2018-02-23tdf#115883 DOCX import: catch RuntimeException from SwXFrameMiklos Vajna2-0/+6
getPropertyValue("Surround") for a non-inserted frame can throw, but hasPropertyValue("Surround") still returns true. So fix the regression by just catching the exception, assuming that in that case no increased spacing is needed. Change-Id: I49a78ce8d41b4e1cc7d23721d5dc70f7550c94af Reviewed-on: https://gerrit.libreoffice.org/50175 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-02-21Fix some IWYU warningsMiklos Vajna1-0/+1
Change-Id: If1e6727e4b5bb225495e20d5dfb78fa5da770f75 Reviewed-on: https://gerrit.libreoffice.org/50060 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-02-13docx: output ruby attributes properly.Mark Hung2-19/+0
Enclose ruby with run, output hps, hpsBaseText, hpsRaise, etc, ,make the size and script correct as much as possible. The ruby format in docx can be round-tripped now, so it is moved to ooxmlexport. Change-Id: I03797be54aeffeff016011ad8ec536cecf40064f Reviewed-on: https://gerrit.libreoffice.org/49509 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mark Hung <marklh9@gmail.com>
2018-02-10writerfilter / ww8filter: enhancement to support new ruby position.Mark Hung2-0/+2
1. Allow ooxml / rtf import the ruby aligned on the right side ( rightVertical or jc=5 ) as css::text::RubyPosition::INTER_CHARACTER. 2. Allow rtf / ww8 export of css::text::RubyPosition::INTER_CHARACTER as jc=5. Though rtf filter can save and load the new ruby position, character format seems lost. The reset of the MSO formats have other issues that they can't make roundtrip yet. Change-Id: Idb77423842f43abc375a1282a52b0bc6f20049e4 Reviewed-on: https://gerrit.libreoffice.org/49177 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mark Hung <marklh9@gmail.com>
2018-02-07Fix typosAndrea Gelmini1-1/+1
Change-Id: I90e3a9b3c1b8053362ff938374dd781d30618279 Reviewed-on: https://gerrit.libreoffice.org/49368 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2018-02-07tdf#114217: Consider relative width when importing floating tableMike Kaganski2-0/+8
Unit test included Change-Id: I8e3338d7df431bd016caa4e06e684fbd189127c4 Reviewed-on: https://gerrit.libreoffice.org/49324 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-01-21tdf#113946 add 'topMargin' to GraphicHelpers importPatrick Jaap2-0/+7
The case '...topMargin' was not caught for setting a relative vertical position in GraphicHelpers. The test file demands a '7' here, which stands for 'PAGE_FRAME'. The '7' was overwritten in GraphicImport in case 'LN_CT_Anchor_positionV' by a call of 'resolve'. For a better overview a switch is inserted here. Change-Id: Ie98209fe445ecbba15c3dafe5980ca52421126f8 Reviewed-on: https://gerrit.libreoffice.org/47905 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-12-11tdf#112443 disable off-page content positioningPatrick Jaap2-1/+9
Disable the positioning for objects that are completely off-page. During import, LO writer forces content always back to the page and causes unwanted content on the page in constrast to MSO. To achive this the top/left position of the content is compared to the bottom/right border of the clipping region. A new compatibility flag OFF_PAGE_POSITIONING is introduced for legacy rendering of legacy documents. A unit test demonstrates the issue. It resolves tdf#112443. Change-Id: I263c129f9f09ed909ad777a34f8b9ffc84d871e4 Reviewed-on: https://gerrit.libreoffice.org/43313 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-11-10tdf#43017: Support for DOCX hyperlinks character propertiesVasily Melenchuk2-0/+11
Here goes a bunch of related changes: 1. Create new character style based on current character properties 2. Apply created style to hyperlink object 3. Fixes to predefined style names usage in w:rPr 4. Disable style usage for hyperlinks in TOC: they will receive later anoter styles Change-Id: I1a228992eb7c1e259a6a811aa7f959debaae4f35 Reviewed-on: https://gerrit.libreoffice.org/41784 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-10-23loplugin:includeform: swStephan Bergmann1-1/+1
Change-Id: Ifc3c4c31a31ee7189eeab6f1af30b94d64f2f92a
2017-10-19tdf#87533 Fixed initialization of writing mode for paragraphSerge Krot2-0/+32
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-18tdf#109306 ooxmlimport: consider table sizes < 10%Justin Luth2-13/+0
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-09-26Rename the basegfx::tools namespace to basegfx::utilsTor Lillqvist1-1/+1
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-13Fraction: make conversion operators and constructor explicitNoel Grandin1-2/+2
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-04just blow through the hierarchy to find the polylinesCaolán McNamara1-2/+2
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-03Resolves: tdf#112145 pdf export of editengine highlight color fails sometimesCaolán McNamara1-2/+2
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-08-30loplugin:constparam in variousNoel Grandin1-1/+1
Change-Id: I6821a3946f2e8fabf26558a84370c16ac8827fed Reviewed-on: https://gerrit.libreoffice.org/41721 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-08-25tdf#60351 - add unit test for shape brought to foregroundJustin Luth1-0/+3
Test for this comment in d59ef5b2ddb9249905fecf941be6ec83251d12de // We should bring it to front, even if wp:anchor's behindDoc="1", // because otherwise paragraph background overlaps the graphic // TODO: if paragraph's background becomes bottommost, // then remove this hack Actually, the proper fix for this would be that the paragraph background also "wraps" around the picture (just like the text), not that the paragraph background becomes bottommost. The main concern in forcing to the foreground would be if wrap_THROUGH text would become hidden. However, testing suggests that cannot happen in this code. In that case, the worst would be that this shape now overlaps another shape - a rather unlikely situation. So this hack should be safe and maintained since it visually fixes a compatibility problem. Change-Id: I96495cd08a580afbca71a7f6d6dfd85652ff021b Reviewed-on: https://gerrit.libreoffice.org/41487 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-08-22Fix two issues in ActiveX DOCX import / export codeTamás Zolnai1-7/+4
* Inline anchored VML shape had wrong vertical position ** In MSO inline shapes are positioned to the top of the baseline * During export all shape ids were the same (shape_0) ** VML shapes used to be exported only as fallback, I guess that's why it did not cause any issue before. ** Override the shapeid generator with a new one, which actually generates unique shapeids. Change-Id: I752f39d092d0b61d91824141655dae662dbeafbc Reviewed-on: https://gerrit.libreoffice.org/41319 Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2017-08-17tdf#50097: DOCX: export form controls as MSO ActiveX controlsTamás Zolnai2-28/+0
* Use the same structure for export what MSO uses ** Position and size information are exported as VML shape properties ** Different handling of inline and floating controls (pict or object) ** Do some changes on VML shape export to match how MSO exports these controls ** Write out activeX.xml and activeX.bin to store control properties ** Use persistStorage storage type defined in activeX.xml * Drop grabbaging of activex.XML and activeX.bin * Cleanup control related test code Change-Id: I38bb2b2ffd2676c5459b61ec2549c31348bab41c Signed-off-by: Tamás Zolnai <tamas.zolnai@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/41256 Tested-by: Jenkins <ci@libreoffice.org>
2017-08-15tdf#109319 writerfilter: set DropCap.DistanceJustin Luth1-0/+6
Change-Id: I3ec06e9a196897c095f227e9f765243c6c188898 Reviewed-on: https://gerrit.libreoffice.org/41185 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-08-15tdf#109318 writerfilter: don't increment DropCap linesJustin Luth2-0/+16
I have no idea why the original implementation used ++nLines when setting aDrop.Lines. Unchanged since mass import from OOo in 2008 commit 614f53dda31f14fe89303dc1809fc29350c1ba29. Change-Id: If427dcea815e91d2cccb2c11044cdb393bff09e3 Reviewed-on: https://gerrit.libreoffice.org/41184 Reviewed-by: Justin Luth <justin_luth@sil.org> Tested-by: Justin Luth <justin_luth@sil.org>
2017-08-15loplugin:redundantcast, find more functional castsNoel Grandin1-5/+5
In the enum types that caused the problem look like this when I dump then: EnumType 0xdb45770 'enum SvxFrameDirection' `-Enum 0xdb456d8 'SvxFrameDirection' SubstTemplateTypeParmType 0xdb61200 'enum SvxFrameDirection' sugar |-TemplateTypeParmType 0xd7518f0 'EnumT' dependent depth 0 index 0 | `-TemplateTypeParm 0xd7518a8 'EnumT' `-EnumType 0xdb45770 'enum SvxFrameDirection' `-Enum 0xdb456d8 'SvxFrameDirection' Change-Id: Id8fedabe43b7a27df61a2320a9acbf54d2dc7882 Reviewed-on: https://gerrit.libreoffice.org/41169 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-08-12Removed duplicated includeAndrea Gelmini1-1/+0
Change-Id: I68286aaf7bce262cfc6d371490221e910a3ba7c6 Reviewed-on: https://gerrit.libreoffice.org/41040 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2017-08-10tdf#111550: A workaround for out-of-order (in-paragraph) tbl on OOXMLMike Kaganski2-0/+66
Word allows <w:tbl> to be direct child of <w:p>, which is illegal according to ECMA-376-1:2016. This allows for import the data in such tables (previously, this text was simply dropped, causing dataloss) - bug-to-bug compatibility with Word. Change-Id: I19c17ab19915ea46685727c635476fe5df593212 Reviewed-on: https://gerrit.libreoffice.org/40909 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-08-09tdf#91384: DOCX: import ActiveX controlsTamás Zolnai2-0/+29
Change-Id: Iebf2ff65fcec3231acfc962fb2f1abc2ed2dc67a Reviewed-on: https://gerrit.libreoffice.org/40930 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2017-07-28tdf#107723 Import font name from text portions in shapesSamuel Mehrbrodt2-0/+11
Change-Id: Ib9b73b5c05ec2e6846ea3adc950ccab5d1c0a9b0 Reviewed-on: https://gerrit.libreoffice.org/40439 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-07-28tdf#109524: use 100% table width when there's no explicit width availableMike Kaganski2-0/+12
According to ECMA-376-1:2016 17.4.63, 17.18.87, etc, all table widths are considered preferred, and actual table layout should be determined using an algorithm described in 17.18.87. When w:tblLayout element is omitted, or there is no explicit width information given, it is assumed that AutoFit Table Layout should be used, i.e. using cells content to determine final widths of table grid. In the description of the AutoFit Table Layout algorithm, it is stated that the table width grows to hold data, but no more than page width. As a first approach, this commit just sets table width to 100% when there's no width data available. TODO is to implement the AutoFit Table Layout algorithm properly. Change-Id: I000c548eb152c70d2c6e053f4d2b1d16e8976c27 Reviewed-on: https://gerrit.libreoffice.org/40500 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-07-24tdf#109306: consider percent unit specification for table sizesMike Kaganski2-0/+13
According to ECMA-376-1:2016, ST_MeasurementOrPercent (the type of "w:w" attribute of table sizes) is allowed to have this specification (and then is expected to be a floating-point value). First edition of the standard (of 2006) only defined this attribute to contain int32 value (of fiftieths of percent when holding relative widths). Unit test included. Change-Id: I700912e4eb07430e55fe1d169d99e8e7e0e1a00b Reviewed-on: https://gerrit.libreoffice.org/40361 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-07-21Fix typosAndrea Gelmini1-1/+1
Change-Id: I43f38b4dda6b1999d84d9f9760d0fae4c0358394 Reviewed-on: https://gerrit.libreoffice.org/40277 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2017-07-20tdf#108849: allow out-of-order sectPrMike Kaganski2-0/+8
According to ISO/IEC 29500-1:2016(E) 17.6.17), the final <w:sectPr> must be the last child element of the body element. Also, this is enforced in schema for CT_Body complex type (Annex A. (normative) Schemas – W3C XML Schema, A.1 WordprocessingML, page 3866), where sectPr is a part of <xsd:sequence>, and thus *must* stay at specific place in sequence, namely being the last element, and be at most one instance. However, real-life documents (generated by some third-party software) have sectPr before other body contents. Unfortunately, MS Word seems to allow this standards-violating content, and thus encourages creation of non-standard documents by third-party generators. This patch doesn't assume that current final (body-level) sectPr is the last body element, and does not mark current paragraph as last section's paragraph. Thus, current section (possibly started after previous paragraph-level sectPr) is continued after final sectPr is closed. Change-Id: I8e88288bc6659d77d17986514b3b4fe16a5b45d9 Reviewed-on: https://gerrit.libreoffice.org/40161 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-07-13Make tdf108545_embeddedDocxIcon test universalSzymon Kłos1-7/+2
Change-Id: Ie0d0520bb725c082710c08aa30ecfe18d0c6cc6b Reviewed-on: https://gerrit.libreoffice.org/39864 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
2017-07-12tdf#109053: DOCX: Multipage table is not imported properlyTamás Zolnai2-0/+8
An other use case when converting to a "floating table" is not a good idea. In this case we can check whether next to the table anything fits in the text area. If not then we can avoid floating table conversion. Change-Id: I798a2f4c7a9dfe6aecbe4a73e3162b49ea5f0adc Reviewed-on: https://gerrit.libreoffice.org/39811 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2017-07-08tdf#108545 show an icon (DOCX inside DOCX)Szymon Kłos2-0/+12
If DrawAspect is equal "Icon", show an icon not document preview Document is opened in the separate window, not in-place. Change-Id: I3a8d81e7340b29d247f8ac440c06b0420bb65644 Reviewed-on: https://gerrit.libreoffice.org/39440 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
2017-07-07tdf#108995: take xml:space attribute into accountMike Kaganski2-0/+10
See paragraph 2.10 of XML 1.0 specification and 17.3.3.31 of ECMA-376-1:2016 Change-Id: I7f19d3b9cf2ccce88a5fa03022beeb99facc04fe Reviewed-on: https://gerrit.libreoffice.org/39682 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-07-07tdf#108714: Also support paragraph-level (line) breaksMike Kaganski2-1/+3
Change-Id: Ida55015363cac3ae29b82a60a9b9a5f1b39086a2 Reviewed-on: https://gerrit.libreoffice.org/39675 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-28tdf#108714 follow-up: handle deferred break in character groupMike Kaganski2-4/+15
If an out-of-order break happens immediately after a table, then in following paragraph group (before character group start) the table level is > 0, and break is ignored. Since out-of-order break only happens at top level, the following character group necessarily designates a new paragraph group, so it's OK to handle that at the character group level, where table level is already updated. Change-Id: Ic1b1bb89e12407b050c2e880ad971794311845a5 Reviewed-on: https://gerrit.libreoffice.org/39347 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-27tdf#108714: allow <w:br> as direct child of <w:body>Mike Kaganski2-0/+47
LibreOffice doesn't accept <w:br> element as a child of <w:body>. ECMA-376-1:2016 17.3.3.1 describes br as element of a run content, and points to CT_Br in §A.1. CT_Br may appear only as part of EG_RunInnerContent. In turn, EG_RunInnerContent may appear only inside CT_R. So, using <w:br> outside of <w:r> produces ill-formed OOXML. Open XML SDK 2.5 Productivity Tool for Microsoft Office confirms that, showing OpenXmlUnknownElement error. However, Word accepts it as direct child of <w:body>. It behaves as if the <w:br> were used as first element in first run of the following <w:p> (thus creating page break after next paragraph). Another Word bug that provokes third-parties to create ill-formed documents, and requires LibreOffice to be bug-to-bug compatible. This commit makes the following changes: 1. Registers a dedicated complex type CT_Br_OutOfOrder to handle those unusual breaks, with corresponding handler function. 2. In the handler function, saves the gathered property set to parser state to use later in next paragraph group handler. This reproduces Word behaviour. Change-Id: I5df6927e2de9266b58f87807319ad1c4977e45a7 Reviewed-on: https://gerrit.libreoffice.org/39168 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-27tdf#108806: convert CRLF into space in OOXML textMike Kaganski2-0/+10
Change-Id: I8e2e108a705ecdb55c096a589d83d51c48b0b83c Reviewed-on: https://gerrit.libreoffice.org/39286 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-09GSoC: import VML shape adjustmentsGrzegorz Araminowicz2-0/+11
Change-Id: Ifcd49f34b889b34eba2464de6e083f9021633bc6 Reviewed-on: https://gerrit.libreoffice.org/38427 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
2017-06-09use comphelper::InitPropertySequence in more placesNoel Grandin1-10/+7
Change-Id: I72d7b13a23ce306b752b39187a0e9fbb7028643a Reviewed-on: https://gerrit.libreoffice.org/38606 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-09tdf#108408: support unit specifications for ST_HpsMeasureMike Kaganski2-0/+9
w:ST_HpsMeasure is defined in ECMA-376 5th ed. Part 1, 17.18.42 as This simple type specifies that its contents contain either: * A positive whole number, whose contents consist of a measurement in half-points (equivalent to 1/144th of an inch), or * A positive decimal number immediately followed by a unit identifier. ... This simple type is a union of the following types: * The ST_PositiveUniversalMeasure simple type (§22.9.2.12). * The ST_UnsignedDecimalNumber simple type (§22.9.2.16). This patch generalizes OOXMLUniversalMeasureValue to handle standard- defined units, and introduces two typedefed specifications: OOXMLTwipsMeasureValue (which is used where UniversalMeasure was previously used), and new OOXMLHpsMeasureValue. Unit test included. Change-Id: Iccc6d46f717cb618381baf89dfd3e4bbb844b4af Reviewed-on: https://gerrit.libreoffice.org/38562 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-08tdf#99074: export Web view to DOCXAron Budea2-12/+0
...so document saved in Web view shows in Web Layout in Word. Change-Id: If39d566be02966fe5d22f74aee46e6d5452a9451 Reviewed-on: https://gerrit.libreoffice.org/38469 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-06-06tdf#104450: Use Calibri; let LO to fallback to CarlitoMike Kaganski1-3/+2
Using Calibri will allow to keep originally intended font on round-trip. If Calibri is absent on a system, LO will fallback to Carlito for rendering, but keep original font intact. Change-Id: I8f29bed29bc7f48912b2637053ff128ea904c7a1 Reviewed-on: https://gerrit.libreoffice.org/38456 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-06tdf#108350: Use Carlito for DOCX import by defaultMike Kaganski2-0/+10
In OOXML (i.e. Word since 2007), the default document font is Calibri 11 pt. If a document doesn't contain font information, we should assume our metric-compatible equivalent Carlito to provide best layout match. A unit test included. An existing unit test (testN766487) was corrected to match the font size that Word uses (11; was 12 which doesn't match Word's size). Change-Id: I3040f235696282dc7a124cd83fb34a6d95a29a17 Reviewed-on: https://gerrit.libreoffice.org/38421 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins <ci@libreoffice.org>
2017-06-01Improve suppression of loplugin:redundantcast in CPPUNIT_ASSERTStephan Bergmann1-2/+2
Change-Id: I65f95e7245f08592ea11cc75e1cf34dcbdf16b40
2017-05-31tdf#76446 GSoC: incorrect rotation of VML shapesGrzegorz Araminowicz2-0/+7
* support poorly documented 'fd' suffix in rotation attribute * allow non-integer rotation Change-Id: I3d72f2a708e6585597db09366c00c50038abc9c1 Reviewed-on: https://gerrit.libreoffice.org/38207 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2017-05-19ooxmlexport: roundtrip tdf#103975's unit testsJustin Luth5-70/+0
MS documentation for splitPgBreakAndParaMark only mentions page breaks, not column breaks. (Always Move Paragraph Mark to Page after a Page Break) This element specifies whether a page break shall automatically complete the line on which it appears, moving the end of the paragraph to a new line on the next page, or if it shall behave as true run-level content within its current paragraph. Typically, a page break defined using the br element is treated as run-level content, which means that although it delimits the end of the page, if there is no content after it within the current paragraph, that the paragraph shall also end on that page. This element, when present with a val attribute value of true (or equivalent), specifies that a page break shall always immediately end the current page, moving the paragraph mark which delimits the end of its parent paragraph to a new line on the next page. Note that this setting only affects the case where there is no run-level content after the page break within the paragraph - if any further run content appears in the paragraph it shall appear on subsequent lines on the next page I borrowed the !footnote code from the if newline ELSE section. It seemed appropriate to take the same precautions here. || bSingleParagraph was added specifically for COLUMN_BREAK. That is obsolete now, so removing. There is a lot of old code here that I have questions about. I tried to change as little as possible, but likely lots of the existing logic is just wrong. Change-Id: Ib988c6623acb2b6152118098b706314bfbfb99e3 Reviewed-on: https://gerrit.libreoffice.org/36421 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-05-18tdf#100072 zero height of shape's path was causing geometry errorsVasily Melenchuk2-0/+45
DOCX custom geometry shape's path width and height are now used independently for scaling calculations. Change-Id: I368dd4dc065b8f122c4eb2911261e45047f03c70 Reviewed-on: https://gerrit.libreoffice.org/37639 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-05-16tdf#107801 docx export: support w:kernJustin Luth2-7/+0
Writer only enables or disables pair kerning (autokern). Word uses a minimum font size to determine which characters to kern. Since these documents are round-tripping through Writer, and every size is kerned by Writer, the minimum size is forced to 1pt and the original minimum font size is lost. This is a followup to commit 38b0c24fa5cbb4246e03d77ac022dfdc9fdede03 for related tdf#105454 DOCX import: fix unwanted enabled-by-default kerning. Tested in Word 2003, 2007, 2013. Change-Id: I7678a544f455fd06bec5e7d864b5c27ab26bf6d3 Reviewed-on: https://gerrit.libreoffice.org/37574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-23 11:51:31 +0000