summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)AuthorFilesLines
2020-10-22tdf#103987 Avoid duplication of the Custom Properties during OOXML exportBartosz Kosiorek2-37/+140
The MS Office is case insensitive for Properties. As a result properties names: ContentType and contentType are treated as the same properties. Additionally some Core and Extended File Properties does not exist in LibreOffice standard. To resolve that such properties are stored in LibreOffice Custom File Properties. For example: - category - contentStatus - contentType - identifier - version Unfortunately if user specify Custom Property which differ only with case, there will be conflict. To solve that the properties were renamed to be unique: - OOXMLCorePropertiesCategory - OOXMLCorePropertiesContentStatus - OOXMLCorePropertiesContentType - OOXMLCorePropertiesIdentifier - OOXMLCorePropertiesVersion Additionally if internal property have default value, then the value will not be imported into Custom File Property. During export to OOXML (eg. docx) The values which are already stored in Core or Extended File Properties, are not stored into Custom File Properties to avoid duplication. Change-Id: Ifc2b88ab74aa41d12ba968fff199062ce8dc96ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104384 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2020-10-22long->tools::Long in hwpfilter..ooxNoel6-8/+9
Change-Id: I9ab8876aac7b2f8b488db6dfa9c6fd0cecd2238b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104626 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-21new tools::Degree10 strong typedefNoel Grandin2-3/+3
partly to flush some use of "long" out the codebase, but also to make it obvious which units are being used for angle values. Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-20tdf#137417 oox smartart: avoid considering rules in vertical linear layoutsMiklos Vajna1-0/+6
Regression from commit 0024c48b4822062995effed7db4f1281196384bb (oox smartart: consider rules when scaling in linear layout, 2020-07-31), the problem is that I only tested horizontal layouts and this is not working for vertical layouts. Just disable the vertical case for now, to avoid unwanted side effects. Change-Id: I31a894157996a2371b8d0ec482ee91dc4d5b053e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104541 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-10-17tdf#133377 OOXML Fix storage of date in Custom PropertiesBartosz Kosiorek1-1/+3
During exporting documents into OOXML formats (docx, xlsx, pptx), if custom properties have Date format, the day and year were switched. This commit fixes that. Change-Id: Id497602eb3354de78bfd52bf5ef61d32aafd957d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104450 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-10-16fix some *printf which are using "%l" ie. long specifiersNoel1-3/+3
which are not portable between Linux and Windows because long is not portable. In preparation for converting long -> tools::Long Change-Id: I8bf1aa1570946ca887a6c83dd5f99c024d437336 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104374 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-13tdf#101122 DOCX custom shape export: remove bad fillRegényi Balázs2-3/+48
of (simplified export) of not filled custom shapes by adding missing fill="none" to a:path. Note: in OpenDocument, unfilled shape path is defined by draw:enhanced-path command "F", see section 19.145 in ODF v1.2. Co-authored-by: Szabolcs Tóth Change-Id: I0be2aada3deb06828216e0441c91c389a673f87c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104205 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-09tdf#99810 DOCX export: fix lost arrow shapeRegényi Balázs1-13/+23
by saving connector shape as shape element wps:wps instead of the invalid wps:cxnSp. Co-author-by: Szabolcs Tóth Change-Id: I0ed435eff8e4284f04f71f8fa8c1dc4cfbee5af9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104032 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-09tdf#133037 OOXML shape import: camera rotation along ZDaniel Arato (NISZ)4-4/+60
Instead of implementing proper OOXML 3D rotation (which would be an entirely new feature if I understand correctly), I merely interpret attribute "rev" of the rotation element a:camera/a:rot as a directive to rotate the entire shape the usual 2D way. That is already implemented and works well. This isn't the same thing Word does, but it might be good enough for now. This is kind of a mock solution, but it will be very easy to revert if it turns out to cause problems. Note: the export worked well previously, too (moreover, reloading the first LO export fixed the import). Change-Id: I2a99c119880bbed1c5b6430c4638cfbd10b7ac06 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103627 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-09tdf#134978 Chart OOXML Import: fix pie chart label custom positionTünde Tóth2-1/+6
Follow-up of commit dff7a46fb46d1fa2a3ad674ee493ae2d59150fe3 (tdf#130032 Chart OOXML Import: fix data label custom position). Change-Id: Iaaf4ae654ac0c1b4896a53be6034e6c027412df0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102981 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-06loplugin:const* make some params and methods constNoel1-1/+1
Change-Id: Idec482c21c270912f9bcaeb980077c1616f67c8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104022 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-06Drop unused codeMike Kaganski1-14/+2
... a leftover in commit 3187eeab10df77a6c0dd6397be993a68276d7141, copypasted in commit 4f4a668e04bdd68655a0f574027f486cea953857. Change-Id: I7a634ba432cb4736ec85a420b0f77288cd1e0802 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104004 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-10-06tdf#105875 DOCX VML shape import: fix missing rotationRegényi Balázs1-11/+15
Also to avoid bad resizing of the rotated shape, remove obsolete(?) code part from commit 0423a6741fc08a35b123556f9b10219d090ee42a (Import bezier curves from .docx.). Co-authored-by: Szabolcs Toth Change-Id: I77266ba65e558cf9e6dd0e1c37fad85abd038819 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103693 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-06tdf#137000 XLSX shape export: fix uprightSzabolcs Toth2-7/+39
Upright is an XML attribute of xdr:txBody/a:bodyPr. It is set in MSO when in a textbox menu we choose "Do not rotate this element". LO import uses a text rotation opposite shape rotation to create upright text, but when exporting the attribute "upright" we must make sure that the text rotation in bodyPr is 0, not the temporary opposite value. Otherwise MSO rotates the text. Note: integer precision of rotation is enough for interoperability, because it's possible to rotate the shapes only by whole degrees in MSO. Follow-up of commit 8c23be49fb5a9044989532e6e20feb1e3ff64f2b (tdf#106197 XLSX shape import: keep text upright). Co-authored-by: Balázs Regényi Change-Id: I0ffae41f83d3fc3a1fa37f413a8fc9fd8ccd9b6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103094 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-06tdf#137023 PPTX import: fix unexpected center alignment of shape text, 2nd tryMiklos Vajna4-5/+35
Regression from commit 10bb02efd8afd42e633e370480104e2575546d8e (tdf#129685 PPTX import: fix unexpected centering of shape text, 2020-09-18), now the problem was that some text should be left aligned, but was centered. Fix the problem by reverting most of the above commit: XML changes, changes to SdImportTest::testTdf113198() (manual testing show that this change is not needed after all) and changes to the TextBodyPropertiesContext ctor in oox/ (but not the testcase itself). Fix tdf#113198 again, this time in Shape::createAndInsert(), which is meant to be closer to what the binary PPT import does. With this, all cases from tdf#104722, tdf#113198, tdf#129685 and tdf#137023 are meant to be handled correctly at the same time. Change-Id: Id785252c26fc407cd74c9cfb55624091798d7773 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103996 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-10-04ofz#26128 check at start instead of end if encryptedHashValue is too smallCaolán McNamara1-5/+10
Change-Id: I10774802c96f6f0912a4ee3bf9a6a2a9482b7c94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103918 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel2-3/+5
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-03loplugin:reducevarscope in ooxNoel6-10/+9
Change-Id: I6f2f91b821271415c4cec0eb1e694b00b3b2f59f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103836 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-02cid#1467667 Division or modulo by float zeroCaolán McNamara1-2/+2
Change-Id: Ia332896190e09d6c5459ce80819c8f1263a60873 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103815 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-02cid#1467665 Division or modulo by float zeroCaolán McNamara1-1/+2
Change-Id: I34446609f25b5fdf2c6c537a6a0f6085c707b0c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103816 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-30oox smartart: extract snake algo from AlgAtom::layoutShape()Miklos Vajna2-300/+339
AlgAtom::layoutShape() is more or less the single function where all layouting happens for all algoritms. Extract the snake algorithm part from it to a separate SnakeAlg::layoutShapeChildren() before that function grows too large. Change-Id: I5e5ae66d16770fa72db6edf5df4cbd2ef3eea9c2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103686 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-30oox smartart: snake algo: make sure child shape height stays within parentMiklos Vajna1-6/+28
1) When applying double outside spacing, introduced with commit 0a29c928afa74123bca05dc089c751603d368467 (oox smartart, picture strip: fix lack of spacing around the picture list, 2019-02-26), make sure that is only applied in the direction of a signle row: i.e. the bugdoc case is left/right outer spacing, but no top/bottom spacing. 2) If a child shape has an aspect ratio request, make sure that it only decreases what would be allocated by default, so the children never leave the parent's rectangle. 3) Fix a mis-match between the first and second row, the unexpected small left padding in the second row was because code assumed that all child shapes have the same width; which is not true, when widths come from constraints. With this in place, we finally do a good rendering of the bugdoc, and child shapes are always within the bounds of the background. Change-Id: Ia2606dcd945402f7dfe17c6e2f261bfd98667022 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103680 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-29oox smartart: snake algo: apply constraints on child shape widthsMiklos Vajna1-10/+47
This requires tracking what is the total of the width request of child shapes, then scaling them according to what is the total available width. Additionally, the height of child shapes should be adjusted based on their aspect ratio requests. A related trap is when an (invisible) spacing shape is at the end of the row, that would result in smaller spacing between the rows, so track the max height of shapes inside a single row. With this, finally the 6 child shapes are arranged on 2 rows, not 3 ones. Change-Id: I4eb2f06676df11c1432e0934ca3a0ec8891c5843 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103629 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-29oox smartart: snake algo: start parsing relative width constraintsMiklos Vajna1-13/+90
This is needed, but not enough to have the correct width for each shape and spacing item on the path of the snake. Currently we give the same width for all children, while the shapes typically have a larger width than the spacings. Change-Id: I4e2638ea5b566c21cb1cf503a8cf2e5d35256e3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103594 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-29tdf#91251 XLSX textbox export: fix missing overflow propertiesRegényi Balázs4-4/+28
by grab-bagging them. Co-authored-by: Szabolcs Toth Change-Id: I242bf33e1272d913805c90a2ef902be8633618fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103182 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-29tdf#80526 DOCX: import word-wrap textbox settingRegényi Balázs1-0/+5
See option "Word wrap text in shape" in Format->Text Box and Shape->Text Attributes... of the selected textbox. Co-authored-by: Szabolcs Toth Change-Id: I7f2ca392089043c4bec20b943aa8c1975de72e5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103109 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-27Fix typo in codeAndrea Gelmini1-3/+3
Tested before split here: https://gerrit.libreoffice.org/c/core/+/103464 Change-Id: Iadc9dd49762ec63bd8b3edba322bcbf5d0f862a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103487 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-25oox smartart: snake algo: consider child's aspect ratio request for cols/rowsMiklos Vajna1-2/+9
If the child's aspect ratio request will shrink the width, then take that into account when calculating how many rows / cols we need. This reduces the number of columns for the bugdoc from 4 to 3, which is needed, but not enough to render it correctly. Change-Id: I1d02df4834b8a2ce97d5e006db0e3135d3d42917 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103411 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-25fix Graphic duplication in import and add GraphicMapperTomaž Vajngerl4-12/+53
When importing writerfilter, we change to oox when importing images. This transition doesn't store any previous contexts and all instances are reset. The problem occurs when we have identical images because the transition erases all caches we have to determine if an image has already been imported or not, which causes that we import the same image multiple times which create unnecessary copies. This introduces the XGraphicMapper, which can be used to store the XGraphic for a key and can be transferred between writerfilter to oox. With this we can remember which images were already imported and don't create unnecessary internal copies which decreases memory. This also includes a test which checks that the import and export doesn't produce unnecessary copies of identical images. The test checks that for OOXML, ODF and MS Binary formats. Change-Id: I33dc19218c565937fab77e132b3a996c51358b6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103283 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-24Fix typoAndrea Gelmini1-2/+2
Change-Id: I4f73bed05f994769f2c9b12e49e4102b3af6fc6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103321 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-24Fix endianness issues in OOX crypto routinesStephan Bergmann2-14/+30
...without which CppunitTest_sw_ooxmlencryption failed on (big-endian) s390x: * The 32-bit segment counter in AgileEngine::de-/encrypt apparently needs to be stored in LSB format (at least, if it is, CppunitTest_sw_ooxmlencryption ultimately succeeded, whereas otherwise it failed). * The UTF-16 string in Standard2007Engine::calculateEncryptionKey apparently needs to be in LSB format (at least, if it is, CppunitTest_sw_ooxmlencryption ultimately succeeded, whereas otherwise it failed). * The various 32-bit values in the EncryptionStandardHeader and EncryptionVerifierAES data structures apparently need to be written out in LSB format in Standard2007Engine::writeEncryptionInfo, given that they are always read in LSB format in Standard2007Engine::readEncryptionInfo. Change-Id: I3a1efbfe324b1bbd539b88dc5d40bb44f9676ffa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103315 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-24tdf#106197 XLSX shape import: keep text uprightSzabolcs Toth4-23/+44
Handle and grab-bag attribute upright to keep text upright regardless of shape rotation, fixing the text direction after import and after a round-trip. Co-authored-by: Balázs Regényi Change-Id: If4c73aeaebad55af967cea894a94756068ca3766 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102870 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-23tdf#136566 XLSX export: fix lost scheme based line colorsRegényi Balázs2-8/+52
by converting scheme color identifiers to colors temporarily. Because we haven't exported theme XML yet, we could not import shapes of these exported documents correctly, resulting missing lines. Co-authored-by: Szabolcs Toth Change-Id: I4f3d19cb8a9a851fb07a97f798195011e420d441 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102722 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara6-13/+13
do more like commit 121771e37f7e2de41cd5643475861062bf25627b Date: Mon Sep 21 09:17:54 2020 +0200 Make some OUStringLiteral vars constexpr cause coverity can live with that Change-Id: I9efd7f848289c4865997a44c6780373068422227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-22tdf#136650 DOCX pie chart import: fix percentageBalazs Varga1-8/+14
Follow-up of commit e0da00d655ecca5986eea3812a8a670c6adbc40f (tdf#132174 Chart DOCX import: fix label number format). Change-Id: Ie0b2fe6305d7696de6dddc1f17d078fc2e749e4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102753 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-22tdf#123610 DOCX shape import: keep text uprightSzabolcs Toth2-0/+30
Grab-bag attribute upright to keep text upright regardless of shape rotation, fixing the text direction in MSO after a round-trip. Co-authored-by: Balázs Regényi Change-Id: If18a12c7728317a7af093048b07bc392d2964389 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102690 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-21tdf#136620 tdf#136708 filter,oox,sw: fix export of 2 different wrapsMichael Stahl1-4/+18
This reverts commit 2cb90a5c87fe46737c8d840967d8836284f92ffd. Revert the change to EscherPropertyContainer, which was completely bogus, based on pre-existing bogus code in VMLExport::Commit(). The problem is that ESCHER_Wrap values are for wrapping text *inside* a text box, which is "mso-wrap-style" in VML, whereas VML's w10:wrap element defines how text wraps *around* a shape, doesn't exist as an ESCHER property and is specific to Word formats. Instead, export the w10:wrap element in VMLExport::EndShape(). This has 2 callers, WriteActiveXControl() and writeVMLDrawing(). Furthermore the value "none" wasn't written for WrapTextMode_THROUGH, which caused the wrap element to be omitted in that case. Change-Id: Id4a01fcb2ea73fa9bef4ee8769b5e0680e059f15 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103009 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-21tdf#136247 Change element order of data labelsGülşah Köse1-2/+2
Reference OOXML (Appendix B.5.1, line 248) Change-Id: Idf5c2546b4ad65c8e78ca03e18ecfa575ef17fe8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103005 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-09-18tdf#129685 PPTX import: fix unexpected centering of shape textMiklos Vajna4-1/+27
Regression from commit 89f0af144c18efafe2573801641689a1432c0cae (tdf#113198 set default shape paragraph alignment.., 2019-11-19), the old bugdoc had this markup: <a:bodyPr ... anchor="ctr"/> (centered) The new bugdoc has 2 shapes with text: <a:bodyPr .../> (aligned to left) <a:bodyPr ... anchorCtr="1"/> (should be centered) "anchor" is about vertical, "anchorCtr" is about horizontal centering of text. Checking what the binary filter does, it maps horizontal centering to TextHorizontalAdjust, so fix the original bug differently, by leaving ParaAdjust alone, and tweaking TextHorizontalAdjust intead: this keeps the old bugdoc working but fixes the new one. This caused a number of "change detector" XML-based tests to fail: all of them are unchanged visually, so the XML files are adapted to the new state. The tdf#113198 fix itself was fixing a regression from tdf#104722, and that commit had no testcase, I tested that we don't regress there, manually. Change-Id: I81a7b3e8c76bfbce5c5569d16d5238958ac20f75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103012 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-18tdf#136830 Fix: positions of group shapes of PPTXnd1011-1/+13
For certain PPTXs, Impress fails to import the document with correct group shape positions. More specifically, chExt (Child Extents) calculation should take the values from group shape when 0 is given. Change-Id: I1f8e89dcfe61ab2071ad00850ff99aecb7218067 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102895 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-09-18tdf#136247 OOXML export data label background color.Gülşah Köse1-6/+25
Change-Id: Ie3e00e8195239e6570bfe76c2451bae11c209145 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102999 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-09-18tdf#124013 XLSX shape export: fix missing solidFillRegényi Balázs1-27/+1
of the inside of the shape (resulting for example, invisible shapes). See also commit 83c30743eaf44d8eded4a73e3ac2585b5bdbaffc (tdf#77236 DOCX shape export: fix missing solidFill). Co-authored-by: Szabolcs Toth Change-Id: I4efde86f82e22e1aa49b89dc13557ef5f238ba83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102871 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-18tdf#136267 OOXML Chart Import: create main category axis labels onceBalazs Varga5-8/+7
because InternalDataProvider can not handle different category names on the primary and secondary category axis. Revert e0b0502516a10181bbd1737b93b38b2bba4c98e8 commit, except the relevant unit test. Regression from commit: e0b0502516a10181bbd1737b93b38b2bba4c98e8 (tdf#128016 Chart OOXML Import: fix duplicated category labels) Also fix tdf#129994 (FILEOPEN - hang at import time), which is a a regression from commit fa0a981af41a2606541eec1cb20a379a739691e0 (tdf#114166 DOCX chart import: fix missing complex categories) Change-Id: I5d049e760eb1a647ea774be264349a2f16f15f5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102463 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann3-4/+11
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-16clean-up of commit 83c30743eaf44d8eded4a73e3ac2585b5bdbaffcRegényi Balázs1-11/+0
Change-Id: Ic49b9337e6accea6c9045f1da377eafcb683a1c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102721 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2020-09-15tdf#103611 sw: fix vertical alignment to page bottom marginTibor Nagy1-2/+6
Allow to align objects to page bottom margin vertically in Position and Size settings. Fix also DOCX import of VML shapes. Co-authored-by: Attila Szűcs (NISZ) Change-Id: I78db2553ee9d963b18a2d580b1cbb76c1917ac0b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102379 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-14oox smartart: handle <dgm:prSet ... custT="1"/>Miklos Vajna1-1/+55
Which defines that a data node has text properties as direct formatting, so autoscale should not happen. We decide autofit at a shape level, smartart defines custom text props at a data node level. So take the shape, go to its first presentation node, get its data node and see if it has custom text props. If not, continue to scale text down till it fits. smartart-autofit-sync.pptx is extended to contain a 3rd shape: the first two have their autofit scaling synchronized, while the 3rd has a fixed font size of 10pt. Change-Id: I6caacdaab9a36072b9ad5021bd217c955b09b790 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102689 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-12Fix typosAndrea Gelmini1-1/+1
Change-Id: Ica93ad739eb32372addc01e1c72804e33d8ce819 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102508 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-11log what token was unexpectedCaolán McNamara1-1/+1
Change-Id: I192bd691816a044dbca389621730ca7ee3a584e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102453 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-11oox smartart: add support for syncing font heights of multiple shapesMiklos Vajna7-11/+126
When 2 or more shapes have their text set to autofit and they have a constraint like: <dgm:constr type="primFontSz" for="des" forName="node" op="equ"/> Then make sure that the automatic font size is the same for all shapes and all content fits, by using the smallest scaling factor from all relevant shapes. Some rework is needed, because normally oox::drawingml::Shapes don't have access to their parents, at the same time there can be multiple SmartArts on a single slide, so storing the grouping info in the filter is problematic, too. Solve this by storing the grouping in the toplevel oox::drawingml::Shape and exposing them in XmlFilterBase just during the time the children of the toplevel shape of the SmartArt are added. This works, because we know SmartArts can't be nested. Change-Id: I6c591eadc7166c7c42752650afdb7ee1e416cff6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102490 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-13 11:33:30 +0000