Bug 62147 - FILEOPEN table embedded in ODT: <table-cell string-value="FOO" table:style-name="BAR"/>: style BAR not applied to FOO
Summary: FILEOPEN table embedded in ODT: <table-cell string-value="FOO" table:style-na...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.1.2 release
Hardware: x86 (IA32) All
: high major
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: odf target:4.1.0 target:4.0.4
Keywords:
: 62811 63489 63529 63623 63641 (view as bug list)
Depends on: 60842
Blocks: 68020
  Show dependency treegraph
 
Reported: 2013-03-11 07:14 UTC by Benjamin Wagner
Modified: 2013-11-13 20:41 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Shows the wrong format of textfields in a report since LO 4.0.1 (95.10 KB, application/vnd.oasis.opendocument.text)
2013-03-13 07:16 UTC, Robert Großkopf
Details
Database to test the wrong behavior (26.05 KB, application/vnd.sun.xml.base)
2013-03-13 07:17 UTC, Robert Großkopf
Details
Screenshot to describe wrong behavior (6.38 KB, image/png)
2013-03-16 23:53 UTC, Uwe Graßhoff
Details
reproduction example (4.83 KB, application/vnd.oasis.opendocument.text)
2013-04-08 10:34 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Wagner 2013-03-11 07:14:57 UTC
An existing Form in the Base-Modul has the font attribute Arial, Size 9, bold.
Open the Form with LibreOffice 4.0.0.3 shows the font correct.

In LibreOffice 4.0.1.2 all fonts on the form are Times New Roman, Size 9.

Open the Form again with older versions of LibreOffice shows alwaqyas the font correct, only in 4.0.1.2 the fonts are wrong.

Tested unter Windows7 x32
Comment 1 Robert Großkopf 2013-03-12 20:41:14 UTC
Have you formatted the fields in the form? Or are the fields formatted as Font (Standard)?

I could not confirm this behavior with OpenSuSE 11.4 32bit rpm Linux and LO 4.0.1.2 - but it's Linux.

You could selsct all fields together and change the font to the font you wish.
Comment 2 Benjamin Wagner 2013-03-13 06:32:59 UTC
The fileds are formatted as fonts, some with bold because they are capitals, some with standard text, for example Arial 10pt.

With version 3.6.x the filed are show right in the form, with the correct Fonts.
With version 4.0.0 is also looks good, with version 4.0.1 all fonts are already defined in the text field, but on the report none of the defined fonts are used.

I can only check it at the moment with Windows7 x32 because the database contains confidential data so it is not allowed to use it on other systems.
Comment 3 Benjamin Wagner 2013-03-13 06:34:42 UTC
Sorry, i just see that i have a wrong description:
the fonts are display wrong in a REPORT, not on a form!!!
Comment 4 Robert Großkopf 2013-03-13 07:16:45 UTC
Created attachment 76453 [details]
Shows the wrong format of textfields in a report since LO 4.0.1

