Created attachment 170589 [details] Converted from ppt to odp by PowerPoint Open attached file. It has an extruded shape top/right and another bottom/left. The top/right one should have direction "North East", but it has direction "South West". The file was converted by PowerPoint from a ppt file to odp. The direction of a parallel projection is specified by the attribute draw:extrusion-skew (ยง19.177, ODF 1.3). The second value in it is the angle. https://docs.oasis-open.org/office/OpenDocument/v1.3/cs02/part3-schema/OpenDocument-v1.3-cs02-part3-schema.html#__RefHeading__1417044_253892949 If the attribute is missing, an angle of 45deg has to be used as default, but LibreOffice uses -135. The default value is set in GetSkew() in https://opengrok.libreoffice.org/xref/core/svx/source/customshapes/EnhancedCustomShape3d.cxx?r=cfff893b#85 Unfortunately the same part is used when getting a ppt-file. And there, the default value is -135deg. So simple changing it there to 45deg, will break ppt import. PowerPoint drops the draw:extrusion-skew attribute on saving, if it has default values. (What corresponds to the idea of "default" values.) My idea is, not to change the value in GetSkew() and then try to tweak MS binary import and export, but to add the values on import of odp in XMLEnhancedCustomShapeContext::endFastElement() in case the attribute is missing. Do yo agree?
Created attachment 170590 [details] Original ppt file created by PowerPoint 97
Just for curiosity because I got no expertise here, since 45 should be the default value, what about changing GetSkew() to put 45 instead and tweak MS binary import and export? I mean, the first priority is to manage well odf formats, managing MS formats is 2nd priority I suppose.
(In reply to Julien Nabet from comment #2) > Just for curiosity because I got no expertise here, since 45 should be the > default value, what about changing GetSkew() to put 45 instead and tweak MS > binary import and export? I mean, the first priority is to manage well odf > formats, managing MS formats is 2nd priority I suppose. The problem is, that I do not know where to change the binary import. On the other hand adding the default values in case of missing draw:extrusion-skew attribute is easy in principle. https://gerrit.libreoffice.org/c/core/+/112819 (Hope Jenkins likes it.)
Searching ppt import in cgit, I got: https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=ppt+import I gave a look at https://cgit.freedesktop.org/libreoffice/core/commit/?id=11d542352e1088a2c870b0e73e14e10266276483 tdf#118037 PPT import: fix lost crop of graphic Regression from commit b11188835d3b87cd9d2a8cdb3da204cfda5d3e6e (DOC import: lazy-read images, 2018-04-20). and noticed this file: filter/source/msfilter/msdffimp.cxx Then searching Skew in it, I got: https://opengrok.libreoffice.org/xref/core/filter/source/msfilter/msdffimp.cxx?r=4e639c37#1828 Here's part of bt: #0 DffPropertyReader::ApplyCustomShapeGeometryAttributes(SvStream&, SfxItemSet&, DffObjData const&) const (this=0x88e3f18, rIn=..., rSet=SfxItemSet of pool 0x937c110 with parent 0x0 and Which ranges: [(1000, 1241), (4006, 4061)] = {...}, rObjData=...) at filter/source/msfilter/msdffimp.cxx:1828 #1 0x00007ff304630f24 in DffPropertyReader::ApplyAttributes(SvStream&, SfxItemSet&, DffObjData const&) const (this=0x88e3f18, rIn=..., rSet=SfxItemSet of pool 0x937c110 with parent 0x0 and Which ranges: [(1000, 1241), (4006, 4061)] = {...}, rObjData=...) at filter/source/msfilter/msdffimp.cxx:2684 #2 0x00007ff304637b80 in SvxMSDffManager::ImportShape(DffRecordHeader const&, SvStream&, SvxMSDffClientData&, tools::Rectangle&, tools::Rectangle const&, int, int*) (this=0x88e3f10, rHd=..., rSt=..., rClientData=..., rClientRect=..., rGlobalChildRect=..., nCalledByGroup=0, pShapeId=0x7ffc04d48d4c) at filter/source/msfilter/msdffimp.cxx:4348 #3 0x00007ff304635c3c in SvxMSDffManager::ImportObj(SvStream&, SvxMSDffClientData&, tools::Rectangle&, tools::Rectangle const&, int, int*) (this=0x88e3f10, rSt=..., rClientData=..., rClientRect=..., rGlobalChildRect=..., nCalledByGroup=0, pShapeId=0x7ffc04d48d4c) at filter/source/msfilter/msdffimp.cxx:4034 #4 0x00007ff3046bf083 in SdrPowerPointImport::ImportPage(SdrPage*, PptSlidePersistEntry const*) (this=0x88e3f10, pRet=0x877d450, pMasterPersist=0x93a1b60) at filter/source/msfilter/svdfppt.cxx:2910 #5 0x00007ff2fd82621b in ImplSdPPTImport::Import() (this=0x88e3f10) at sd/source/filter/ppt/pptin.cxx:951 #6 0x00007ff2fd820cb6 in SdPPTImport::Import() (this=0x8275c90) at sd/source/filter/ppt/pptin.cxx:155 #7 0x00007ff2fd830cf0 in ImportPPT(SdDrawDocument*, SvStream&, SotStorage&, SfxMedium&) (pDocument=0x93fb5c0, rDocStream=..., rStorage=..., rMedium=...) at sd/source/filter/ppt/pptin.cxx:2778 #8 0x00007ff304c9051e in SdPPTFilter::Import() (this=0x7ffc04d4b3a8) at sd/source/filter/sdpptwrp.cxx:207 #9 0x00007ff304e083df in sd::DrawDocShell::ConvertFrom(SfxMedium&) (this=0x87bd5b0, rMedium=...) at sd/source/ui/docshell/docshel4.cxx:457 #10 0x00007ff31d71ae75 in SfxObjectShell::DoLoad(SfxMedium*) (this=0x87bd5b0, pMed=0x93eb390) at sfx2/source/doc/objstor.cxx:751 #11 0x00007ff31d7837ee in SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x83e71b0, seqArguments=uno::Sequence of length 16 = {...}) at sfx2/source/doc/sfxbasemodel.cxx:1883 #12 0x00007ff31d8f7f11 in (anonymous namespace)::SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) (this=0x83f28e0, rArgs=uno::Sequence of length 12 = {...}, _rTargetFrame=uno::Reference to ((anonymous namespace)::XFrameImpl *) 0x3f67030) at sfx2/source/view/frmload.cxx:681 Perhaps it may help.
But changing (-135 * 65536) to (45 * 65536) there does not solve the problem with ppt import. I get a wrong direction for the left/bottom shape in ppt file in case I had changed GetSkew() to use 45. I have attached the ppt file, so that it is possible to test, that any change still opens that file correctly.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2bf8c1e0e211601a70b6b28fdb92f636c7969513 tdf#141127 Use ODF default values for draw:extrusion-skew It will be available in 7.2.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.
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/7c4a797148a68b342b17f2d34854d6bacf51cb85 tdf#141127 Use ODF default values for draw:extrusion-skew It will be available in 7.1.3. 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 conflicts with documents created by OpenOffice/LibreOffice, because they sometimes do not write attribute draw:extrusion-skew="50 -135" although it is not the default value. Is there a way to reliable detect, that a document was written by OpenOffice or LibreOffice, so that the missing skew angle could be set to -135 on opening in those cases?
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f1b55d3f8e963069fc798bcf559ae9af2bf18b64 Revert "tdf#141127 Use ODF default values for draw:extrusion-skew" It will be available in 7.2.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.
The patch is in principle correct, but it can only be used, when LibreOffice is fixed so that in case of skew angle -135 the value is written to file, and if that fix is so long ago, that faulty documents are unlikely.
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/7947f3ed80ce2056de4777a21fc6767466645327 Revert "tdf#141127 Use ODF default values for draw:extrusion-skew" It will be available in 7.1.3. 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.