summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)AuthorFilesLines
2020-07-29throw if length of keys and values are differentXisco Fauli1-0/+4
See https://crashreport.libreoffice.org/stats/signature/%60anonymous%20namespace'::WriteAnimateValues This is expected to start rejecting broken files, instead of accepting invalid data silently, as it did before. This is not a regression, and should be indication of corrupted generator, which is the actual cause of the bug... Change-Id: I66dbb380e8b2d313e58cddf938d952aed4a635b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99327 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit bcdcdaa5dfc5f1d50e0239055161b71e97f5f022) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99392 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-22tdf#131175 oox chart import: fix char color of <dLbl>, inherited from <dLbls>Miklos Vajna3-0/+80
There were two problems here: 1) Our chart model expects the char formatting of a data label as direct formatting, so in case <c:dLbl> has no such formatting, but <c:dLbls> has, oox has to explicitly inherit. 2) The data label char formatting is represented using chart::FormattedString, but the char format of it is not (yet) exported to ODF. Given that the char format of the series and the individual data labels is the same, restore the same formatting on import to please rendering. With these, finally the chart labels in the bugdoc are white, not black (and have a dark background, so they are readable). (cherry picked from commit 8a43bfeffab9009c9f373e883fef87af1a7b3843) Change-Id: Iebac5ce0be31a59bafb0f9fe7636330585e33822 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99026 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-07-22Related: tdf#131175 OOXML chart: insert hatch definition into the right tableMiklos Vajna2-2/+19
Both the chart and the containing document has one, but the intention is to insert this into the chart one. This is needed, but not enough to render the right hatch for data labels. (cherry picked from commit e18bc316efbd815b047f4e19ebd033e7a842d10d) Change-Id: I485d84e2ae33728963b648c05e730d418567fc0e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99025 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-07-20Related: tdf#131175 OOXML chart: import data label fill patternGülşah Köse4-71/+321
(cherry picked from commit 6f752061d5153da50d6f536d506358c8f512a397) Change-Id: I2db64489c86e4381167eb13af4ab5118113960d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99024 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-14tdf#112312 DOCX legacy shape export: keep fixed sizeRegényi Balázs1-1/+6
Classical/legacy shapes lost their fixed size when exporting them with the option "Resize shape to fit text" because they do not have the ability to resize to content. Co-authored-by: Szabolcs Tóth Change-Id: Idd84dea040f9607d0d498e591601a8648a605a2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97127 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit cab956c480eb4f619580285c7b9a15b9e6d9b780) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97807 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-06-23tdf#134053 tweak dash and space length for ooxmlRegina Henschel2-16/+57
OOXML does not specify how line caps are applied to dashes. MS Office keeps dash and space length for preset dash styles and for round custom dash styles and add them for square line caps on custom dash styles. ODF specifies, that the linecaps are added to the dashes and the spaces are reduced, so that the dash-space pair keeps its length. This patch changes the dash and space length on import and export so, that they look nearly the same in LibreOffice as in MS Office. For custom dash styles with square line cap the first dash is longer as in MS Office. I have no solution for that. But I consider it as minor problem, because MS Office has not even an UI for that case. It should not hinder the improvement for the usual cases. Change-Id: I3e3e4b7c9d71e440ed301d2be423100440cb688b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96769 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> (cherry picked from commit 3f3b50015e4fd9efc3459612a70409fca49cf390) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96796 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-06-16tdf#133632 Chart DOCX Import: fix percentage number formatBalazs Varga1-1/+1
Set the LinkNumberFormatToSource to false only if we have an inner data table and the labels are shown as values. Regression from commit: e0da00d655ecca5986eea3812a8a670c6adbc40f (tdf#132174 Chart DOCX import: fix label number format) Change-Id: I879c5d81709995bfa49c18e0c84aaf6dc3dea41c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95493 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 53eeb419836f31bc4e16a2276a7ef875bea4ff97) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95984 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-06-16tdf#91250 Chart DOCX Import: Fix decimal place formatting issueBalazs Varga1-0/+3
Use UNLIMITED_PRECISION in case of GENERAL number format of CATEGORY axis labels in embedded charts, just like Calc does. Change-Id: I30cb50955c67824bd1aa88fb139618ce0f0974fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95802 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit f2a7f1bb080d882fd23b63a4f7a4833d6691b6e7) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95985 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-06-15PPTX export, custom shape, bitmap fill: fix source vs fill rect confusionMiklos Vajna1-0/+13
Commit 682ab832522b1349f1714bcb16f6e83468ea2920 (drawingML export\import: cropping of shape's fill texture, 2014-02-12) improved the DOCX filter, so the fill rectangle of a custom shape with bitmap fill is handled. The problem is drawingML has a source rectangle (similar to our crop rect) to limit the usage of the bitmap, and also it has a fill rectangle in case some margin is wanted around a stretched bitmap. We don't have a mapping for the later. Fix the problem by limiting the above work for DOCX, this way PPTX's source rectangle won't be turned into a stretch's fill rectangle. This way no unwanted margins will appear around the image -- those margins can be large enough that the image effectively disappears on export. Change-Id: Ic35063545a56eec9eaf885bbd397a854705d134f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96025 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit b00e43fa5848be0cc7ba81b185021511d94cdc00) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96097
2020-06-15PPTX import: handle adjust values from both the shape and its placeholderMiklos Vajna4-2/+39
The direct problem is a crash in CustomShapeProperties::pushToPropSet(), the code just hoped that the input file doesn't have more adjust values than the # of adjust values we allocate based on the preset type. Fix the crash, but there is a deeper problem here... The shape can inherit custom shape properties from a placeholder, then later it can have its own custom shape properties. When it comes to adjust values specifically, we used to just append own adjust values to the end of the list. This way we got the double of expected adjust values. And later rendering took the N expected adjust values from the start of the 2N element list, so we used the adjust values of the placeholder, not of the actual shape. Fix this by clearing the custom shape geometry once we know we have our own preset geometry. (cherry picked from commit 408ec7a4470741edbedbb034de07a2d776348593) Change-Id: I09f669bf59c33b552b906733d323eba7af5548e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96059 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-04Use "Radius" instead of "Rad" for new propertiesTomaž Vajngerl3-7/+7
Change-Id: Ifd232bccf1519e0ed68195cf4344893175a675e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95331 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 7313ed6a5b63e06ddd8ce90c3b5b2f168743a2c9) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95322 Tested-by: Jenkins
2020-05-28oox smartart import, composite alg: implement vertical centeringMiklos Vajna1-0/+23
The bugdoc's case was that the total height would be used by 2 shapes, but then a constraint decreases the height of one shape, so not all vertical space is used. We used to just count from the top, need to center vertically, as PowerPoint does it. Change-Id: I436019e9e837b73130e387c9bcd309e20045b0f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94948 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit acdde3c643fde015214c546b1567727272ea799e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94962
2020-05-27tdf#132594 Chart XLSX import: fix legend entries in pie chartsTünde Tóth1-1/+1
Legend entry text of pie chart wasn't imported correctly in XLSX documents created with Excel 2007. Regression from commit: e0b0502516a10181bbd1737b93b38b2bba4c98e8 (tdf#128016 Chart OOXML Import: fix duplicated category labels) Change-Id: I4567437a41fe66e124dccbd148c0c49196d5c007 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94864 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-05-26Fix loplugin:simplifypointertobool for libstdc++ std::shared_ptrStephan Bergmann25-107/+107
...where the get member function is defined on a std::__shared_ptr base class, so loplugin:simplifypointertobool used to miss those until now. (While e.g. using libc++ on macOS found those cases.) 366d08f2f6d4de922f6099c62bb81b49d89e0a68 "new loplugin:simplifypointertobool" was mistaken in breaking isSmartPointerType(const clang::Type* t) out of isSmartPointerType(const Expr* e); c874294ad9fb178df47c66875bfbdec466e39763 "Fix detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had introduced that indivisible two-step algorithm on purpose. The amount of additional hits (on Linux) apparently asked for turning loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed that the naive adivce to just "drop the get()" is not sufficient in places that are not contextually converted to bool, as those places need to be wrapped in a bool(...) functional cast now. If the expression was already wrapped in parentheses, those could be reused as part of the functional cast, but implementing that showed that such cases are not yet found at all by the existing loplugin:simplifypointertobool. Lets leave that TODO for another commit. Besides the changes to compilerplugins/ itself, this change has been generated fully automatically with the rewriting plugin on Linux. Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-05-26oox smartart import: fix aspect ratio of shape with composite algoMiklos Vajna1-20/+99
The layout node has alg=composite, then a parTx and a desTx child layout nodes. No matter what order is used (parent first, child first), the result will be wrong, as the constraints refer to each other. I did not spot any description in ISO 29500-1 that would describe what is the expected behavior. Researching this, found "One other consideration when specifying composite constraints is that the constraints must be specified in the same order as the nested layout nodes." at <http://web.archive.org/web/20111015151600/http://msdn.microsoft.com/en-us/magazine/cc163470.aspx>, which suggests to handle constraints for each shape in a parent -> child order, but keep a shared state when iterating over the children which gives us: - parent node, all direct constraints - for each child node: - child's constraints from parent - child's own constraints This way the desTx top value can depend on the parTx's height, and it's supported to define parTx's height only in the parTx layout node, not in the composite parent. And after all, it matches what PowerPoint does, so the column headings in the bugdoc have a 4:10 height:width aspect ratio. Change-Id: Ideb76c1ddd1ffff8d2a217cddf81106d1bb97eb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94872 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-26tdf#133030: DOCX export: fix formula alignment - part 3Attila Bakos1-1/+2
Follow-up of commit 1237acf9851f8b12d1ccd929e2aa8b184c06d552 (tdf#132811 DOCX: fix formula alignment – part 2) Co-authored-by: Tibor Nagy (NISZ) Change-Id: I5466649a2aa6b7ffdb0def723f79dfbecdf1495f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93665 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-05-26tdf#106181 XLSX export: output form controlsSerge Krot1-0/+1
Prepared general algorithm to ouput form controls into XLSX. For now only CHECKBOX is supported with a possibility to link withem to any worksheet/cell. Change-Id: Ide8739d81ffb755aeae074c4ebecf24251383e34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94161 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-05-25tdf#133190 tdf#133191 Chart OOXML export: fix text wrap and rotationBalazs Varga1-9/+19
of data point labels. Change-Id: Ic61d9ee149e838c000b5dc9ac0411bbe0f07219a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94598 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-05-25tdf#125812 Chart: fix OOXML export of gradient centerTünde Tóth1-21/+11
See also: commit 898e4ae1364e76af8be22183ac64d73b6a6d8d90 (tdf#128794 Chart: Fix OOXML import/export of Radial gradient) Change-Id: I9486c5b1dfcfd25bbf00d5f11b90c3c02459f634 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94486 Reviewed-by: Balazs Varga <balazs.varga991@gmail.com> Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2020-05-25[MS-OFFCRYPTO] convert oox implementation into UNO serviceVasily Melenchuk11-123/+450
To permit pluggable crypto services, abstract existing implementation behind an XPackageEncryption API. Previous code already had two halfway-polymorphic classes (agile and standard 2007 engine), so we're not adding much additional layers. As MS crypto always uses OLE storage to wrap content into one single file, current implementation passes all substorage names down into XPackageEncryption APi, so different downstream implementations (e.g. for MS RMS, or Azure AIP) are possible. Because OleStorage classes are internal to LibO core, access is provided via XInput/XOutput stream API function. Change-Id: Icc32a4e0ce215090c3b739f1dcaa0654b36b7f08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84436 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-05-24inline some use-once typedefsNoel Grandin2-5/+3
Change-Id: Idddba2f3fd05265b08dbc88edb6152d34a166052 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94730 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-24tdf#101181: drop useless "GlowEffect" boolean propertyMike Kaganski2-8/+9
Just use GlowEffectRad to indicate effect presense: radius of 0 means effect is disabled. Change-Id: Ic06bba34f5a851f120d3d00cb7e20c429ead9ee1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94732 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-05-22tdf#129686: Revert "tdf#118776: pptx import: draw char noFill as transparent"Xisco Fauli1-6/+1
Revert it for now towards LibreOffice 7.0 and add unittest This reverts commit e01df3488abe6d319c6874ca870afb82a3ad9b1e. Change-Id: Ic6aba5948f9c6e55199def0476918fbd496321bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94704 Tested-by: Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-05-22smartart import: handle multiple <a:schemeClr> in <dgm:fillClrLst>Miklos Vajna8-29/+86
The TODO in the ColorFragmentHandler ctor was right: we only handled the last <a:schemeClr> child, but there can be multiple one. Use them based on the index of a shape in a <dgm:forEach> loop. Move the TODO to the only place which still assumes a single color in the color list. Change-Id: I1c5c4f82e621f1110ef06b0490ff79f82f60f214 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94697 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-21use for-range on Sequence in i18npool..sdNoel Grandin3-25/+24
Change-Id: I19eba57bc6058c317473d0746f06699a09ba2830 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94608 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-20tdf#126363 DOCX shape round-trip: keep original line widthRegényi Balázs2-1/+8
to avoid of rounding error of EMU -> 1/100 mm -> EMU conversions, which messed up recognition of preset line widths in MSO. Co-authored-by: Szabolcs Tóth Change-Id: Ide0e393e667848683f00f9ba7a73ff8a45a908b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94043 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-05-19oox, svx, sw, xmlsecurity: clang-format these filesMiklos Vajna5-137/+187
I added these files more or less recently and they have long lines. Use clang-format to break at a sane column limit. Change-Id: Id4ef832e4843fc81f4a497385e49ccb835a7197f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94503 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-18tdf#92526 DrawingML shape export: fix 0 line widthSzabolcs Toth1-1/+1
0 line width is the thinnest possible line width, but without its explicit export (a:ln w="0"), shape outline was imported with 0.75 pt line width by MSO. Co-authored-by: Balázs Regényi Change-Id: I40f7aefe6358bebe9a3853fe3e7d6faa170bc34c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93968 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2020-05-18tdf#123622 DOCX VML import: fix relative horizontal alignmentTibor Nagy1-4/+10
Margin (left, right, inner, outer) alignments of VML shapes weren't handled. Co-authored-by: Attila Bakos (NISZ) Change-Id: I5f8ece64707a2d699b71d6151887db05ac39c4f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93723 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-05-15replace hard-coded "1.2" ODF version stringsMichael Stahl1-2/+2
Most of these are calls to DocumentDigitalSignatures::createWithVersion(), where it doesn't make a difference if "1.2" or "1.3" is passed in but maybe it will be different with "1.4". There is another ctor createDefault() which looks appropriate for non-ODF contexts and can also be used when no actual signing or verifying is done. In cases where there's an actual document its Storage has the version. Change-Id: Id636bbf965d9f96c7ed5f50774c509032525b2b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93091 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-05-12tdf#128794 Chart: Fix OOXML import/export of Radial gradientBalazs Varga1-12/+24
Style should be radial at least when the horizontal/vertical center is not in the corner of a shape. Otherwise import as a linear gradient, because it is the most similar to the MSO radial style. Change-Id: I9bab7b787897bde51a06a950487de9843eb717a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93497 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: Tünde Tóth <tundeth@gmail.com> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-05-11tdf#49247: no need in extra boolean property, radius is enoughMike Kaganski2-8/+9
When soft edge has radius 0, the effect is disabled. Change-Id: I7d66ea7b87e0ed59129a83885d52906b8edf75f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93971 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-05-11tdf#49247: implement soft edges document model and import/exportMike Kaganski5-8/+55
... for ODF and OOXML. Two object properties added: SoftEdge (boolean, effect enabled/disabled) SoftEdgeRad (sal_Int32, effect radius in 100ths of mm) Two corresponding ODF attributes added: loext:softedge ("visible"/"hidden") loext:softedge-radius (metric) Change-Id: I0dc4d7fc3e5b0c2c36092d430568ebcfd3a68c9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93833 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-05-10new loplugin:simplifypointertoboolNoel Grandin1-1/+1
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-09compact namespace in i18npool..ooxNoel Grandin77-171/+168
Change-Id: I1de87468b56b86a1eeee09a612551ab119a1be8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93857 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-08read properly OOXML 'strips' slide transition as our SLIDEWIPELuboš Luňák2-0/+11
Change-Id: I584c66008e40d692021be5298cb9cdcc492eea05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93716 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2020-05-08implement PowerPoint 'flash' slide transition (API CHANGE)Luboš Luňák2-1/+10
It's like 'fade', but using white instead of black. It's a separate type in the pptx file (although I actually cannot find it in the spec OOXML, but PowerPoint 2013 generates it). The API change in XTransitionFactory should be fine, I doubt there's anything external using it. Change-Id: I3479840f265ed8227b3b8301ecff56a63d57f493 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93668 Tested-by: Luboš Luňák <l.lunak@collabora.com> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-05-08tdf#132201: use proper sequence order of effects per specMike Kaganski1-2/+16
See CT_EffectList in ECMA-376 Change-Id: Ib0605f1e4a0795d2bfdbb6b7451a902c67ea504d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93717 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-05-07tdf#101181: store glow radius in 100ths of mm instead of EMUsMike Kaganski2-3/+5
... as we do for all metric values. This fixes storing values like "190.5cm" in ODF for 15 pt (should be "0.529cm"). Change-Id: I382756af56464424dcb24ed8801d0a4203658c11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93640 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-05-06tdf#101181: support for transparency attribute of glow effectMike Kaganski2-1/+4
Read/write support for ODF and OOXML (in ODF, loext:glow-transparency attribute of style:graphic-properties has been added). Added UI on glow sidebar panel. Not used in actual painting yet. Change-Id: I21b25d9c52c8611cd796f056374377ebf13cc2f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93565 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-05-06tdf#79082 Export paragraph tab stops to ooxmlSamuel Mehrbrodt2-0/+42
Change-Id: I7d25dc1ab3c960aafc07a3be69b54f5aceef23fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93462 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-05-05tdf#132486 Chart: fix OOXML export of ShiftedCategoryPositionBalazs Varga1-24/+13
Regression from commit 75156c6fd73dc202df541306e1636727d51d6fc3 (tdf#132076 Chart OOXML: fix lost date format of X axis) Change-Id: I4bb62959775b0b6ed11e1f7e5473c3b9805f4e29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92420 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-05-04tdf#131175 Import data label solid fill and color.Gülşah Köse2-1/+24
Change-Id: I8a3ef6e60d4f2a13310bb9a8fc4eb873df3f9b4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93407 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-04-29tdf#132491 DOCX DrawingML shape import: fix missing underline colorRegényi Balázs1-0/+7
The import of underline color was unhandled. Co-Author: Szabolcs Toth Change-Id: I47dce90966c7130ca67941ee47b0e4b2ba7eb972 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93108 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-04-29Related tdf#111461: add "variant", "lpstr" and "i4" in docprophandler (oox)Julien Nabet1-1/+11
Following these logs: warn:oox:24274:24274:oox/source/docprop/docprophandler.cxx:320: OOXMLDocPropHandler::startFastElement: unknown element 5621 warn:oox:24274:24274:oox/source/docprop/docprophandler.cxx:320: OOXMLDocPropHandler::startFastElement: unknown element 3198 warn:oox:24274:24274:oox/source/docprop/docprophandler.cxx:320: OOXMLDocPropHandler::startFastElement: unknown element 5621 warn:oox:24274:24274:oox/source/docprop/docprophandler.cxx:320: OOXMLDocPropHandler::startFastElement: unknown element 2749 warn:oox:24274:24274:oox/source/docprop/docprophandler.cxx:320: OOXMLDocPropHandler::startFastElement: unknown element 5621 warn:oox:24274:24274:oox/source/docprop/docprophandler.cxx:320: OOXMLDocPropHandler::startFastElement: unknown element 3198 warn:oox:24274:24274:oox/source/docprop/docprophandler.cxx:320: OOXMLDocPropHandler::startFastElement: unknown element 5621 warn:oox:24274:24274:oox/source/docprop/docprophandler.cxx:320: OOXMLDocPropHandler::startFastElement: unknown element 2749 warn:oox:24274:24274:oox/source/docprop/docprophandler.cxx:320: OOXMLDocPropHandler::startFastElement: unknown element 3198 warn:oox:24274:24274:oox/source/docprop/docprophandler.cxx:320: OOXMLDocPropHandler::startFastElement: unknown element 3198 warn:oox:24274:24274:oox/source/docprop/docprophandler.cxx:320: OOXMLDocPropHandler::startFastElement: unknown element 3198 I found that each element corresponded to the line of oox/source/token/tokens.txt - 1 File https://bugs.documentfoundation.org/attachment.cgi?id=135265 contains this in docProps/app.xml <?xml version="1.0" encoding="utf-8" standalone="yes"?> <Properties xmlns="http://schemas.openxmlformats.org/officeDocument/2006/extended-properties" xmlns:vt="http://schemas.openxmlformats.org/officeDocument/2006/docPropsVTypes"> <TotalTime>0</TotalTime> <Application>Microsoft Excel</Application> <DocSecurity>0</DocSecurity> <ScaleCrop>false</ScaleCrop> <HeadingPairs> <vt:vector size="4" baseType="variant"> <vt:variant> <vt:lpstr>Feuilles de calcul</vt:lpstr> </vt:variant> <vt:variant> <vt:i4>1</vt:i4> </vt:variant> <vt:variant> <vt:lpstr>Plages nommées</vt:lpstr> </vt:variant> <vt:variant> <vt:i4>2</vt:i4> </vt:variant> </vt:vector> </HeadingPairs> <TitlesOfParts> <vt:vector size="3" baseType="lpstr"> <vt:lpstr>GENERALISTE</vt:lpstr> <vt:lpstr>GENERALISTE!Impression_des_titres</vt:lpstr> <vt:lpstr>GENERALISTE!Zone_d_impression</vt:lpstr> </vt:vector> </TitlesOfParts> <LinksUpToDate>false</LinksUpToDate> <SharedDoc>false</SharedDoc> <HyperlinksChanged>false</HyperlinksChanged> <AppVersion>12.0000</AppVersion> </Properties> Change-Id: I736df31676377d1c342b6c4b35d435edc3719891 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92592 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-29tdf#119087 Don't treat OOXML strict namespace as custom XMLSamuel Mehrbrodt1-1/+2
Change-Id: I5037ac09f57c92e02e330cbc906da3afbe4c747c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93056 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-04-28tdf#132282: Revert fix for tdf#131554Xisco Fauli1-3/+1
912217285b3058efa54c2336f91fda4efdad6ff0 fixed the root cause of tdf#131554 and 69b83dc2d3014dd9b18402534e15c937dc082464 is no longer needed The unittest still passes Change-Id: I7c723b0c3cc2b56022978bbeb8bf6b3f6f93f1c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93063 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-04-28move the castToFastAttributeList functionNoel Grandin1-1/+1
to the slightly higher namespace, to make it easy and more readable to use directly in a for-loop-range expression. And make it return a reference rather than a pointer, since it is never allowed to be nullptr. Change-Id: I15d0b32493ef65cfc601b247c272b318f1eadfd8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93049 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-28tdf#131841 DOCX DrawingML shape import: Fixed missing HighlightColorSzabolcs3-4/+72
Implemented highlight color in grouped shapes. It was missing completely. Co-Author: Balázs Regényi Change-Id: I51207d01a205fbb24abc51c0d69042d6747570a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91619 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-04-28tdf#127811 tdf#127813 Introduce compatibility key for the data seriesTünde Tóth2-20/+15
order of filled net and normal area charts. The data series of filled net and normal area charts are drawn in reversed order in LibreOffice but not in Microsoft Office. Default value is true to keep current behavior. Change-Id: I07adac814597b756878d74610d028f07327f7214 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/83897 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga991@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-20 01:51:28 +0000