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
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.
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.
Sorry, i just see that i have a wrong description: the fonts are display wrong in a REPORT, not on a form!!!
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.
Created attachment 76454 [details] Database to test the wrong behavior
(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.
+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.
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.
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.
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.
(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.
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.
*** Bug 62811 has been marked as a duplicate of this bug. ***
Adding Lionel to CC
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
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:
@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.)
Created attachment 77584 [details] reproduction example
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.
*** Bug 63489 has been marked as a duplicate of this bug. ***
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.
*** Bug 63529 has been marked as a duplicate of this bug. ***
*** Bug 63641 has been marked as a duplicate of this bug. ***
*** Bug 63623 has been marked as a duplicate of this bug. ***
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.
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 :)
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.
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.