summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)Author
2020-06-10PPTX export, custom shape, bitmap fill: fix source vs fill rect confusionMiklos Vajna
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
2020-06-10PPTX import: handle adjust values from both the shape and its placeholderMiklos Vajna
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. Change-Id: I09f669bf59c33b552b906733d323eba7af5548e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95993 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-06-10tdf#91250 Chart DOCX Import: Fix decimal place formatting issueBalazs Varga
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>
2020-06-10tdf#133632 Chart DOCX Import: fix percentage number formatBalazs Varga
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>
2020-06-04Update ShadowPrimitive2D to support shadow blurA_GAN
Add attribute for the blur radius and get function. give more range for the shadow depends on the size of the blur radius. update the blur radius to be imported in Hmm and the test function. Change-Id: I32faaf02884d9a6b2f11a9033178b3b6bb419580 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95388 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-06-04Upcoming loplugin:elidestringvar: ooxStephan Bergmann
Change-Id: I74da8354fe58c2800a7aaa4145356f61b388dc58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95507 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-04loplugin:simplifypointertobool improve (2)Noel Grandin
to look for the x.get() == null pattern, which can be simplified to !x Change-Id: I0eddf93257ab53ab31949961d7c33ac2dd7288ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95400 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-03loplugin:simplifypointertobool improveNoel Grandin
to look for the x.get() != null pattern, which can be simplified to x I'll do the x.get() == nullptr pattern in a separate patch, to reduce the chances of a mistake Change-Id: I45e0d178e75359857cdf50d712039cb526016555 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95354 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-02OOXML support for shadow blurA_GAN
Add a new property for the blur radius and define an ID for it to support the import of OOX files. Add a test for importing the blur radius from PPTX file Change-Id: Iffaa33ff7159019ce9478cee558622bd61bcf60e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95090 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-06-02Use "Radius" instead of "Rad" for new propertiesTomaž Vajngerl
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>
2020-05-29loplugin:simplifybool in oox..sdNoel Grandin
Change-Id: I76cbd5d3e65f0b392d713a51607f5c88dae79593 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95101 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-28Make loplugin:simplifypointertobool handle parenthesized expressionsStephan Bergmann
...as discussed as an open TODO in the commit message of fe6cce01c88d045a1fcf09acf049c34c22299b02 "Fix loplugin:simplifypointertobool for libstdc++ std::shared_ptr". The necessary changes across the code base have been done fully automatically with the rewriting plugin on Linux. (All those changes apparently involve uses of macro arguments wrapped in parentheses in the macro body, but always in conditionally-converted-to-bool contexts. In other contexts, such automatic rewriting would add the "bool" to the macro body, which would be wrong in general, but we apparently get away with that sloppy coding for now.) The parenExprs_ stack that fe6cce01c88d045a1fcf09acf049c34c22299b02 had introduced to treat such (then-undetected, it had turned out) parenthesized cases now turns out to not be needed after all. Change-Id: I2021f61c2e2805be7e18b38edf8744d186cac3cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95010 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-27Further fixing of loplugin:simplifypointertobool for libstdc++ std::shared_ptrStephan Bergmann
...after fe6cce01c88d045a1fcf09acf049c34c22299b02 "Fix loplugin:simplifypointertobool for libstdc++ std::shared_ptr", this time for uses of oox::drawingml::chart::ModelRef, which derives from std::shared_ptr. Change-Id: I7e9620da52b3f6d26c6fe6d7909888c3a221c164 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94975 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-27oox smartart import, composite alg: implement vertical centeringMiklos Vajna
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
2020-05-27tdf#132594 Chart XLSX import: fix legend entries in pie chartsTünde Tóth
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 Bergmann
...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 Vajna
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 Bakos
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 Krot
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 Varga
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óth
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 Melenchuk
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 Grandin
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 Kaganski
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 Fauli
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 Vajna
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 Grandin
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ázs
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 Vajna
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 Toth
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 Nagy
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 Stahl
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 Varga
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 Kaganski
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 Kaganski
... 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 Grandin
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 Grandin
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ňák
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ňák
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 Kaganski
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 Kaganski
... 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 Kaganski
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 Mehrbrodt
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 Varga
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öse
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ázs
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 Nabet
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 Mehrbrodt
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 Fauli
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 Grandin
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>
generated by cgit (git 2.34.1) at 2025-01-18 03:51:08 +0000