lo/core - LibreOffice 核心代码仓库

index : lo/core

LibreOffice 核心代码仓库

文档基金会

summary refs log tree commit diff

path: root/config_host

diff options

Diffstat (limited to 'config_host')

0 files changed, 0 insertions, 0 deletions

gt; Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2020-11-05tdf#133037 OOXML shape import: camera rotation along ZDaniel Arato (NISZ) 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> (cherry picked from commit a9c5c0d814a266096483572b84c72875ef8efd77) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105352 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com> 2020-10-07tdf#137023 PPTX import: fix unexpected center alignment of shape text, 2nd tryMiklos Vajna 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. (cherry picked from commit dfa1856cdb4c69985ef1e809d33055427b6fbd76) Change-Id: Id785252c26fc407cd74c9cfb55624091798d7773 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104050 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2020-09-22tdf#129685 PPTX import: fix unexpected centering of shape textMiklos Vajna 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. (cherry picked from commit 10bb02efd8afd42e633e370480104e2575546d8e) Change-Id: I81a7b3e8c76bfbce5c5569d16d5238958ac20f75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103136 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2020-08-07tdf#134183 PPTX: improve import of transparency in multi-step gradientsMiklos Vajna Impress core only support a single step, improve the conversion from multi-step to single step to take transparency into account explicitly. Once we select the widest segment, look backwards and forward if there are other next segments which have the same RGB color, just different transparency and include them. This helps in general, because in case a 0% or 100% transparency is mishandled, that's very visible. (cherry picked from commit 73993fdb5d4b507694cd0edf80887d19f7e2bf9a) Conflicts: oox/source/drawingml/fillproperties.cxx Change-Id: I11d593c01a6a4b16149ce74c1408c2a39895e941 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100287 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2020-07-15tdf#131175 oox chart import: fix char color of <dLbl>, inherited from <dLbls>Miklos Vajna 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/+/98810 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 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. (cherry picked from commit 408ec7a4470741edbedbb034de07a2d776348593) Change-Id: I09f669bf59c33b552b906733d323eba7af5548e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96066 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> 2020-06-10tdf#131082 fix missing fill property of grouped shapesnd101 When shapes are grouped together, and fill property is specified at the group level in MSO, it fails to work in IMPRESS. This fix is to set the fill property when it is being imported. Change-Id: I89920e71fc558f54d49ef7b065c549a732bc2b10 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89862 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96065 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> 2020-05-11oox: add PPTX import/export for semi-transparent shape textMiklos Vajna And start a drawingml test suite in oox, so the test and the tested code is close to each other (just like how it's done in chart2/ already). (cherry picked from commit 1e64d9ebaa231caef5fb062009b8f76465e415f4) Conflicts: oox/Module_oox.mk Change-Id: I9a2810691f12604d240e4394e6a5ff4e7f52f1c1


context:
space:
mode: