Issue 67206 - Applying both a font effect and a font position has problems
Summary: Applying both a font effect and a font position has problems
Status: CONFIRMED
Alias: None
Product: Calc
Classification: Application
Component: formatting (show other issues)
Version: OOo 2.0.3
Hardware: All All
: P4 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-10 22:05 UTC by Andrea Pescetti
Modified: 2013-08-07 15:13 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 Andrea Pescetti 2006-07-10 22:05:17 UTC 
1. Open Calc, create a new sheet, insert some text.
2. Select some text within a cell.
3. "Format" -> "Character"
4. In the "Font Effect" tab, set "underlining" to "single".
5. Switch to the "Font Position" tab.
6. Set "position" to "superscript".
7. Go back to the "Font Effect" tab.
8. Set "underlining" to "(Without)".
9. Go to the "Font Position" tab again.

Expected:
10. The text is not underlined in Preview or in the actual document
    after pressing OK.

Actual:
10. The text is underlined in Preview and it is inserted underlined
    if you press OK.

[Reported by Alessandra during Italian QA tests]
Comment 1 gercokees 2006-07-12 09:19:40 UTC 
Confirmed
Comment 2 frank 2006-07-13 09:22:25 UTC 
Hi Thomas,

one for you I think.

Frank
Comment 3 thomas.lange 2006-08-08 09:51:32 UTC 
The problem in svx\source\dialog\chardlg.cxx is in the FillItemSet function
which has code like this:

=======================================
	if ( pOld )
	{
        //! if there are different underline styles in the selection the
        //! item-state in the 'rOldSet' will be invalid. In this case
        //! changing the underline style will be allowed if a style is
        //! selected in the listbox.
        BOOL bAllowChg = LISTBOX_ENTRY_NOTFOUND != nPos  &&
                         SFX_ITEM_DEFAULT > rOldSet.GetItemState( nWhich, TRUE );

		const SvxUnderlineItem& rItem = *( (const SvxUnderlineItem*)pOld );
		if ( (FontUnderline)rItem.GetValue() == eUnder &&
             ( UNDERLINE_NONE == eUnder || rItem.GetColor() ==
m_aColorLB.GetSelectEntryColor() ) &&
             ! bAllowChg )
			bChanged = FALSE;
	}

	SfxItemState eS = rOldSet.GetItemState( nWhich, FALSE );
	if ( bChanged )
	{
		SvxUnderlineItem aNewItem( eUnder, nWhich );
		aNewItem.SetColor( m_aColorLB.GetSelectEntryColor() );
		rSet.Put( aNewItem );
		bModified |= TRUE;
	}
 	else if ( SFX_ITEM_DEFAULT == rOldSet.GetItemState( nWhich, FALSE ) )
		CLEARTITEM;

=======================================

The above code works fine with the Writer but with the EditEngine in the second
last line the item will not be a default item and thus the CLEARTITEM call is
missed.

modifying the code like this will fix the problem for this item:

=======================================
...
 	else if ( SFX_ITEM_DEFAULT == rOldSet.GetItemState( nWhich, FALSE ) )
		CLEARTITEM;
	else
	{
		const SfxPoolItem* pTemp = NULL;
		if ( rOldSet.GetItemState( nWhich, FALSE, &pTemp ) == SFX_ITEM_SET )
		{
			FontUnderline eOld1 = (FontUnderline)( (const SvxUnderlineItem*)pOld
)->GetValue();
			FontUnderline eOld2 = (FontUnderline)( (const SvxUnderlineItem*)pTemp
)->GetValue();

			if ( eOld2 == eUnder )
				CLEARTITEM;
		}
	}

=======================================


The greater problem is that there probably most of the other items in this
tab-page and in the other tab-pages will have the same problem.
And also there are various other settings where this dialog gets used (e.g.
Writer, Stylist, ...) and none of them must be broken by the new code.

TL->PB: Thanks for taking over!
Comment 4 akrama 2007-02-01 00:10:23 UTC 
Issue confirmed. I got the same results with OpenOffice 2.0.3 on Windows XP
Professional Edition, SP 2 installed. 

Works the same way on same version of OpenOffice installed on "Linux 2.6.9-42.0.3"
Comment 5 akrama 2007-02-01 15:49:16 UTC 
If we follow the same set of steps to produce the bug as mentioned by pescetti. 
It works the same way even when I tried to set the position "subscript" instead 
of "superscript".
The same problem occurs with version 2.1 on Win XP Home Edition.
Comment 6 pb 2007-02-05 08:37:09 UTC 
pb: accepted.
Comment 7 Martin Hollmichel 2007-11-09 16:52:43 UTC 
change target from 2.x to 3.x according to
http://wiki.services.openoffice.org/wiki/Target_3x
Comment 8 Mathias_Bauer 2009-05-07 13:08:43 UTC 
Thomas, please take over