Bug 46917 - FORMATTING: Inserted 'Tables' in presentation respond poorly for configuration changes
Summary: FORMATTING: Inserted 'Tables' in presentation respond poorly for configuratio...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.3.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 75684 (view as bug list)
Depends on:
Blocks: ImpressDraw-Tables
  Show dependency treegraph
 
Reported: 2012-03-02 21:00 UTC by pharmankur
Modified: 2022-09-30 07:59 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Presentation showing common issues with Table in Impress (1.08 MB, application/vnd.oasis.opendocument.presentation)
2014-08-20 07:53 UTC, pharmankur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pharmankur 2012-03-02 21:00:38 UTC
Problem description & Steps to reproduce :

When we insert & try to edit 'Table' in presentation, in general it responds poorly to the edits. [like colour formatting, font changes in the table text, colour & thickness changes of table borders etc.)

i.e. even when I select config (e.g. say - font Arial size 32 colour red; table borderline black coloured 1.00 thick ; colour background invisible  etc.) this config do not show up in table instantly.

Many of the times borders of  a table disappears when the presentation is closed & opened again. 

This issue is more serious in Linux / Ubuntu ; but to my surprise, same version (3.5.0) run & respond to table config changes far superior under windows XP.

Current behavior: Config settings changes in table option do not show up effects

Expected behavior: whatever change we make should instantly reflect in selected table

Platform (if different from the browser): Ubuntu 11.10
              
Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Comment 1 sasha.libreoffice 2012-03-23 06:15:29 UTC Comment hidden (obsolete)
Comment 2 pharmankur 2012-03-23 07:17:18 UTC Comment hidden (obsolete)
Comment 3 sasha.libreoffice 2012-03-23 08:58:34 UTC Comment hidden (obsolete)
Comment 4 bfoman (inactive) 2012-08-08 09:49:07 UTC
Confirmed with:
LO 3.5.5.3 
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

Created 6x20 table and every operation like changing text style, align, font size, color, resizing, moving is quite delayed. From x to xx seconds.
Comment 5 sasha.libreoffice 2012-08-08 10:07:50 UTC
Thanks for additional information. Sorry for not understand problem from first attempt.
Indeed table 6x20 is very slow if we try to move it, resize, change "Table design" on right hand pane. But if we input text into table, it updates immediately. 
Reproduced in 3.3.4, 3.5.5, 3.6.0rc on Fedora 64 bit
Changing version to 3.3.4 as most early reproduced
Comment 6 pharmankur 2014-08-20 07:53:31 UTC
Created attachment 104963 [details]
Presentation showing common issues with Table in Impress
Comment 7 pharmankur 2014-08-20 07:55:29 UTC
Also while making this presentation I encountered a issue with 'Vanishing of inserted images' in Impress described as issue no 5 in presentation. 

Rest 4 issues are related to Table properties.
Comment 8 pharmankur 2014-08-20 07:57:09 UTC
created with Libreoffice 4.3.0
Comment 9 Jean-Baptiste Faure 2015-05-07 04:41:07 UTC
*** Bug 75684 has been marked as a duplicate of this bug. ***
Comment 10 QA Administrators 2016-09-20 09:37:21 UTC Comment hidden (obsolete)
Comment 11 pharmankur 2016-09-20 13:19:46 UTC
Dear QA team,

I have tested the issue on Linux Mint 18 (64 bit) with LO version ,
Version: 5.2.1.2
Build ID: 31dd62db80d4e60af04904455ec9c9219178d620
CPU Threads: 4; OS Version: Linux 4.4; UI Render: default;


And my observations are ...

Most of the issues mention in previously enclosed bug report presentation 'SEEM' resolved ... only untill table is small e.g 5 X 3.

But the situation is worse when table grows up in size. I created a table of 20 X 20 & tried to apply possible editing as mentioned in my bug report ... and I found
if you try to change even boarder colour of big table (I tried with 20 X 20), Libreoffice freezes and I have to XKILL it.

No edit is possible on bigger tables. Thus for me the issue / bug prevails.

Hope after this retesting the issue will be at least marked as confirmed & will be assigned to someone.

But thanks anyways for asking me to test, If you want any further assistance I will be glad to help !

Regards,
Ankur Joshi
Comment 12 jose.velez 2017-02-04 06:49:14 UTC
The bug is still present in Impress 5.3.X and 5.2.X

1) Create a 5x5 table.
2) Select first row.
3) Use Right click to go to "Table Property" panel.
4) Change border color
5) Press ok button

There are no changes in the borders of the first row of the table.
Comment 13 QA Administrators 2019-02-02 03:43:47 UTC Comment hidden (obsolete)
Comment 14 pharmankur 2020-09-29 07:11:00 UTC
Issue is not resolved and continued as it was before. Tested with LO 7.0.1
Comment 15 QA Administrators 2022-09-30 03:53:27 UTC Comment hidden (obsolete)
Comment 16 pharmankur 2022-09-30 04:50:26 UTC
Dear QA team,
Thanks for reporting.

I have ,
1) Tried with the test file attached already in this bug report. --- All issues were resolved.

2) Created large tables like 20 X 20 and tried to edit line colors, text fonts alignments and background colors etc. --- I found it becomes little slow and takes some time to respond, but finally it works and does the edits as desired. 

Tested with my version of LO --
Version: 7.3.6.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-IN (en_IN); UI: en-GB
Ubuntu package version: 1:7.3.6~rc2-0ubuntu0.20.04.1~lo1
Calc: threaded


Also as requested, wanted to select status RESOLVED-WORKSFORME, but did not find this option in status dropdown ( It has only RESOLVED ). So leaving it untouched.
Comment 17 Timur 2022-09-30 07:59:45 UTC
pharmankur, thanks for nice sample and retest. 
Normally one needs to report separately table and images, though, after searching in existing bugs. 
When you mark Resolved, next field has WFM (indicating we don't know the exact fix commit, unlike with Fixed).