Created attachment 13073 [details]
Document containing mentioned problem

Target OO 2.0.

cmc->mru: Yes. That frame is an autowidth drawing object. To not import it as a
drawing object would be ok in this one example, but not in the general case :-(

Either we have drawing objects which can use a writer frame as their "text
engine" to allow them to contain graphics. Or our frames are enhanced to support
autowidth so that we can import these drawing object as autowidth frames.

For the 'Q' there is issue 20202 to provide such autowidth support for our
native frames, when that is implemented, such document as this will work correctly.

cmc->mmaher: The code to enable/disable importing such objects as frames or
drawing objects is in svx/source/msfilter/msdffimp.cxx in ProcessObj
This case is explictly not allowed for conversion to textframe, i.e. the 
wrapmode must be " == mso_wrapSquare" currently, while this rectange is mso_wrapNone

  if (!bTextFrame)
            {
                //Either
                //a) its a simple text object or
                //b) its a rectangle with text and square wrapping.
                bTextFrame =
                (
                    (pImpRec->eShapeType == mso_sptTextSimple) ||
                    (
                        (pImpRec->eShapeType == mso_sptRectangle)
                        && (eWrapMode == mso_wrapSquare)
                        && ShapeHasText(pImpRec->nShapeId, rObjData.nOldFilePos)
                    )
                );
            }

MRU->MM: autowidth frames have now been implemented into Writer. Please adapt
import of such objects as CMC proposed.

mmaher: fixed in adare

reopening to reassign

reassigning to mru

Fixed in adare

Verified fix in CWS adarefilterteam29.

Checked integration in 680m60.