Created attachment 92051 [details] example odt problem e image format correct. The ODTs documents that were created in LibreOffice 3.6 are losing the formatting styles when opened in libreoffice 4.x. Attached an example of a document with an image problem and the correct format of the document.
Hi Emerson, Can you pls describe presicely the problem? Which line, paragraph, style ... thanks a lot, Cor
Description of the problem: When we open a document created in version 3.6 and contains numerators / markers follow the following formats are modified / added: A 5pt border is added and the spacing between the letters is changed from 0.3 to 2.4 pt condensed in the following styles: Title of document text Items markers
a comparative screenshot of the 3.6 look of the document and the 4.x look would help as well
Created attachment 92275 [details] Print Screen of libre office 4 - format problem Print Screen of libre office 4 - format problem
Created attachment 92276 [details] Print Screen of libre office 3.6 - format OK Print Screen of libre office 3.6 - format OK
I do not reproduce with versions 4.0.6 and 4.1.4 (release) or 4.2.1.0.0+ (development) on Ubuntu 13.10 x86-64. Please, try to reinitialize your LibreOffice user profile : https://wiki.documentfoundation.org/Faq/General/110 Best regards. JBF
I don't reproduce with LO 4.2.0.2 nor with LO 4.2.1.0.0+ Build ID: d77f6160afc213cd1cb8c658ece4e074f4e60bce TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-01-17_02:12:39 Windows 7 Home Premium Kind regards, Jacques
Today I tested it on several computers with windows xp and windows 7 and all PCs I could reproduce the problem. The fact that the windows in Portuguese can be the problem?
I also can not reproduce this bug running 4.2.0.2 on mac osx 10.9.2
Bug confirmed under Windows XP x86 using LO 4.2.1.1 with Portuguese UI The text with Tahoma font is indeed tighter than when the English UI is used. Please notice that the odd formatted text is set to Character Spacing: Very Tight However selecting the text and clicking on Very Tight (i.e. reapplying the style) with the English UI produces the same result on the font. However the black bars only show up with the Portuguese UI
The black bars also appears in pt-BR. The black bars are borders in Texto style, inherited from "Capa do título" style.
Just checked with LO 4.0.6.2 with Portuguese UI and the problem does not occur Therefore this is a regression in branch 4.1 Emerson, I recommend that you install version 4.0.6.2 available from http://downloadarchive.documentfoundation.org/libreoffice/old/4.0.6.2/ until this bug is fixed
should we label this as a mab4.1?
(In reply to comment #0) > Created attachment 92051 [details] > example odt problem e image format correct. > > The ODTs documents that were created in LibreOffice 3.6 are losing the > formatting styles when opened in libreoffice 4.x. > @Emerson which 4.x did you use? 4.0.x branch or 4.1.x branch? did you try 4.0.6 a s suggested by Pedro?
Hello, I just checked in version 4.0.6.2 and it worked perfectly.
We are currently using version 4.1.x
on Linux, cannot reproduce any borders being drawn in any version i tried. only difference i can see: in 3.6.6 the "below paragraph" spacing on the list items is 0.3 cm, but in 3.6.5 and older it is 0cm. actually in OOo 3.3 and LO 3.4.6 it is also 0.3cm... presumably change in 3.6.6 a bugfix? ah indeed it is: commit abb84c2cce54a903ef846cbfe297b2bbc62ff260 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Thu Jan 17 12:41:11 2013 +0000 Resolves: fdo#58730 workaround [UL|LR]Space 100% problem
Estou em férias, retorno dia 17/03. Obrigado Emerson Valdir Pellis
hi Emerson, are you still reproducing the issue in LibO 4.2.5.2? it looks fine to me using that version.
Adding keyword 'preBisect' as this regression was introduced before branch 4.4 and therefore it can't be bibisected as there's no bibisect repository for this branch.
** 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 (5.4.1 or 5.3.6 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 helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
example looks good in Version: 6.3.0.0.alpha0+ (x64) Build ID: eca59b6b8a0cf826ac59f77aec9acf045340c23f CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-01-16_03:48:12 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded Status->WFM