https://bugs.documentfoundation.org/show_bug.cgi?id=102149
Bug ID: 102149
Summary: Malformed Tables, Missing Borders, and Preferences not
being Saved
Product: LibreOffice
Version: 4.1.5.3 release
Hardware: x86 (IA32)
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer Web
Assignee: [email protected]
Reporter: [email protected]
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
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
