Currently the shape "forbidden" is on the so called 'Whitelist'. That means, that the shape is exported into a custGeom element. But export to custGeom can only write numbers, no formulas. Therefore the handle of the shape is lost. But OOXML has a corresponding shape, so there is no need to put it on the 'whitelist'. Export and Import works well, when it is on the 'Blacklist'. The changes have to be done in core/oox/source/export/shapes.cxx
I consider it an 'easyHack'. [The two other shapes on the Whitelist are correct. The LO shape 'Heart' looks different than the 'Heart' from OOXML preset. The shape 'Puzzle' does not exist in OOXML.]
Hi Regina, Do you have any document sample with this shape ?
Created attachment 154869 [details] ShapeNoSmoking.odp with own and pptx version of the shape The attached file has on the left side the shape as it is provided in our own preset. On the right side is the corresponding shape from OOXML preset. It was inserted by copy&paste from a pptx-file. Make sure, both shapes have a handle to set the thickness of the ring. Save the file into pptx-format and reopen. Notice the left shape has no handle.
Reproduced in Version: 6.4.0.0.alpha0+ Build ID: ae7b26246ec03dbff3d43a0dc04fd9ffd2cd0809 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Ayhan Yalçınsoy: Do you still work on this bug? Do you have found the place where the adjustment values are set? Or do you need a tip?
Hi Regina, in fact I need some tips.
Writing visual shape properties starts at line #863. What is actually written depends on some switches e.g. bCustGeom, bOnBlacklist, bHasHandles. What values has your shape (of cause after the changes you have already made)? So what branch is relevant? If not sure, set a breakpoint and move forward. When you then have roughly the area where AdjustmentValues are treated, you need to decide, to which branch your shape belongs. You can in theory look, how your shape is defined in detail [1] and decide what to do. I would not try that. Instead remember what kind of handle your shape has: It has exactly one handle. So one value has to be written. And the handle of your shape moves in horizontal direction, so its x-position is relevant. There are not many branches where both conditions are fulfilled ;) So you can simple try, which is the correct one. [1] In case you are interested in geometry definition details: The name mapping is in file https://opengrok.libreoffice.org/xref/core/svx/source/customshapes/EnhancedCustomShapeTypeNames.cxx and the geometry definitions are in file https://opengrok.libreoffice.org/xref/core/svx/source/customshapes/EnhancedCustomShapeGeometry.cxx
ayhanyalcinsoy committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/451eab287acd88abc19c97bd99e50cbfa4480bb4 tdf#128049:FILESAVE PPTX Improve export of shape 'forbidden' It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
It is OK now and I have pushed it to master. Congratulation. Writing a unit test is the next step now. A unit test should be always included in a bug fix. You should first consider what is to be tested at all. There are several possibilities. If you don't know how an idea can be implemented technically, then ask on the mailing list.
Guess it's solved
(In reply to Regina Henschel from comment #9) > It is OK now and I have pushed it to master. Congratulation. > > Writing a unit test is the next step now. A unit test should be always > included in a bug fix. > You should first consider what is to be tested at all. There are several > possibilities. If you don't know how an idea can be implemented technically, > then ask on the mailing list. Ayhan was not in CC, so pointing this out.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/006fea5a3ec04394081cc28035be9e4c1e0ffc83 tdf#128049: sd: Add unittest It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.