Bug 38929 - FORMATTING: Changing most font attributes has no effect on testcase Impress table when two cells are selected
Summary: FORMATTING: Changing most font attributes has no effect on testcase Impress t...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.3.3 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-03 09:04 UTC by Milan Bouchet-Valat
Modified: 2015-05-01 16:21 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Testcase presentation (11.72 KB, application/vnd.oasis.opendocument.presentation)
2011-07-03 09:04 UTC, Milan Bouchet-Valat
Details
picture from inside of presentation in format VCLMTF (1.58 KB, image/x-svm)
2012-09-26 11:55 UTC, sasha.libreoffice
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Bouchet-Valat 2011-07-03 09:04:06 UTC
Created attachment 48708 [details]
Testcase presentation

I've experienced a few oddities when formatting text in tables in Impress. Attached is a simple test case illustrating a problem I have.

1. Select the two cells.

2a. Set font to bold.
3a. See that nothing changes (though the Bold button in the toolbar reflects the new state).
(You can also try changing the font size: the toolbar changes, but not the text. Actually, the new parameters are forgotten as soon as you change the selection.)

2c. Set font to italic.
3c. See that it works OK.

2c. Change the font family.
3c. See that only the first cell changes!


Needless to say, this it a complete nightmare... ;-)
Comment 1 Milan Bouchet-Valat 2011-07-03 09:05:11 UTC
Ah, exact version is 3.3.3.1-1 on Fedora 15.
Comment 2 Björn Michaelsen 2011-12-23 12:21:01 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 3 Florian Reisinger 2012-08-14 13:57:32 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 4 Florian Reisinger 2012-08-14 13:58:52 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 5 Florian Reisinger 2012-08-14 14:03:25 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 6 Florian Reisinger 2012-08-14 14:05:40 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 7 Milan Bouchet-Valat 2012-08-14 17:39:21 UTC
Still present in LibreOffice 3.5.5.3 (Fedora 17). Just check the attached testcase.
Comment 8 Florian Reisinger 2012-08-16 11:36:00 UTC
I check this ASAP
Comment 9 Andreas Lartz 2012-08-28 18:38:54 UTC
Tested with LO 3.6 at Opensuse 12.1 32bit:

The bug is fixed. I have downloaded the testcase and have checked the described problems.
1. select the cells
2a. set font to bold: works in both cells!
2b. set font to italic: works in both cells!
2c. change font family: works in both cells!
Comment 10 Milan Bouchet-Valat 2012-08-28 20:16:51 UTC
Sorry, it still does not work here on Fedora 17 with LibreOffice 3.6.0.4 64 bits. Underline and shadow work perfectly, but italic, bold and font family and size still do not have any effect, except for changing the button state. This is even slightly worse than what I first described! ;-)

Could somebody confirm that my problem is reproducible?
Comment 11 Florian Reisinger 2012-08-29 08:54:43 UTC
Have you deleted / renamed the user profile?
Comment 12 Milan Bouchet-Valat 2012-08-29 09:09:14 UTC
(In reply to comment #11)
> Have you deleted / renamed the user profile?
Yes, same result with a completely new user account.
Comment 13 sasha.libreoffice 2012-09-26 11:55:17 UTC
Created attachment 67721 [details]
picture from inside of presentation in format VCLMTF
Comment 14 sasha.libreoffice 2012-09-26 12:04:48 UTC
Attachment contains picture inside in format VCLMTF. To open this picture, start LO and drag-and-drop this picture to it.
When we change table in presentation, we see not table, but this picture. Therefore problem is in this concrete document, not in Impress.

But how created this presentation? If available, please, provide step-by-step instructions of how to create such document from scratch.

Or if this presentation created from template, then problem is inside of template.

We can also ask developers to add functionality for removing such pictures from document automatically.
Comment 15 Milan Bouchet-Valat 2012-09-27 17:04:17 UTC
Sorry, but that's not just a picture in the original document: I can change the text in it, add or remove rows, and even change the formatting of the text (and so did Andreas). It's just that when I select *both cells*, several formatting options have no effect.
Comment 16 gmolleda 2013-01-26 08:26:41 UTC
Same behaviour with LibreOffice 3.6.4.3 in Debian Squeeze.

If create a table, write some text in cells, select two or more cells and change size or font, don't work.
Comment 17 gmolleda 2013-03-16 22:11:32 UTC
Work-around:
1) Select the text (not cell) in one cell
2) Change font, size, color, ... 
3) Use the paste format button for give the same format to other cells (selecting all in one time).

But, this method copy all format, not only one style (only size, only color, ...)

LibreOffice Impress 4.0.1.2
Comment 18 Milan Bouchet-Valat 2013-08-18 17:13:14 UTC
Still present with LO 4.1.0.4.

I think I have found the root problem in this bug (see below). Any chance to get some attention?

In the attached testcase (see XML extracts below), bold font is determined both by cell-level text styles, and by inside-cell paragraph and text styles. The state of the Bold button in the toolbar only reflects the attributes of inside-cell text styles. So when one cell has bold font set by an inside-cell text style, the Bold button considers bold is enabled: when you click on it, Impress tries to disable bold font. This results in both cell-level (ce1) and inside-cell (P1) paragraph styles to be updated, but not change is visible since inside-cell text style (T1) already specified that no bold font should be used, which contradicted ce1.

Likewise, the inside-cell text style for the second cell (T2) is not updated, so it continues to specify a bold font. When selecting both cells, the Bold button is still enabled. Yet, when toggling it, ce1 and P1 are changed to *enable* bold (instead of disabling it as it should), which again has no effect.

