Bug 102149 - Malformed Tables, Missing Borders, and Preferences not being Saved
Summary: Malformed Tables, Missing Borders, and Preferences not being Saved
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer Web (show other bugs)
Version:
(earliest affected)
4.1.5.3 release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-13 08:17 UTC by UberGeek
Modified: 2018-04-04 13:26 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Comparisons of two tables with sequential steps and observations (3.29 KB, text/html)
2016-09-13 09:11 UTC, UberGeek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description UberGeek 2016-09-13 08:17:52 UTC
Overview:I've used OO/LO Web for years to create html documents on a daily basis. One of the most important functions is the creation of visible tables which I use to organize topics and technical details. Approximately 2 years ago (~LO 4.1)this function became problematic and in my case, has remained broken ever since. This is despite a series of profile purges, config changes, clean installs, and updates.

This looks like a remnant of Bug 76195 or its variants which ultimately fixed my broken versions of Writer after ~ 4.2.4, but subsequently seemed to do little for LO Writer/Web.

Steps to Reproduce:(using LO 5.1.5):
Preview the Table Menu dropdown and confirm “Table Boundaries” is checked (it always is - default)
a) Set Table Boundary preferences in Tools>Options>LibreOffice>Application Colors from Default (Automatic – Gray) to Black (better visibility)
b) Open a LO Writer/Web document.
c) Click in an empty space and from Table Menu select “Insert Table” (In my example I chose 2 Columns & 2 Rows)
d) When table is inserted it appears as 4 horizontal lines (no vertical lines that define a normal table)
e) Highlight table, Right-click and select “Table Properties” from the context menu.
f) Under the heading “Line Arrangement”, the graphic correctly shows a 4 quadrant table with vertical lines labeled “User Defined”
g) Under the heading “Line”, Width shows .05 pt, and Color shows “Gray 6”, not Black which suggests the value was not saved.
h) Change Width to the next larger size, 2.5 pt and change the Color to Black
Note: the 2.5 pt Line Width is 5 times the .05 pt default and is the only setting required to temporarily render the table correctly.
i) Vertical lines now appear as expected and the table looks normal.
j) Add text, color, formatting, etc to the table. (In my example I randomly chose: 18 pt Bold, centered aligned text with blue background [left upper quad; 15 pt non-bold, left aligned text[left lower quad; cell split into 2 sections, the first containing standard 12 pt text, highlighted in yellow [ right lower quad.
k) Save the document.
l) Later, Open the document and it should incorrectly revert to a table with non-visible/partially visible vertical borders. In the example above, the only visible vertical element is the left border of the left upper quad (with blue background)
m) When the table is highlighted and “Table Properties” selected from the context menu, two errors are immediately apparent:
1. Line Width, the single property which corrected the table above, was again not saved, reverting back its original .05 pt value.
2. The “Line Arrangement” graphic was also not saved, and the 4 quadrant table which previously looked normal, now appears with partially missing vertical AND horizontal elements.

Note: Attempting to fix these anomalies by changing additional preferences will be futile, resulting in a “cat-and-mouse” game that never ends.

NOTE: This behavior does not occur in Writer and provides the workaround below.
* Table appears normally in d) above and in g) the settings are almost identical (see differences below), however, Color correctly shows Black.
* Tables copied from Writer into Web don't suffer malformations and will save correctly after termination of sweb.exe (workaround).

“Table Format” Differences between Writer & Web:
Table > Width 6.93”, Relative Box – Unchecked, Alignment – Automatic (Writer)
Table > Width 100%, Relative Box – Checked, Alignment – Left (Web)
Text Flow “Allow table to split across pages and columns” Box – Checked, “Allow row to break across pages and columns” Box – Checked (Writer) Both variables are missing in Web, other values appear to be identical
Columns appear in “inches” format (Writer) vs “%” format (Web), otherwise identical.
Borders > Spacing to Contents is .04 (all 4 fields) in Writer vs. zero in Web

Tool > Options > Table Differences between Writer & Web:
Do not split Option available in Writer, not in Web
Both Number recognition and Number format recognition boxes are checked in Web, neither are checked in Writer

Subsequent discovery of 2 additional errors:

A. Evidence of improperly saved configurations in the registrymodifications.xcu file:  
Changes in Tools > Options > Writer > Table from “Variable” to “Fixed Proportional” were correctly saved, those in Writer/Web > Table were not. 
Expected Results: Correct toggling of strings from reg <value>2< to reg <value>1< in both programs.
Actual Results: Correct toggling in Writer but not Web, as seen in the following String Values:
<item oor:path="/org.openoffice.Office.WriterWeb/Table/Change"><prop oor:name="Effect" oor:op="fuse"><value>2</value></prop></item>
<item oor:path="/org.openoffice.Office.Writer/Table/Change"><prop oor:name="Effect" oor:op="fuse"><value>1</value></prop></item>

B. Comparisons of html code:
A properly formed table created in writer, was changed to web view and saved, not as the default odt, but as an html file. It opened properly in Writer/Web (sweb.exe) and the table attributes appeared correctly. This same file was later opened in Notepad++ and compared to the Writer/Web doc with the faulty table. This crude example appears to confirm malformed table properties with missing CellPadding, CellSpacing, and border elements seen in html code after the style="border variable as shown below:
Writer/Web html file - <td width="50%" bgcolor="#66ccff" style="background: #66ccff" style="border: none; padding: 0in">
Converted Writer html file - <td width="50%" bgcolor="#66ccff" style="background: #66ccff" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0.04in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in">

I hope this offers ample evidence to help provide an accurate conclusion.
Many Thanks, UG
Comment 1 UberGeek 2016-09-13 09:11:31 UTC
Created attachment 127293 [details]
Comparisons of two tables with sequential steps and observations
Comment 2 pcharalk 2016-12-03 16:51:42 UTC
I managed to reproduce the bug from a-j but after saving the document and re-opening it, it does not return to the previous faulty table.

I am running version 5.2.3.3
Comment 3 Xisco Faulí 2017-08-03 16:17:28 UTC Comment hidden (obsolete)
Comment 4 QA Administrators 2018-03-02 10:00:56 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2018-04-04 13:26:30 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-20180404