Bug 47924 - FORMATTING: Paragraph alignment "right" lost in TABLE to text conversion
Summary: FORMATTING: Paragraph alignment "right" lost in TABLE to text conversion
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium minor
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Blocks: Paragraph-Alignment Writer-Tables-Alignment
  Show dependency treegraph
Reported: 2012-03-26 13:12 UTC by Serhiy
Modified: 2022-12-31 07:10 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Example document with the bug (12.07 KB, application/vnd.oasis.opendocument.text)
2012-03-27 07:07 UTC, Serhiy

Note You need to log in before you can comment on or make changes to this bug.
Description Serhiy 2012-03-26 13:12:43 UTC
Problem description: 
When I convert table to text using menu Table - Convert - Table to text (with paragraph as separator), then paragraph alignment is lost, while other formatting like indents and spacing is preserved. 
When you convert text to table using the same options, paragraph alignment is preserved in the table, but when you convert it back to text, you will get all paragraphs left aligned.

Steps to reproduce:
1. Create Writer document
2. Put few paragraphs of text
3. Select all the text
4. Choose menu Table - Convert - Text to Table (with paragraph as separator) and press OK
5. Make some paragraphs in the table aligned left, some right, some centered and some justified.
6. Choose menu Table - Convert - Table to text (with paragraph as separator)and press OK

Current behavior:
The whole text you will get will have left alignment. Other formatting, like fonts, indents and spacing will be preserved.

Expected behavior:
The paragraph alignment should be preserved in Table-to Text conversion with paragraph as separator.

Platform (if different from the browser): 
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.83 Safari/535.11
Comment 1 Rainer Bielefeld Retired 2012-03-26 21:27:07 UTC
I did a quick test and was not able to reproduce the problem with "LibreOffice German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit); may be I misunderstood the report.

Thank you for your report – unfortunately important information is missing.
May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? If you believe that that  is really sophisticated please as for Help on a user mailing list
- Write a meaningful Summary describing exactly what the problem is
- Attach a sample document (not only screenshot). I helps If you copy / paste
  results of each steps to a new page and proceed the next step on that new
- Attach screenshots with comments if you believe that that might explain the 
  problem better than a text comment. Best way is to insert your screenshots
  into a DRAW document and to add comments that explain what you want to show
- Contribute a step by step instruction related to the sample document 
  containing every key press and every mouse click how to reproduce your 
  problem (due to example in Bug 43431)
– if possible contribute an instruction how to create a sample document 
  from the scratch
- add information 
  -- what EXACTLY is unexpected
  -- and WHY do you believe it's unexpected (cite Help or Documentation!)
  -- concerning your OS (Version, Distribution, Language)
  -- concerning your LibO version and localization (UI language, Locale setting)
  –- Libo settings that might be related to your problems 
  -- how you launch LibO and how you opened the sample document
  –- If you can contribute an OOo Issue that might be useful
  -- everything else crossing your mind after you read linked texts

Even  if you can not provide all demanded information, every little new information might bring the breakthrough.
Comment 2 Serhiy 2012-03-27 07:07:39 UTC
Created attachment 59111 [details]
Example document with the bug

In this document first we have the table with the text inside, aligned to the right.

Then in second case we have the text, got by the conversion Table > Convert > Text to Table (Separate text at: paragraph). Right alignment of the paragraphs  isn't kept as expected. The alignment of those paragraphs became left.
Comment 3 Rainer Bielefeld Retired 2013-04-05 17:36:09 UTC
[Reproducible] with reporter's sample document "LibreOffice rc " German UI/ German Locale [Build-ID: f969faf] {pull date 2013-04-03} on German WIN7 Home Premium (64bit).

I found a similar problem for TAB type "right" (others not tested) at opposite direction, Alignment in cell will kept for Table -> Text (becomes Tab type "right"), but lost for Text -> Table. I will submit a separate bug for that.

That never worked correctly in LibO / OOo at least back until 1.1.5., and also Symphony and OOo 4 fail.

But SoftMaker FreeOffice does a perfect job with my enhanced test document I created based on reporter's.

Not a big thing, but if SoftMaker can do that ...

Please change  Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf
Comment 4 Rainer Bielefeld Retired 2013-04-05 17:49:08 UTC
The possibly related tab problem: "Bug 63185 - EDITING TABLE: FORMATTING alignment "right" in cell lost in Text to TABLE conversion"
Comment 5 Rainer Bielefeld Retired 2013-04-05 17:51:04 UTC
Only for the sake of completeness: Still reporducible with Version (Build ID: 049ce78144650d92eb6bd73292868f73d37c901)
TinderBox: Win-x86@6, Branch:master, Time: 2013-03-29_23:59:42
Comment 6 A (Andy) 2014-09-25 22:03:45 UTC
reproducible with LO (Win 8.1)
Comment 7 QA Administrators 2015-10-14 19:56:45 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2016-11-08 11:13:01 UTC Comment hidden (obsolete)
Comment 9 Serhiy 2016-11-10 18:31:00 UTC
reproducible with LO Version: (Win 10)
Comment 10 QA Administrators 2018-06-17 02:44:42 UTC Comment hidden (obsolete)
Comment 11 Serhiy 2018-06-17 18:20:13 UTC
Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
CPU threads: 4; OS: Windows 6.1; UI render: GL; 
Locale: uk-UA (uk_UA); Calc: CL

The bug is still present
Comment 12 Rainer Bielefeld Retired 2018-06-23 11:47:47 UTC
Still REPRODUCIBLE with Version: 
Build ID: f5f6781acb292783033caea0147ff98490c78d89
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-06-23_00:13:45
Locale: de-DE (de_DE); Calc: CL
Comment 13 QA Administrators 2019-10-03 03:00:39 UTC Comment hidden (obsolete)
Comment 14 Julien Nabet 2020-04-05 09:50:52 UTC
On pc Debian x86-64 with LO Debian package 6.4.2, I don't reproduce this.
Here what I did:
- I created a brand new odt file with 5 paragraphs Lorem Ipsum generated from https://fr.lipsum.com/feed/html.
- I copied pasted it on gedit (to be sure not to have extra format from website).
- I put some paragraphs 2 at left, 1 at center, 1 at right and 1 justified
- I selected Menu Table, Convert to table
=> everything seems ok.
Perhaps I missed something?
Could you give a try to 6.3.5 or brand new 6.4.2?
Comment 15 QA Administrators 2020-10-03 03:52:25 UTC Comment hidden (obsolete)
Comment 16 Serhiy 2020-10-07 04:37:37 UTC
Linux the bug is still present.

The formatting is lost not when you convert from text to table, but when you convert from table to text.
Comment 17 dash 2020-10-27 08:40:36 UTC
I've tested and it seems that in general the alignment is not being kept with the Table to Text function

short test:
1. Create table with 4 rows single column
2. make each row in different alignment
3. It will return to be aligned to the right
Comment 18 raal 2020-12-30 00:41:35 UTC
repro Version:
Build ID: 2577d9ecea199ca2c10d852cf279053a1b22faf7
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded
Comment 19 Julien Nabet 2020-12-30 10:10:24 UTC
On pc Debian x86-64 with master sources updated today, I confirm I could reproduce this.
Right and Center alignment aren't kept.
Comment 20 QA Administrators 2022-12-31 03:19:40 UTC
Dear Serhiy,

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