Issue 37705 - RTF table import results in wrong table layout
Summary: RTF table import results in wrong table layout
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: open-import (show other issues)
Version: 680m62
Hardware: All All
: P3 Trivial with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: oooqa
Depends on:
Blocks:
 
Reported: 2004-11-23 14:47 UTC by flr
Modified: 2017-05-20 11:19 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description flr 2004-11-23 14:47:39 UTC
When importing RTF tables the resulting table layout is wrong, in a way, that a)
spacing information are not preserved and b) border rules are no preserved. Some
of the phenomena also appear when importing tables from .doc files.

Consider for example the following RTF document. On import the cells 4 and 5 get
the wrong size and cell 6 disappears. Additionally the border rules are also not
properly imported.
{\rtf1
  {\pard RTF Table Sample\par}
  {\pard
 
\trowd\trgaph300\trleft400\clbrdrr\brdrth\clbrdrl\brdrth\clbrdrt\brdrth\clbrdrb\brdrth\cellx1500\cellx3000\clbrdrr\brdrth\clbrdrl\brdrth\clbrdrt\brdrth\clbrdrb\brdrth\cellx4500
  \pard\intbl 1. All work and no play makes jack a dump guy... \cell
  \pard\intbl 2. All work and no play makes jack a dump guy... \cell
  \pard\intbl 3. All work and no play makes jack a dump guy... \cell
  \row
 
\trowd\clbrdrl\brdrth\clbrdrr\brdrth\trgaph300\trleft400\cellx1500\cellx3000\clbrdrr\brdrth\clbrdrl\brdrth\clbrdrt\brdrth\clbrdrb\brdrth\cellx4500
  \pard\intbl 4. All work and no play makes jack a dump guy... \cell
  \pard\intbl 5. All work and no play makes jack a dump guy... \cell
  \pard\intbl 6. All work and no play makes jack a dump guy... \cell
  \row
 
\trowd\trbrdrt\brdrth\trbrdrb\brdrth\trbrdrl\brdrth\trbrdrr\brdrth\trgaph300\trleft400\cellx1500\cellx3500
  \pard\intbl 7. All work and no play makes jack a dump guy... \cell
  \pard\intbl 8. All work and no play makes jack a dump guy... \cell
  \row
  }
  {\pard I'M A PARAGRAPH}
}
Comment 1 flr 2004-11-23 15:03:25 UTC
The bug splits up into the following sub-problems:
a) leading SPACES confuse the import filter
b) border rules are not handled properly
Comment 2 flibby05 2004-12-22 21:21:42 UTC
set to NEW to have a qualified developer instead of a ordinary skilled volunteer
look at this
Comment 3 flr 2004-12-23 16:09:27 UTC
flr->maxweber: What do you means with "ordinary skilled volunteer"? 
Comment 4 flr 2004-12-23 16:18:04 UTC
The problem with this bug is, that the SwRTFParser::InsertText method checks via
the SwRTFParser::CheckInsNewTblLine function whether to add a new table line or
not. Because there appear spaces preceeding the \row statements the
SwRTFParser::InsertText method adds a new table cell by mistake. This causes the
misbehaviour. When you uncomment the call to the SwRTFParser::CheckInsNewTblLine
function everything is fine.
By now I have not yet figured out, how this problem could be solved without
major changes in the state engine of the RTF filter.


Comment 5 flibby05 2004-12-23 17:08:24 UTC
maxweber -> flr: >> What do you means with "ordinary skilled volunteer"?

A. This was not referring to you, but to me. my honest apologies for using
ambigious language (i am not english native..).

B. Please let me explain in more detail:
The issue you filed was in Unconfirmed + defect status. Thus it will be listed
when members from QA team will search for it. The QA team of OpenOffice.Org
consists - as far as I know - completely or mainly of volunteer users. They are
not professional developers, but still can help in development, because - as
they have full privileges to change issues to "invalid" or "worksforme" - they
act as sort of prefilter to guarantee that professional developers will not
waste their time by looking at defects, because nobody else then the original
reporter could reprocude them and maybe the reporter did not find a bug, but was
using the software incorrectly.

I am member of QA team of OpenOffice.Org. I found your issue and set the issue
to NEW, because
1. there was not much to reproduce, as there was f.e. no sample file
2. still the issue was described very clearly
and consequently it appeared to me as a _reasonable_ defect report.

However i had not acted in a "filter" manner, but more in a "well, i guess it's
correct, so i confirm it" manner. In order to reflect this and also communicate
this to the developer, who will work on the issue, i wrote the statement, which
was referring to me.

3. OpenOffice.Org and the whole community appreciates every submission to
Issuezilla. Still all of us are humans and tend to give ambigous statements when
confirming bugs after midnight.. ;-)

Best regards,
Max Weber
Comment 6 andreas.martens 2005-01-07 15:16:09 UTC
Leading spaces may confuse our filter but in real life we don't get such spaces
normally.
Comment 7 Mathias_Bauer 2006-08-30 15:15:36 UTC
reassigning to hbrinkm
Comment 8 Marcus 2017-05-20 11:19:38 UTC
Reset assigne to the default "issues@openoffice.apache.org".