summaryrefslogtreecommitdiff
path: root/sw/qa/extras/ooxmlimport
AgeCommit message (Collapse)AuthorFilesLines
2016-07-20vcl: bmpacc.hxx -> bitmapaccess.hxxChris Sherlock1-1/+1
(cherry picked from commit 88730cdae3520b18fc073dc59bd0ed660e15d6b4) Change-Id: I4bb19d6103c4a6a902d86b62a857e3478493924c
2016-07-08tdf#95367 inherit page style if no new one importedJustin Luth2-0/+5
CopyLastHeaderFooter doesn't do much good if the previous section has blank stylenames. (usually because of continuous section breaks). Change-Id: Ida1e42ab0b650c7c43f06539b3cc058fe5c27919 Reviewed-on: https://gerrit.libreoffice.org/26911 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 1127bed4d943036473dbbda6bcfae1ec0a23ed2e)
2016-07-07DOCX export: handle <w:smartTag>Miklos Vajna2-40/+0
A Writer document can have multiple arbitrary RDF graphs, handle the following subset: - instead of handling all graphs, have a whitelist, look at the TSCP graph the DOCX importer creates - look for (paragraph, key, value) statements and export those (cherry picked from commit 08e5fc257fa8c106be34bb034ebe5e00b6fcf711) Change-Id: I142c24fb4c8140bde5fc1efad2932886de167b90
2016-07-07DOCX import: handle <w:smartTag>Miklos Vajna2-0/+40
These can be sort of arbitrary key-value pairs around one or multiple runs, handle the following subset: - when they appear at a paragraph context -> we assume they are annotations on the paragraph - when the smart tag's URI/element is RDF -> we map these to RDF metadata statements on paragraphs - when the attribute name's namespace is known, because in ODF we need to specify both a path and a type (namespace) for the RDF graph, and OOXML only provides a namespace As a start, recognize the TSCP BAF namespace from <https://www.tscp.org/wp-content/uploads/2013/08/TSCP_BAFv1.pdf>. Change-Id: Ib188b1395e7ec7e0441b4f12f86cfef99fb9f096 (cherry picked from commit 831492f3d50f3d131f458f4ec0e5e802b612923f)
2016-06-22tdf#92157: allow both dimensions of a graphic to be 0Mike Kaganski2-0/+5
Commit ca80f73 made it possible for one of dimensions to be zero. This commit goes further, allowing opening real-life documents with graphics having both width and height equal to 0. Thanks to libreoffice@arbruijn.dds.nl for debugging and initial patch! Change-Id: I96a13b776adfd9fe46fc2c7691eb7904400c20a1 Reviewed-on: https://gerrit.libreoffice.org/21287 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com> (cherry picked from commit 654f6ff28d7a148950b48ed8905d8f13a015a5b5)
2016-06-11tdf#99074 DOCX import: handle <w:view w:val="web"/>Miklos Vajna2-0/+8
Instead of always using the Normal view, use the Web view when the DOCX file contains Web Layout. For this to work, expose sw's DocumentSettingId::BROWSE_MODE via css.document.Settings. Change-Id: I7787ca058d8cb8a346b2001a2bd70c3df86d8673 Reviewed-on: https://gerrit.libreoffice.org/23806 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit e0f9bb795251d950b5dd960fcd030170c8eb67aa)
2016-05-03tdf#93640 Fix import of linked left page header/footerLuke Deller2-0/+100
In a docx section, any header/footer which is not defined in the section is considered to be linked to the previous section. In the Word UI this is shown as an option named "Link to Previous", and editing the header/footer in either section affects both sections. LO imports this by copying the header/footer contents from the previous section, but it did not handle the case where a section had different headers for left pages vs right pages. Fix this, which involved changing the mechanism used to detect whether a section has defined a certain header/footer (which unlinks it from the previous section): rather than trying to figure it out from the converted LO page styles, explicitly track which headers/footers have been defined using boolean member variables on the SectionPropertyMap instance. Conflicts: sw/qa/extras/ooxmlimport/ooxmlimport.cxx Change-Id: Ic43a867356c2cd5df09d39f2a3ddefa584b6765c Reviewed-on: https://gerrit.libreoffice.org/24608 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-05-02tdf#99135 VML import: handle image cropMiklos Vajna2-0/+6
The spec says in theory a % suffix could be also supported, but let's wait till that is seen in a real-world document. Change-Id: Ie026915e38dcb03c99085a1740075364b00e1c8d (cherry picked from commit bb646c1472d3b77066b01128baf1c9cafdb40233) Reviewed-on: https://gerrit.libreoffice.org/24364 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2016-04-14tdf#99140 DOCX import: fix table at the bottom of the page to span over ...Miklos Vajna2-0/+15
... multiple pages. In short, one more blacklist entry when conversion should not be performed. Conflicts: sw/qa/extras/ooxmlimport/ooxmlimport.cxx Also (because otherwise the first commit would introduce a regression): tdf#99140 DOCX import: fix table horizontal aligment to be 'from left' ... ... when it was 'manual'. Regression from commit c1e563f6efd09cd3463f1b92a3022ae288c92087 (fdo#76741 [DOCX] Table Alignment and width type, 2014-04-04), DOCX import code had to deal with two kinds of horizontal alignment when it came to floating tables: the alignment of the table itself, and the alignment of the float parameters. The problem is, in general it's wanted that the table is aligned according to the floating parameters, but in Writer the "from left" UI setting is described differently for tables and fly frames: tables use LEFT_AND_WIDTH for that, while fly frames use NONE. Fix the problem by touching the default only in case the floating parameters have something that's different from NONE. With this, the width of tables is no longer lost when they are described to be floating ones in the DOCX markup, but FloatingTableConversion() decides to ignore that. (cherry picked from commits d56deaeb2a1e8007e50fc2334f416fddd4e3cde3, c07f04ab422eadba0f2c3c128a0e3ff78e90cdf2, and fd61dee6457a44687f1142dd55bfee6b64fda2ef) Change-Id: I764f02cc58ae1b7af802b81e570e4feaf73ee2c1 Reviewed-on: https://gerrit.libreoffice.org/23986 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2016-03-29tdf#98882 DOCX import: set default para properties on the Standard para styleMiklos Vajna2-0/+8
That's what the DOC import does, and that's the reason e.g. the strange unwanted crop of the as-char anchored picture doesn't happen there. This also needs the "reset all existing style properties back to default" logic to be adapted: the Standard style has to be reset before the default are set, and later it should be left alone, otherwise the defaults are lost. Conflicts: sw/qa/extras/ooxmlimport/ooxmlimport.cxx (cherry picked from commit eae2331f83bd58bacccd898d60f6c5f54856c036) Change-Id: Ie422a0b64b80a826fa4f469145a26283fb32d734 Reviewed-on: https://gerrit.libreoffice.org/23597 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2016-02-18tdf#97371 DOCX import: fix text covered by shapeMiklos Vajna2-0/+15
Regression from commit 358666e4204364ce915ee95372dc6f2fca545253 (tdf#90153 DOCX import: fix default sw TextFrame roundtrip, 2015-09-28), the problem was that at the moment SwTextBoxHelper::syncProperty() doesn't handle an AnchorType at-para -> at-char transition, so the importer shouldn't do that for TextBoxes till sw core gets extended to support the scenario. (cherry picked from commit 8f1a1092d47947847e1d888b0284e8364c663d1f) Conflicts: sw/qa/extras/ooxmlimport/ooxmlimport.cxx Change-Id: I8308bfd306672bc68984fbf019767c174130e18d Reviewed-on: https://gerrit.libreoffice.org/22483 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-02-18tdf#95376 DOCX import: fix incorrectly indented tab stopsMiklos Vajna2-0/+9
Regression from commit f4badd9a485f32f787d78431ed673e2932973887 (tdf#92454 DOCX import: allow overriding para prop from num style in para style, 2015-09-22), the problem was yet another priority mishandling in the maze of various styles and indentation handling. In the tdf#92454 bugdoc, both a numbering-from-paragraph-style and a paragraph-style defined indentation, and Word preferred the numbering, while Writer preferred the paragraph style, that's why the import-time conversion was added. However, it turns out there is a 3rd source that's still not direct indentation formatting: a direct numbering. So the correct priority is: direct-ind > ind-from-num > ind-from-parastyle > ind-from-num-from-parastyle Which means in this case the indentation should not be set directly: the two conflicting value (ind-from-num and ind-from-parastyle) will be resolved correctly by Writer core. Given that we always first get the para style info, and only then the numbering, we just need to undo the conversion added for the other bug if we see a direct numbering, then both the old bugdoc and this new one will be handled properly. Change-Id: I09cc84605d5df6159da985ad069d46b580a53358 (cherry picked from commit 3915bf2dc877d5f1140798e24933db0f21386a4a) Reviewed-on: https://gerrit.libreoffice.org/22307 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-02-15sw: ensure that configuration change in odfexporttest.cxx ...Michael Stahl1-6/+9
... is reverted in case the test function throws an exception, so that subsequent^Wfollowing tests don't inherit the changed configuration. Change-Id: I748f9edf15a7f860607ae4cce891450db254c73e (cherry picked from commit e2bfae9006e6adc4de17d0167dac6661b002f126) Reviewed-on: https://gerrit.libreoffice.org/22333 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-02-11tdf#85523 DOCX import: fix unexpected extra char at comment endMiklos Vajna2-0/+8
(cherry picked from commit 39969defa29948d77565a7cd8a3471baaec8f35d) Change-Id: Ic3eb073d11a395a81b90fd1a9292d6ecf2940c09 Reviewed-on: https://gerrit.libreoffice.org/22157 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-02-02writerfilter: tdf#97417: don't insert numbering on end-of-sectionMichael Stahl2-0/+12
... paragraph, it will be copied to every following paragraph. (Before commit 2b78f2cd7b9e4bab0f3b3b9119238f36a1bbc7b2 the properties of the end-of-section paragraph would be overwritten by the properties inside the header) Change-Id: Ibe095cf873a09ef9e12f898d09b5fd6f61c914c9 (cherry picked from commit 57def64bec0853de7d6f4243e31e8e9650491914) Reviewed-on: https://gerrit.libreoffice.org/22000 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-01-12tdf#95213 DOCX import: don't reuse list label stylesMiklos Vajna2-0/+14
We used to optimize the creation of these styles, so in case two list label had the same character properties, then we could avoid creating two styles for those. This isn't correct though: it means if the style is changed later by the user, then unexpected other places in the document will change as well. Do what the binary DOC filter does: create one character style for each level of a numbering separately. (cherry picked from commit f9c8d97d82a85b897520a2fe897352ee5ad879d9) Change-Id: I967b30fc078b1be30f7ef81b2706df2962fc3fb0 Reviewed-on: https://gerrit.libreoffice.org/21386 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2016-01-11tdf#92045 DOCX import: <w:effect w:val="none"/> doesn't mean blinkingMiklos Vajna2-0/+6
Regression from commit eeb8297e47bae11f2aeaa7bae6e51eee921e9e58 (Use constants for ST_TextEffect values, 2014-09-22), the problem was that while the tokenizer stopped using hardcoded token values, the matching dmapper code wasn't adapted. (cherry picked from commit ac6bfd85df271b650dbd24b45391dac346ecd72c) Change-Id: Id61912e9c9458efc87e0a6f8e461663942c555f0 Reviewed-on: https://gerrit.libreoffice.org/21343 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2016-01-08tdf#96674 drawingML import: fix handling of zero width/height linesMiklos Vajna2-0/+10
(cherry picked from commit 627c2469843c9461b665c4571f1214aca7fc36a4) Change-Id: If3d9f6272031e08ab228cfa58963d60ceede2498 Reviewed-on: https://gerrit.libreoffice.org/21115 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2016-01-05tdf#69640: Treat errors opening OLE stream gracefullyMike Kaganski2-0/+5
The testcase for tdf#69640 includes links (relations) to external pptx files. It demonstrates two non-fatal reasons for failure opening OLE stream: 1. it fails OStorageHelper::IsValidZipEntryFileName check, because the file path contains ":\"; 2. even if that were not the case, the required file can be absent from user's system. I suppose that intercepting the failure at the level of OOXMLOLEHandler::attribute() is the best option, because at the lower level it's unknown if this failure is fatal or not. I suppose that it could be also useful to intercept specifically failures in OStorageHelper::IsValidZipEntryFileName, checking if the file exist externally, and asking users if they want to update external links (as MSO does). Possibly it should be discussed with UX team if that should be done, and if so, do it in separate commit. Change-Id: I240a6f69abe236eb790bb406c79f3b761fb4638a Reviewed-on: https://gerrit.libreoffice.org/19963 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit 26eb0debda788d996d9bd63d72947652a5066087) Reviewed-on: https://gerrit.libreoffice.org/21105
2015-12-03Related: tdf#94043 DOCX import: fix column separator handlingMiklos Vajna2-0/+8
See wwSectionManager::SetCols() for the DOC import equivalent of this code, if line width is 0, then there will be still no visible line. Change-Id: Ifb0dc596e252a60cdac575fff2894aced1580c69 (cherry picked from commit be6a428c08467ec379b58c8908580a282f9a9d01)
2015-11-24Resolves: tdf#95962 incorrect scanline strideCaolán McNamara1-1/+1
we were reusing the stride of the surface we were cloning, but the new surface has a different underlying size. remove the custom stride argument and just change our stride calculation to use the same scheme that cairo and GDI uses, which remove another platform/drawing-system variable Change-Id: I257dac9757b121642e9ccfde7db0911edc9f3fb1 Reviewed-on: https://gerrit.libreoffice.org/20149 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-11-24tdf#95970: Don't loose mirroring in SdrTextObj::TRSetBaseGeometryMike Kaganski2-0/+28
Currently, negative scaling (mirroring) is lost in SdrTextObj::NbcSetSnapRect, when rect is justified. This patch cares for this. Possibly it's better to make these changes directly in SdrTextObj::NbcSetSnapRect? Change-Id: I353ff01626e15b398de95e28eae78572991dfdc3 Reviewed-on: https://gerrit.libreoffice.org/20109 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2015-11-24tdf#78902 VML import: workaround for extreme top marginMiklos Vajna2-0/+6
Regression from commit 2b78f2cd7b9e4bab0f3b3b9119238f36a1bbc7b2 (rhbz#988516: DOCX import: fix context stack when importing header/footer, 2014-03-05), though that just made an existing Writer layout problem visible. RTF/WW8/newer (drawingML) DOCX import doesn't have this problem, as those import pictures as sw graphics, not draw ones. <w10:wrap type="through"/> is normally mapped to our page wrap (as it uses "through" in the "not only wrap around, but also in the holes of the shape, if it has any" context, not in our "text should go through it, so no wrapping" one), but for some reason in this case (most probably due to the extreme large negative margins) Word handles the situation as our through, i.e. the text should not go to the second page, as it would normally happen with a "Word through" wrapping. Work around the strange situation by ignoring the wrapping request for extreme top margin values. Change-Id: I20555b1fa7a769e20c40a3a5ff3873807403e937
2015-11-23tdf#60351: Use Wrap Polygon also for PROP_SIZE_PIXELMike Kaganski2-0/+24
Since commit 2b5bf2f1c57d6585ec898c4c44a74c5b47f09ab9 "graphic import improved" from 2006-11-20 by Oliver Specht, there is an unused code reading pixel size (PROP_SIZE_PIXEL) of an image in a part of GraphicImport::createGraphicObject() that imports the wrap polygon. When there's no PROP_SIZE100th_M_M in graphic, the imported wrap polygon was simply dropped, and then automatic contour was generated for graphic. Now we import contour correctly in this case. Also, as paragraph background overlaps non-opaque graphics, we need to set opaque to true regardless of behindDoc value of wp:anchor. Change-Id: Ifa5eec9f8ccaf5ba051732b6e4f965ae8606a1cf Reviewed-on: https://gerrit.libreoffice.org/20103 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Michael Meeks <michael.meeks@collabora.com>
2015-11-16tdf#83300 DOCX import: 'TOC Heading' should not be 'keep with next' by defaultMiklos Vajna2-0/+6
On one hand, neither our binary DOC import, nor Word maps the "TOC Heading" style to something special, and that's how the DOCX import added that property to some paragraphs in the document, moving the as-char picture from the first to the second page. OTOH, the DOCX export filter has a lcl_guessQFormat() function that explicitly assumes that such a style name exists in Writer document models, so again it doesn't make sense to handle this style name with special care. Change-Id: I3af548930f9683695fc3ad56b486e013f107d61a
2015-11-16use cairo-compatible top-down direction virtual devices everywhereCaolán McNamara1-1/+1
that way we can use cairo to text render etc onto our basebmp-backed headless/gtk3 virtual devices Change-Id: I91002b610b72a4fe1d2094a57c5cb1b6b5d69cb1 Reviewed-on: https://gerrit.libreoffice.org/19957 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-11-14tdf#95775: Allow zero shape width/height; fix setting width/height relationMike Kaganski2-0/+5
Conflicts: sw/qa/extras/ooxmlimport/ooxmlimport.cxx Reviewed on: https://gerrit.libreoffice.org/19962 Change-Id: Ic91ebf4a18a77704dc1ccd1e1180b42d0bc84c74
2015-11-12bin/rename-sw-abbreviations.sh run to fix few re-introduced abbrvtns.Jan Holesovsky1-6/+6
Change-Id: I11d282c3be86feb57f5279220d84d8a121df0dbd
2015-11-11tdf#85232 WPG import: fix handling of line shapesMiklos Vajna2-0/+11
The missing convertMm100ToTwip() calls mispositioned the line shapes inside the groupshape in case of using drawingML inside DOCX files. Change-Id: I0c9d652de43d779f9073a8bfe22866ce4f31d0fa
2015-11-10tdf#95071: fix spacing calculations for border with page offsetMike Kaganski1-1/+1
With commit ebf767eeb2a169ba533e1b2ffccf16f41d95df35, some previously hidden bugs manifested themselves, this is one of them. The margin size calculated incorrectly when border offset was from page. The border is drawn from the margin inwards, so the margin should be equal to OOXML w:space attribute, and border distance should be OOXML page margin - border distance - border width. Incorrect calculation gave negative margin, with IllegalArgumentException thrown in SfxItemPropertySet::setPropertyValue. Change-Id: Ifcf4a348e975df53410933aab3684d17f68b688c Reviewed-on: https://gerrit.libreoffice.org/19586 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
2015-11-06com::sun::star->css in sw/qa/Noel Grandin1-1/+1
Change-Id: I4a0282291c7737a981dbff0722228824904f07e4 Reviewed-on: https://gerrit.libreoffice.org/19804 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2015-11-05use uno::Reference::set method instead of assignmenNoel Grandin1-2/+2
Change-Id: I76671a74150791e1a74ece3d5bcf40fd6c727ac7
2015-11-04loplugin:stringconstantNoel Grandin1-1/+1
Change-Id: Ic135382652966e80c288f3407508bdaf0c60316e
2015-10-19Use comphelper::InitPropertySequence()Miklos Vajna1-7/+7
Change-Id: I10d7fa6180b09f2304227e9fab81bba88f46294f
2015-10-19tdf#94374 DOCX import: allow insert -> object -> documentMiklos Vajna3-0/+30
Change-Id: I977930d59ef1ae9ae8bd2dfa9a7f3816c46d982c
2015-10-12Replace "SAL_OVERRIDE" with "override" in LIBO_INTERNAL_ONLY codeStephan Bergmann1-2/+2
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
2015-10-12tdf#89165 sw: looping layout in SwHeadFootFrm::FormatSize()Miklos Vajna2-0/+5
FormatObjsAtFrm() returns false, indicating that the result is not perfect, and the caller hopes that formatting all children of the frame again will help. Make sure that in case that assumption turns out to be false, we at least do not loop. The loop limit is enough to make the original i#43771 bugdoc still laid out properly. Change-Id: Ife9bd99a628a72edb922d04e05081971b6adf340
2015-10-07tdf#90810: skip breaks outside of the requested footnoteOliver Specht2-0/+12
the footnote stream is parsed completely at each footnote insertion (line) breaks outside of the requested footnote need to be skipped test include Change-Id: I78de7774b7daf44c2b8980115870082fc56924bd Reviewed-on: https://gerrit.libreoffice.org/19228 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
2015-10-06tdf#91417: import hyperlink with history flag correctlyOliver Specht2-0/+10
ignore '\h' flag in hyperlinks imported from docx including import test Change-Id: I512e811050704f118bf9b2c786378f99e5d04378 Reviewed-on: https://gerrit.libreoffice.org/19154 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Oliver Specht <oliver.specht@cib.de>
2015-09-30Fix typosAndrea Gelmini1-2/+2
Change-Id: Iad3a3d77c5d4412a5c0e0b6adcb9bff3389f863c Reviewed-on: https://gerrit.libreoffice.org/18983 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-09-28bnc#939996 tdf#93919 DOCX import: fix left-from-style and first-from-directMiklos Vajna2-0/+6
With this, <w:ind w:hanging="..."/> as direct paragraph formatting and <w:ind w:left="..." w:hanging="..."/> as a numbering level formatting is properly merged, i.e. w:left is not lost, defaulting to 0. Change-Id: If5534fbd9ee6d41139b0ed3a3df9d0cc5aad3239
2015-09-28tdf#90153 DOCX import: fix default sw TextFrame roundtripMiklos Vajna2-0/+6
The AnchorType of the shape was at-paragraph, which does not allow line-level VertOrientRelation (which is correct, it would be undefined, what line of the paragraph should be the used). Fix this by changing the AnchorType to at-character in the line-level case, which brings the filter in sync with the DOC one. With this, import of a DOCX file that was created by inserting a TextFrame into an empty document is roundtripped without shifting the shape up considerably. Change-Id: I6d85c38be859d6e730584f2349c857b87496a1d4
2015-09-23tdf#92124 DOCX import: don't add a dummy Suffix for an empty LabelFollowedByMiklos Vajna2-0/+12
Change-Id: I0c4366ad0a2f81a198860869f670767343a392be
2015-09-22tdf#92454 DOCX import: allow overriding para prop from num style in para styleMiklos Vajna2-0/+9
Word has a feature like this: a paragraph style can refer to a numbering style, and both can specify paragraph margins. If that's the case, then the ones from the paragraph style has priority. In Writer, the numbering style has priority, so the only chance for correct import result is to set the margin directly on the paragraph in this case. Change-Id: Iff3b03bcc56e0db3a48452c293acf41c91b8f159
2015-09-11tdf#94045: negative margins in OOXML reenabledOliver Specht2-2/+36
OOXMLUniversalMeasureValue is an integer value and needs to be converted to a signed integer. unit test included Change-Id: I7fe3fdf4b8b12df55e9cea2a968b9537676687eb Reviewed-on: https://gerrit.libreoffice.org/18496 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Oliver Specht <oliver.specht@cib.de>
2015-09-01switch to 64-bit checksum: now BitmapChecksum is a sal_uInt64Marco Cecchetti1-1/+1
Changed hardcoded checksum value in ooxmlimport unit test (testN777345). Change-Id: Ied43bf626be82c0e7f6c62e965d0704fc645ac19
2015-09-01Added support for computing 64-bit checksum of bitmap in OpenGLMarco Cecchetti1-1/+1
Added a C++ and a GLSL implementation of a 64-bit CRC algorithm. Changed hardcoded checksum value in ooxmlimport unit test (testN777345). Change-Id: I16bb985a14866775efda49e21fe033ff64645896
2015-08-29sal_uLong to sal_uInt32 for CRC32Matteo Casalin1-1/+1
Change-Id: Id13e07f479615b8eb39d05e6534f514277cc3d03
2015-08-27Improving Asian phonetic guide for docx and rtf files.Mark Hung2-0/+17
RTF import, export, and ooxml export for ruby text are implemented. tdf#49073 - FILEOPEN: Furigana (ruby text) and characters with them are missing in opened .docx files. tdf#50786 - [TASK, METABUG] FILEOPEN, FILESAVE, FORMATTING : Japanese ruby-character handling is broken Change-Id: I4a5c30bad180241e3344e9da7efe7da4369fb325 Reviewed-on: https://gerrit.libreoffice.org/17241 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2015-08-03tdf#87924 DOCX import: rot=90 and vert=vert270 means no text rotationMiklos Vajna2-0/+8
If the shape is rotated 90 degrees clockwise and the text is further rotated 270 degrees clockwise that means we shouldn't do anything with the text and the result will be correct. Change-Id: I7c65319258136288520bd24fa2bf8e3c598b0878
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-22 11:48:14 +0000