So the main issue is that T2 is never updated. But there seem to be other inconsistencies that may be a consequence of this failure to update this style.



XML details:

In the attached testcase, the XML for the table is:
<table:table table:template-name="default" table:use-first-row-styles="true" table:use-banding-rows-styles="true">
  <table:table-column table:style-name="co1"/>
  <table:table-row table:style-name="ro1">
    <table:table-cell table:style-name="ce1">
      <text:p text:style-name="P1">
        <text:span text:style-name="T1">Test1</text:span>
     </text:p>
   </table:table-cell>
  </table:table-row>
  <table:table-row table:style-name="ro1">
    <table:table-cell table:style-name="ce1">
      <text:p text:style-name="P1">
        <text:span text:style-name="T2">Test2</text:span>
        </text:p></table:table-cell>
  </table:table-row>
</table:table>

What changes when disabling bold font while selecting both cells is cell styles P1 and T1:
 <style:style style:name="ce1" style:family="table-cell">
 <style:graphic-properties draw:fill="solid" draw:fill-color="#e6e6e6" style:repeat="repeat" draw:textarea-vertical-align="middle" fo:padding-top="0.1cm" fo:padding-bottom="0.1cm" fo:padding-left="0.1cm" fo:padding-right="0.1cm"/>
 <style:paragraph-properties fo:text-align="start" fo:border="none"/>
-<style:text-properties style:font-name="DejaVu Serif" fo:font-size="28pt" fo:font-style="normal" fo:font-weight="bold" style:font-size-asian="28pt" style:font-style-asian="normal" style:font-weight-asian="bold" style:font-size-complex="28pt" style:font-style-complex="normal" style:font-weight-complex="bold"/>
+<style:text-properties style:font-name="DejaVu Serif" fo:font-size="28pt" fo:font-style="normal" fo:font-weight="normal" style:font-size-asian="28pt" style:font-style-asian="normal" style:font-weight-asian="normal" style:font-size-complex="28pt" style:font-style-complex="normal" style:font-weight-complex="normal"/>
 </style:style>
 <style:style style:name="P1" style:family="paragraph">
 <style:paragraph-properties fo:text-align="start"/>
+<style:text-properties fo:font-weight="normal" style:font-weight-asian="normal" style:font-weight-complex="normal"/>
 </style:style>
 <style:style style:name="T1" style:family="text">
 <style:text-properties style:font-name="DejaVu Serif" fo:font-size="18pt" fo:font-style="normal" fo:font-weight="normal" style:font-size-asian="18pt" style:font-style-asian="normal" style:font-weight-asian="normal" style:font-size-complex="18pt" style:font-style-complex="normal" style:font-weight-complex="normal"/>

And when trying again to disable bold with both cells selected, the inverse change happens:
<style:style style:name="ce1" style:family="table-cell">
 <style:graphic-properties draw:fill="solid" draw:fill-color="#e6e6e6" style:repeat="repeat" draw:textarea-vertical-align="middle" fo:padding-top="0.1cm" fo:padding-bottom="0.1cm" fo:padding-left="0.1cm" fo:padding-right="0.1cm"/>
 <style:paragraph-properties fo:text-align="start" fo:border="none"/>
-<style:text-properties style:font-name="DejaVu Serif" fo:font-size="28pt" fo:font-style="normal" fo:font-weight="normal" style:font-size-asian="28pt" style:font-style-asian="normal" style:font-weight-asian="normal" style:font-size-complex="28pt" style:font-style-complex="normal" style:font-weight-complex="normal"/>
+<style:text-properties style:font-name="DejaVu Serif" fo:font-size="28pt" fo:font-style="normal" fo:font-weight="bold" style:font-size-asian="28pt" style:font-style-asian="normal" style:font-weight-asian="bold" style:font-size-complex="28pt" style:font-style-complex="normal" style:font-weight-complex="bold"/>
 </style:style>
 <style:style style:name="P1" style:family="paragraph">
 <style:paragraph-properties fo:text-align="start"/>
-<style:text-properties fo:font-weight="normal" style:font-weight-asian="normal" style:font-weight-complex="normal"/>
+<style:text-properties style:font-name="DejaVu Serif" fo:font-weight="bold" style:font-weight-asian="bold" style:font-weight-complex="bold"/>
 </style:style>
 <style:style style:name="T1" style:family="text">
 <style:text-properties style:font-name="DejaVu Serif" fo:font-size="18pt" fo:font-style="normal" fo:font-weight="normal" style:font-size-asian="18pt" style:font-style-asian="normal" style:font-weight-asian="normal" style:font-size-complex="18pt" style:font-style-complex="normal" style:font-weight-complex="normal"/>
Comment 19 Jérôme Borme 2013-12-01 17:22:59 UTC
The testcase is still buggy with libreoffice 4.1.3.2. However with a table newly created, both italics and bold can be changed in my tests. But anyway, the bug is still there in a form or another, as changing the font family (in a new table in a clean document) has no effect when several cells are selected.
Comment 20 sasha.libreoffice 2013-12-02 05:47:12 UTC
Steps of creating test case from scratch in 4.1.3:
0. Start Impress
1. Create there table such as in first attachment
2. Save as ppt 2003
3. File->reload
4. Save as odp
5. File->reload
Comment 21 QA Administrators 2015-04-19 03:20:15 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

   *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later)
   https://www.libreoffice.org/download/

   *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
   *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

   *Update the version field
   *Reply via email (please reply directly on the bug tracker)
   *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 

1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug 
3. Leave a comment with your results. 
4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
Comment 22 Milan Bouchet-Valat 2015-05-01 16:21:43 UTC
Looks like this is fixed in 4.4.2.2. Great!