All fields in a report are formatted with a chosen font. The fields of the shown report were formatted with "Liberation Sans". One filed is a field with text-content. Only fields with text-content are shown wrong.
Comment 5 Robert Großkopf 2013-03-13 07:17:53 UTC
Created attachment 76454 [details]
Database to test the wrong behavior
Comment 6 Robert Großkopf 2013-03-13 07:25:35 UTC
(In reply to comment #3)
> Sorry, i just see that i have a wrong description:
> the fonts are display wrong in a REPORT, not on a form!!!

Yes, I have seen it in a report. It's the same behavior in Linux 32bit rpm.
I have set the report to "New" and keyword to "regression".
Could be the importance for you is high and major. Others would say: not dataloss, all is shown, but doesn't look nice. A reported bug wouldn't be fixed faster by settings of the importance only.
Comment 7 Leo 2013-03-13 16:24:00 UTC
+1
I'm seeing this exact problem with LO 4.0.1.2, running on Ubuntu 12.04 (precise). My report accesses a query, and the builder form accepts format (font,size) changes, but when i run the report the data fields retain 'default' fonts & sizes.
Comment 8 Uwe Graßhoff 2013-03-16 23:53:28 UTC
Created attachment 76632 [details]
Screenshot to describe wrong behavior

I recognised this wrong behavior too. I recently updatet to Libre Office 4.0.1.2 on Windows 7 x64.

Any changes of the font propertys like size, style, color, or the type of font are ignored during report generation. At labels all is working properly but labels can't contain database values.

See Screenshot for example.
Comment 9 Uwe Graßhoff 2013-03-16 23:55:04 UTC
I recognised this wrong behavior too. I recently updatet to Libre Office 4.0.1.2 on Windows 7 x64.

Any changes of the font propertys like size, style, color, or the type of font are ignored during report generation. At labels all is working properly but labels can't contain database values.

See Screenshot for example.
Comment 10 Uwe Graßhoff 2013-03-19 08:05:55 UTC
I also tested LibreOffice Version 4.0.2.1 (Build ID: 7e5467ff8f30d821f4fbf69cb2769163eb64c2c)

Bug is also there and there are new bugs for example you cant resize a label or textfield via mouse. If you try it the complete programm is crashing.
Comment 11 Robert Großkopf 2013-03-19 14:41:33 UTC
(In reply to comment #10)
> I also tested LibreOffice Version 4.0.2.1 (Build ID:
> 7e5467ff8f30d821f4fbf69cb2769163eb64c2c)
> 
> Bug is also there 
> 
How should the bug with the wrong fonts have been gone? I don't see any fix here and nobody, who had closed the bug as fixed.

> and there are new bugs for example you cant resize a label
> or textfield via mouse. If you try it the complete programm is crashing.

Please don't report more than one bug in one report. If you have found another bug, create a new report.
Comment 12 myth 2013-03-21 18:11:39 UTC
I am seeing the same bug.  Here is a description of how to reproduce the bug starting from scratch with a freshly-installed LO 4.0.1.2:

1) Create a new document by clicking Database in the LibreOffice opening screen
2) Click "Next" with "Create a new database" selected
3) There is no need to register the database, but click "Finish"
4) Let the name default to "New Database"
5) Click "Create Table in Design View"
6) Create a new Table, adding a field named "Foo", leaving the type at the default, which is Text [ VARCHAR ]
7) Exit, saving changes and allowing the software to create a primary key
8) Leave the table with the default name, "Table1"
9) Double click the new "Table1" to open it for editing
10) Fill in a sample row, with ID set to 1 and Foo set to Bar
11) Close "Table1", saving changes
12) Click "Reports" and "Create Report in Design View"
13) Click "Detail"
14) Double-click "Foo" to add "Foo" to the "Detail" section of your report
15) Close the "Add" dialog box
16) Make sure the value box containing "=Foo" is still selected
17) Click the "..." next to Font and change the Arial Regular 12 to "Comic Sans MS Bold 20"
18) Close the window, saving changes as "Report1"
19) Double-click your new "Report1" to open the report
20) Notice that the word "Foo" appears in Comic Sans MS Bold, but the word "Bar" is still in Times New Roman 12.

Since upgrading to LibreOffice 4.0, my Reports in Base are no longer formatted correctly. No matter what font I specify (even something zany like Wingdings Bold Italic 16 point), the fields in the report still come out using the default font, Times New Roman 12 point. Many of my fields aren't actually big enough for 12 point type, so the reports look jumbled, with partial lines printing on top of each other.
Comment 13 frofa 2013-03-28 05:03:28 UTC
*** Bug 62811 has been marked as a duplicate of this bug. ***
Comment 14 Alex Thurgood 2013-04-08 07:38:27 UTC
Adding Lionel to CC
Comment 15 Lionel Elie Mamane 2013-04-08 09:43:41 UTC
This smells like it is caused by


commit 3b605c98a1e6385211e1f2ab76a1b86202f988cb
Author: Lionel Elie Mamane <lionel@mamane.lu>
Date:   Tue Feb 19 11:38:16 2013 +0100

    fdo#52948 fix print-repeated-values=no with formatted values
