Issue 32217 - Text object: problem with default attributes
Summary: Text object: problem with default attributes
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: 680m47
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.0.2
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords:
: 61840 (view as issue list)
Depends on:
Blocks:
 
Reported: 2004-07-28 12:54 UTC by sven.jacobi
Modified: 2006-02-15 15:30 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description sven.jacobi 2004-07-28 12:54:16 UTC 
Our text object is having some problems with default style and or hard attributes.
The following code in svx/source/sdr/properties/textproperties.cxx is hard
attributing the text object. This leads to problems if the default style is
assigned to a text object.

- create a text object with some text
- select the textobject (not being in the edit modus)
- assign the default style via "format/default" -> now the text object is filled
with blue 7
- after save / reload (xml) the fill color of the text object white
 
void TextProperties::ForceDefaultAttributes()
{ 
    SdrTextObj& rObj = (SdrTextObj&)GetSdrObject();
    sal_Bool bTextFrame(rObj.IsTextFrame());
    // force ItemSet
    GetObjectItemSet();

    if(bTextFrame)
    {
        mpItemSet->Put(XLineStyleItem(XLINE_NONE));
        mpItemSet->Put(XFillColorItem(String(), Color(COL_WHITE)));
        mpItemSet->Put(XFillStyleItem(XFILL_NONE));
    }
    else
    {
        mpItemSet->Put(SvxAdjustItem(SVX_ADJUST_CENTER));
        mpItemSet->Put(SdrTextHorzAdjustItem(SDRTEXTHORZADJUST_CENTER));	
mpItemSet->Put(SdrTextVertAdjustItem(SDRTEXTVERTADJUST_CENTER));
    }
}

(Maybe ForceDefaultAttributes should be called each time a stylesheet is set the
textobject)
Comment 1 Armin Le Grand 2004-09-10 16:05:25 UTC 
AW: This is a hard and weird problem. The shape is once created, and the
creation over the factory sets those hard attributes. Then, assigning the
default removes all hard attributes, that's correct. All is saved correct, too.
At load time, the API xShape creates an empty SdrObject using the factory again
what sets those hard attributes again, too. Those are NOT removed then when
setting the PropertySet at the xShape.
AW: The problem is more that at load time the setting of attributes only
additionally sets attributes, but does not remove not-set ones. Investigating
deeper...
AW: Getting xmloff...
Comment 2 Armin Le Grand 2004-09-13 13:25:21 UTC 
AW->CL: XMultiPropertyState needs to be implemented, so that at load time the
hard attributes at a xShape can be reset before the loaded hard attribues get set.
Comment 3 clippka 2004-10-12 18:49:04 UTC 
accepted
Comment 4 clippka 2004-10-14 14:12:21 UTC 
Daniel, please take over.

You have to add XMultiPropertyState to the SvxShape implementation in
svx/source/unodraw/unoshap?.cxx and then call the set?Default in xmloff after
adding a shape to its page in SdXMLShapeContext::AddShape()
(xmloff/source/draw/ximpshap.cxx)
Comment 5 Daniel Boelzle [:dbo] 2004-10-22 11:11:07 UTC 
.
Comment 6 Daniel Boelzle [:dbo] 2004-11-08 10:06:15 UTC 
.
Comment 7 Daniel Boelzle [:dbo] 2004-11-08 10:07:09 UTC 
Christian, please verify.
Comment 8 Daniel Boelzle [:dbo] 2004-11-08 10:07:23 UTC 
.
Comment 9 clippka 2004-11-10 14:44:29 UTC 
We have a problem with images loaded from OOo 1.0 xml files.
In OOo 2.0 we introduced the feature that images can have a background filling.
So since OOo 2.0 we also export and import the fill attributes. In OOo 1.0 xml
files, there have been no fill attributes sets so when we do an import in OOo
2.0 the default is used and that is fill style solid and color blue7.

To fix this issue, we must change the import of image shapes in xmloff. We must
detect if we import with the transformator from OOo 1.0 format. In that case, we
need to hard set the FillStyle property to solid *after* setting the style.
Please ask Oliver Düsterhöft how to detect that we import over the transformator.
Comment 10 Daniel Boelzle [:dbo] 2004-11-11 11:03:53 UTC 
back to me.
Comment 11 Daniel Boelzle [:dbo] 2004-12-07 15:36:16 UTC 
@cgu: please test some samples, e.g. companyTakeOver which has been broken...
Comment 12 Daniel Boelzle [:dbo] 2005-01-10 10:04:45 UTC 
has been verified by SJ.
Comment 13 Daniel Boelzle [:dbo] 2005-01-30 16:38:54 UTC 
closed.
Comment 14 clippka 2005-02-04 13:29:57 UTC 
fix but failed, this issue caused regression issue 42043.
Comment 15 clippka 2005-02-04 13:31:36 UTC 
To correctly fix this issue, I will have to overload ::setAllPropertiesToDefault
in the impress application and handle special defaults like empty presentation
objects on the masterpage correctly.
Comment 16 clippka 2005-05-23 16:41:45 UTC 
retargeted
Comment 17 clippka 2006-01-30 16:00:40 UTC 
Changing target as this issue is problematic for the new formatbrush feature
Comment 18 clippka 2006-01-31 11:14:55 UTC 
Problem also reproducable with new format paintbrush feature.

Create two text shapes with some text
Format the first text shape with the tool bar to have a solid blue filling
Format the second text shape with the format paintbrush feature so it has the
same format as the first shape.
After save&reload the second shape has no filling
Comment 19 clippka 2006-01-31 11:16:49 UTC 
fixed in cws impress84,

in SdXMLShapeContext::AddShape() I again call setAllPropertiesToDefault() on the
newly created shape before its hard attributes are imported. But now I only do
this for non placeholder shapes. This is because we do not export/import hard
attributes for placeholder, therefore we must not clear them on load.
Comment 20 clippka 2006-02-03 08:41:04 UTC 
verfified in cws, back to qa

re-open issue and reassign to wg@openoffice.org
Comment 21 clippka 2006-02-03 08:41:46 UTC 
reassign to wg@openoffice.org
Comment 22 clippka 2006-02-03 08:42:16 UTC 
reset resolution to FIXED
Comment 23 wolframgarten 2006-02-07 10:40:59 UTC 
Verified in CWS.
Comment 24 wolframgarten 2006-02-09 12:28:33 UTC 
*** Issue 61840 has been marked as a duplicate of this issue. ***
Comment 25 wolframgarten 2006-02-15 15:30:02 UTC 
Tested in master OOB680m1. Closed.