Description: Not sure if this is a real bug or not, so please bear with me. I'm generating an .odt file in another program. It writes style info to the styles.xml file with font size printed as %.1f, thus, for instance: <style:text-properties fo:font-size="28,0pt" fo:font-weight="bold" style:font-size-asian="28,0pt" style:font-weight-asian="bold" style:font-size-complex="28,0pt" style:font-weight-complex="bold"/> Notice 28,0pt three times. If I open this in Loffice writer, it blows the font up to 280pt. Like it ignores the comma. The comma is generated by printing library as it observes the French locale. To test this, I generated a small writer file from Loffice run in French mode, put in some text at 28pt, saved it, unzipped the .odt, changed the font from 28pt to 28,0pt, and rezipped the .odt file (zip -r). Loffice claims that the file is corrupted when I load it. So, I permit the repair, and then you can see the fonts go from 28,0 point up to 280pt. Caveat: I am unsure why the re-zipped file is corrupted, since the only change I made was to the font specification. I'm probably doing something wrong there. But the substance of the "bug" remains. I can probably fix my problem by not using fractional point sizes, but I didn't want to limit my program that way if Loffice can handle them and I just don't know how yet. I am running Loffice on Ubuntu 17.10, under this env: export LANG=fr_FR.UTF-8 export LANGUAGE=fr_FR:fr loffice Steps to Reproduce: 1. Open file attached to this bug report (test6revised.odt) 2. Repair it. 3. Note that font is 280pt, but styles.xml in the .odt says 28,0pt Actual Results: .odt styles.xml is parsed so that 28,0pt becomes 280pt. Expected Results: Expect the xml to be "obeyed" so that 28,0pt results in 28.0pt size font. Reproducible: Always User Profile Reset: No Additional Info: Note that in steps to reproduce, when running Loffice in the French env, it just says that the file has an error in it and won't offer to repair. I have to repair it in Loffice running in the English environment. Help | About Version: 5.4.5.1 Build ID: 1:5.4.5-0ubuntu0.17.10.5 Threads CPU : 2; OS : Linux 4.13; UI Render : par défaut; VCL : gtk3; Locale : fr-FR (fr_FR.UTF-8); Calc: group User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Created attachment 140792 [details] ODT file that shows the potential bug This test file was generated by : 1. Create a simple Writer file in Loffice (French env) 2. Unpack it. Edit styles.xml to change 28pt to 28,0pt. Zip -r to recreate .odt. Open it in Loffice, recover, and note that fonts are now 280pt.
(In reply to Matt from comment #0) > Not sure if this is a real bug or not, so please bear with me. > I'm generating an .odt file in another program. It writes style info to the > styles.xml file with font size printed as %.1f, thus, for instance: > > <style:text-properties fo:font-size="28,0pt" fo:font-weight="bold" > style:font-size-asian="28,0pt" style:font-weight-asian="bold" > style:font-size-complex="28,0pt" style:font-weight-complex="bold"/> That's primarily a bug in the other program. It must not write values with localized separators to XML. See xmlschema-2 that defines period ('.' full stop) as decimal indicator. > Notice 28,0pt three times. If I open this in Loffice writer, it blows the > font up to 280pt. Like it ignores the comma. It probably does, because comma is a group (aka thousands) separator. > The comma is generated by > printing library as it observes the French locale. Which is wrong. > To test this, I generated a small writer file from Loffice run in French > mode, put in some text at 28pt, saved it, unzipped the .odt, changed the > font from 28pt to 28,0pt, and rezipped the .odt file (zip -r). Loffice > claims that the file is corrupted when I load it. Instead of re-zipping, freshen the zip (zip -f) with the changed file. Rezip may change the order and compression of files, but the mimetype file has to be very the first file in the zip and not be compressed.