Created attachment 42715 [details] .lwp '97 format document containing examples of paragraph spacing Currently, the Lotus Word Pro import filter doesn't handle Paragraph Spacing. This would be equivalent to the information contained in <style:paragraph-properties fo:margin-top="x" fo:margin-bottom="y"/> in the .odt format. Word Pro allows these to be set in terms of # of lines (1/2 line, 1 whole line, multiple lines) as well as custom spacings (measured in cm/points/picas). I'm not sure how these are stored internally in the .lwp format. I've attached a sample document containing a range of different paragraph spacings, and a .pdf which provides a comparison between LWP '97 and LibO 3.3 handling of this sample document at the moment.
Created attachment 42716 [details] PDF showing Lotus Word Pro '97 and LibreOffice Writer 3.3 handling of sample document
[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
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
Nobody tested yet. Changing to Unconfirmed
Paragraph spacing still doesn't happen in Writer 3.6
Not sure why this bug is set as an enhancement when related bug 33787 and bug 33838 are not. Severity set to normal. Import of the content in the provided example has regressed since the originally reported v3.3. All versions I have tested (3.5.7.2, 4.1.6.2, 4.2.5.2, 4.3.0.3, and 4.4.0.0alpha+) now only import unformatted text.
** 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.0.0.5 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Yeah, unformatted text imported. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: b216cc1b8096eb60c27f67e8c27b7cd756c75e38 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-12_00:06:20 Locale: fi-FI (fi_FI)
Compared to an older version of the OpenOffice Writer, there is a new function in the format paragraph dialogue (Format / Absatz). This is the option "No spaces between paragraphs using the same format pattern" or so - I do not know the English expression while working with the German version. Perhaps this is a function that I proposed to the OpenOffice Project some years ago. In this case my proposition is misunderstood; the actual option has no real or senseful application. This is the bug. My proposition was different: The space above a heading paragraph is always correct after a text block. Like this: --- 2.1 ADVANTAGES OF LIBREOFFICE The following advantages of ... 2.2 BUGS IN LIBREOFFICE A list of bugs ... --- But in the case of two heading paragraphs of different hierarchy, following directly one to the other, the space makes no sense and the layout looks badly. Like this: --- 1 The LIBREOFFICE HANDBOOK 1.1 INTRODUCTION What I want to tell ... --- This is no good formatting. But by suppressing the linespace above(!) a heading paragraph that is preceeded by annother heading paragraph of higher hierarchy we get something like this: --- 1 The LIBREOFFICE HANDBOOK 1.1 INTRODUCTION What I want to tell ... --- This means that in the case of lacking text belonging directly to the heading of the higher rank, You only get the space that is defined to come below(!) the first (higher) heading and not the space that normally is set above the second heading. This should render a better layout and this should be the sense of this option.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Paragraphing still doesn"t work in: Version: 6.1.0.3 Build ID: 6.1.0-2 CPU threads: 12; OS: Linux 4.18; UI render: default; VCL: gtk2; Locale: de-DE (en_US.UTF-8); Calc: group threaded
Dear Jaxson Lee, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This shouldn't be hard to do. The relevant information is already parsed, it just isn't used... Some high-level info about LWP import code: The code resides in lotuswordpro. Parsing is two-step, with ODF as an intermediate format, i.e., the parser reads a LWP document, produces an (internal) ODF document, which is then imported. The parser itself is in lotuswordpro/source/filter. In general, each concept of the file format is represented by a separate class, with names starting with Lwp. ODF export is in lotuswordpro/source/filter/xfilter. In general, there is a class for each ODF element, but there are some that just group together a bunch of related arguments (e.g., XFMargins). Class names start with XF or IXF. The construction of the ODF is done in ToXml() functions. Now to the task at hand: LwpParaStyle::ApplySpacing() needs to handle LwpSpacingCommonOverride::SPACING_DYNAMIC (and possibly also SPACING_LEADING) for abovepara and belowpara. Then the additional info that the margin size is relative (percentual) needs to be passed through XFParaStyle::SetMargins() down to XFMargins (Maybe change the SetMargins() arguments to std::variant? That would also remove the need for a special value meaning "not set".). Finally, XFMargins::ToXml needs to emit values with a proper unit: either "cm" (the only possibility now) or "%".
(In reply to David Tardon from comment #16) > This shouldn't be hard to do. The relevant information is already parsed, it > just isn't used... > > Some high-level info about LWP import code: The code resides in > lotuswordpro. Parsing is two-step, with ODF as an intermediate format, i.e., > the parser reads a LWP document, produces an (internal) ODF document, which > is then imported. The parser itself is in lotuswordpro/source/filter. In > general, each concept of the file format is represented by a separate class, > with names starting with Lwp. ODF export is in > lotuswordpro/source/filter/xfilter. In general, there is a class for each > ODF element, but there are some that just group together a bunch of related > arguments (e.g., XFMargins). Class names start with XF or IXF. The > construction of the ODF is done in ToXml() functions. > > Now to the task at hand: LwpParaStyle::ApplySpacing() needs to handle > LwpSpacingCommonOverride::SPACING_DYNAMIC (and possibly also > SPACING_LEADING) for abovepara and belowpara. Then the additional info that > the margin size is relative (percentual) needs to be passed through > XFParaStyle::SetMargins() down to XFMargins (Maybe change the SetMargins() > arguments to std::variant? That would also remove the need for a special > value meaning "not set".). Finally, XFMargins::ToXml needs to emit values > with a proper unit: either "cm" (the only possibility now) or "%". I'm quite new, so, apologies in advance if it's an obvious answer, but, Is there a way to view the ODF that's created internally?
(In reply to adityapratapsingh51 from comment #17) > I'm quite new, so, apologies in advance if it's an obvious answer, but, Is > there a way to view the ODF that's created internally? There is not, unfortunately... I should have a patch that adds it around somewhere, but IIRC it didn't really work (it caused a segfault or something like that) and I didn't want to spend time debugging it. But if you're interested in working on LWP import, I can give it another chance :-) Btw, I was wrong when I wrote the filter produces ODF: it's actually StarOffice XML (which was the basis of ODF, so it's looks very similar).
(In reply to adityapratapsingh51 from comment #17) > I'm quite new, so, apologies in advance if it's an obvious answer, but, Is > there a way to view the ODF that's created internally? There is a way now: https://git.libreoffice.org/core/+/301b09f0c4fef6fca52fa0b28827a657bbbb6b39%5E%21
(In reply to David Tardon from comment #19) > (In reply to adityapratapsingh51 from comment #17) > > I'm quite new, so, apologies in advance if it's an obvious answer, but, Is > > there a way to view the ODF that's created internally? > > There is a way now: > https://git.libreoffice.org/core/+/ > 301b09f0c4fef6fca52fa0b28827a657bbbb6b39%5E%21 FYI, Aditya
(In reply to David Tardon from comment #16) > This shouldn't be hard to do. The relevant information is already parsed, it > just isn't used... > > Some high-level info about LWP import code: The code resides in > lotuswordpro. Parsing is two-step, with ODF as an intermediate format, i.e., > the parser reads a LWP document, produces an (internal) ODF document, which > is then imported. The parser itself is in lotuswordpro/source/filter. In > general, each concept of the file format is represented by a separate class, > with names starting with Lwp. ODF export is in > lotuswordpro/source/filter/xfilter. In general, there is a class for each > ODF element, but there are some that just group together a bunch of related > arguments (e.g., XFMargins). Class names start with XF or IXF. The > construction of the ODF is done in ToXml() functions. > > Now to the task at hand: LwpParaStyle::ApplySpacing() needs to handle > LwpSpacingCommonOverride::SPACING_DYNAMIC (and possibly also > SPACING_LEADING) for abovepara and belowpara. Then the additional info that > the margin size is relative (percentual) needs to be passed through > XFParaStyle::SetMargins() down to XFMargins (Maybe change the SetMargins() > arguments to std::variant? That would also remove the need for a special > value meaning "not set".). Finally, XFMargins::ToXml needs to emit values > with a proper unit: either "cm" (the only possibility now) or "%". This may be more complicated than just doing the changes listed here. I made some changes and ran into the following warning: warn:sw.core:34192:36628:sw/source/core/unocore/unostyle.cxx:3632: SwXAutoStyleFamily::insertStyle: Unknown property: ParaBottomMarginRelative This suggests that there is other code that needs to be changed to make percentages work. I'm not sure how to proceed from here.
(In reply to David Tardon from comment #19) > (In reply to adityapratapsingh51 from comment #17) > > I'm quite new, so, apologies in advance if it's an obvious answer, but, Is > > there a way to view the ODF that's created internally? > > There is a way now: > https://git.libreoffice.org/core/+/ > 301b09f0c4fef6fca52fa0b28827a657bbbb6b39%5E%21 Setting DBG_LWPIMPORT_DIR when you are trying to run the import tests through make check seems to make the tests fail, so this environment variable needs to be blank when you run tests.
(In reply to Dhiraj Holden from comment #22) > (In reply to David Tardon from comment #19) > > (In reply to adityapratapsingh51 from comment #17) > > > I'm quite new, so, apologies in advance if it's an obvious answer, but, Is > > > there a way to view the ODF that's created internally? > > > > There is a way now: > > https://git.libreoffice.org/core/+/ > > 301b09f0c4fef6fca52fa0b28827a657bbbb6b39%5E%21 > > Setting DBG_LWPIMPORT_DIR when you are trying to run the import tests > through make check seems to make the tests fail, so this environment > variable needs to be blank when you run tests. This was because I had DBG_LWPIMPORT_DIR set to a Windows path because of Visual Studio.
Re-evaluating the EasyHack in 2022 This bug is still relevant, but I don't consider it an EasyHack that should be suggested to the newcomers. The original application (Lotus Word Pro 97) is very old. Although it can be found on some archive websites, and it works fine using Wine, I think there are more important areas that a newcomer should focus on to get familiar with the LibreOffice code. Therefore, I remove the EasyHack keyword from this issue. On the other hand, this is still a bug and should be fixed. This was one the oldest open EasyHacks.
Dear Jaxson Lee, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug