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: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Presentation (show other bugs)
Version: 3.3.3 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-03 09:04 UTC by Milan Bouchet-Valat
Modified: 2013-12-02 05:47 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


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

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 [review]. Save as ppt 2003
3. File->reload
4. Save as odp
5. File->reload


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.