Comment 16 Lionel Elie Mamane 2013-04-08 09:45:35 UTC
Possibly in interaction with:


commit	2b08767693604e43023dda30734ab1ff5921048c
author	Michael Stahl <mstahl@redhat.com>	2013-02-15 21:36:55 (GMT)
committer	 Miklos Vajna <vmiklos@suse.cz>	2013-02-18 10:02:32 (GMT)

fdo#60842: sw ODF import: support value-type="string" on cells:
Comment 17 Lionel Elie Mamane 2013-04-08 10:33:43 UTC
@mstahl: Thanks for fixing bug 60842. However, in such a case:

  <table:table-cell table:style-name="ce2" office:value-type="string">
       <text:p>Robert</text:p>
  </table:table-cell>

  <table:table-cell table:style-name="ce2" office:string-value="Mary" office:value-type="string">
        <text:p>Mary</text:p>
  </table:table-cell>

The style "ce2" is *not* applied to the "Mary" string. I attach an example Writer file (hand-edited):

In the first row, for "Robert", I removed the "office:string-value" attribute, and the style is applied to the "<text:p>Robert</text:p>". In the second row, for "Mary", the office:string-value overrides the child, but the ce2 style is not applied.

Since styles are applied to office:date-value attributes, I'd expect them to be applied to office:string-value, too.

(If for some reason this is hard/long time to fix, I can work around this in Report Builder code by not emitting "office:string-value" attributes. Let me know.)
Comment 18 Lionel Elie Mamane 2013-04-08 10:34:56 UTC
Created attachment 77584 [details]
reproduction example
Comment 19 Lionel Elie Mamane 2013-04-10 17:14:43 UTC
So, the patch to work around this bug in reportbuilder is at https://gerrit.libreoffice.org/3311

My aim is to get either the work-around or this bug fixed in 4.0.3.
Comment 20 Robert Großkopf 2013-04-13 06:30:16 UTC
*** Bug 63489 has been marked as a duplicate of this bug. ***
Comment 21 Commit Notification 2013-04-13 13:20:34 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=add46920608b6f5b79c0ca33845eae4e1e59a4b6&h=libreoffice-4-0

work around fdo#62147


It will be available in LibreOffice 4.0.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 22 Robert Großkopf 2013-04-14 17:23:55 UTC
*** Bug 63529 has been marked as a duplicate of this bug. ***
Comment 23 Robert Großkopf 2013-04-17 19:13:31 UTC
*** Bug 63641 has been marked as a duplicate of this bug. ***
Comment 24 Lionel Elie Mamane 2013-04-18 05:19:30 UTC
*** Bug 63623 has been marked as a duplicate of this bug. ***
Comment 25 Commit Notification 2013-04-22 22:38:45 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=84217e299724b8ee80dff63cb561b4bae0f44835

fdo#62147: sw: ODF import: apply styles in cells with string-value



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 26 Michael Stahl (CIB) 2013-04-23 10:57:12 UTC
this should be fixed on master.

not sure if you want report-designer to rely on this being fixed
now already; in case the generated documents are persistent it
would make sense to wait a year or so in case users open
generated documents with older LO versions (but if the
generated documents are transient there shouldn't be a
problem relying on the fix now).  guess i don't know
what this reporting stuff does anyway :)
Comment 27 Lionel Elie Mamane 2013-04-23 11:59:44 UTC
Thanks!

The reportbuilder documents are transient, in the sense that they are saved to $TMPDIR and then automatically opened in Writer, so the straightforward way to keep an ODT format copy is simply "file / save as", which will regenerate the ODT format; I presume that Writer does that in a backwards-compatible way.

The user could theoretically fish the original document directly from $TMPDIR, but that's an "advanced user" scenario, so I'm not too worried.
Comment 28 Commit Notification 2013-04-23 14:51:12 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=00a8e4604802cecfb87d62a5edc9ef314400ebb4&h=libreoffice-4-0

fdo#62147: sw: ODF import: apply styles in cells with string-value


It will be available in LibreOffice 4.0.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.