Bug 33713 - FORMATTING, FILEOPEN: Spacing above and below paragraph (.lwp)
Summary: FORMATTING, FILEOPEN: Spacing above and below paragraph (.lwp)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: reviewed:2022
Keywords:
Depends on:
Blocks: LWP
  Show dependency treegraph
 
Reported: 2011-01-30 04:16 UTC by Jaxson Lee
Modified: 2022-08-13 10:25 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
.lwp '97 format document containing examples of paragraph spacing (23.11 KB, application/vnd.lotus-wordpro)
2011-01-30 04:16 UTC, Jaxson Lee
Details
PDF showing Lotus Word Pro '97 and LibreOffice Writer 3.3 handling of sample document (222.66 KB, application/pdf)
2011-01-30 04:17 UTC, Jaxson Lee
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaxson Lee 2011-01-30 04:16:37 UTC
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.
Comment 1 Jaxson Lee 2011-01-30 04:17:34 UTC
Created attachment 42716 [details]
PDF showing  Lotus Word Pro '97 and LibreOffice Writer 3.3 handling of sample document
Comment 2 Björn Michaelsen 2011-12-23 11:49:34 UTC Comment hidden (obsolete)
Comment 3 Florian Reisinger 2012-08-14 14:02:05 UTC Comment hidden (obsolete)
Comment 4 Florian Reisinger 2012-08-14 14:03:06 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 14:07:40 UTC Comment hidden (obsolete)
Comment 6 Florian Reisinger 2012-08-14 14:09:46 UTC Comment hidden (obsolete)
Comment 7 sasha.libreoffice 2012-08-24 05:48:45 UTC
Nobody tested yet. Changing to Unconfirmed
Comment 8 Jaxson Lee 2012-08-27 12:22:08 UTC
Paragraph spacing still doesn't happen in Writer 3.6
Comment 9 Owen Genat (retired) 2014-07-26 10:32:45 UTC
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.
Comment 10 QA Administrators 2015-09-04 02:48:15 UTC Comment hidden (obsolete)
Comment 11 Buovjaga 2015-11-18 11:59:42 UTC
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)
Comment 12 roderich_mattmueller 2016-10-04 16:03:19 UTC Comment hidden (spam)
Comment 13 QA Administrators 2018-09-25 02:51:06 UTC Comment hidden (obsolete)
Comment 14 Christian Pietzsch 2018-10-07 14:59:34 UTC
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
Comment 15 QA Administrators 2019-10-08 02:28:21 UTC Comment hidden (obsolete)
Comment 16 David Tardon 2020-06-14 15:04:40 UTC
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 "%".
Comment 17 adityapratapsingh51 2021-02-02 16:51:38 UTC
(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?
Comment 18 David Tardon 2021-02-04 16:14:47 UTC
(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).
Comment 19 David Tardon 2021-02-21 15:27:39 UTC
(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
Comment 20 Buovjaga 2021-02-21 16:27:11 UTC
(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
Comment 21 Dhiraj Holden 2021-12-27 12:13:21 UTC
(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.
Comment 22 Dhiraj Holden 2022-01-03 14:17:45 UTC Comment hidden (obsolete)
Comment 23 Dhiraj Holden 2022-01-12 13:31:34 UTC
(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.
Comment 24 Hossein 2022-08-13 10:25:38 UTC
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.