Hi Samson,

I can not reproduce with OpenSuse 12.2.

Have you tried to reset the user profile?
https://wiki.documentfoundation.org/UserProfile

Adding Bjoern - maybe Ubuntu only?

It' is (probably) font related (myabe not even a bug). I've solved problem by removing texlive-fonts-{recommended,extra} and rebuilding fonts cache (sudo fc-cache -f -v). Hope it helps, since I' new "with bugs", should this be marked as resolved?

Update: I reinstalled TeXlive font packages and everything seems ok. Possibly, problem was caused by broken font cache.

Sounds good. Ales thanks for testing and updating us with that info.

Setting to Resolved > WORKSFORME as of comment #4.

於 2013年08月10日 星期六 07:04 下午, bugzilla-daemon@freedesktop.org 提到:
>
> *Comment # 3 <https://bugs.freedesktop.org/show_bug.cgi?id=63551#c3> 
> on bug 63551 <https://bugs.freedesktop.org/show_bug.cgi?id=63551> from 
> Ales <mailto:ales.kete@gmail.com> *
> It' is (probably) font related (myabe not even a bug). I've solved problem by
> removing texlive-fonts-{recommended,extra} and rebuilding fonts cache (sudo
> fc-cache -f -v). Hope it helps, since I' new "with bugs", should this be marked
> as resolved?
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You reported the bug.
>

I have followed the mentioned method and no luck for me.

1. I haven't install texlive-fonts-extra but I do have 
texlive-fonts-recommended and I have uninstalled it.
2. No improvement. If there should be any minute improvement, say, 
shorten the waiting time from 8 to 6 seconds before the menu popped up.  
I believe this should come from updating the Libre Office to version 4.1.
3.From your suggestion, fonts might be the ultimate cause of the 
problem. Since I am using Chinese system while Chinese font files size 
are very big comparing to English one, I try uninstalled Chinese fonts 
(total more than 200 fonts in my system), but still no luck. Another 
trial that haven't made is reinstall the whole system and avoid 
installing any texlive-fonts and software laTex. It is only a guess and 
this would take time to do while I am too busy to do it now.
4. The font cache had been rebuilt every time I remove the fonts.




Samson

For reference with:
LibreOffice Version: 4.2.4.2 on Debian Jessie
sudo fc-cache -f -v
did reduce the problem from about 9[s] to 1[s].

So thanks for the info! I wonder if this should be done by some installer to prevent problem to spawn on unaware users...

Thank you for you guy's information and effort to remove this bug. I 
have test it on my system - install 4.2.4 and using fc-cache. The 
situation has been improved a lot but the major problem doesn't disappeared.

What 's been improved
Formerly, not only the pop up of the formatting dialogue is slow (>13s), 
the operation inside the dialogue is also sluggish, e.g. sluggishly 
scrolling downward to find an appropriate date format. This situation go 
away now.

What's not been improved
On the contrary of what you claimed, I still have to wait for around 10s 
for the dialogue to pop up.
In the very beginning, I believed one of the factors caused the 
sluggishness Since I use a lot of traditional Chinese fonts (>100), I 
believed they are related. Chinese fonts are different from English one 
by its size, ranging from 5 to 10M per typeface while english ones are 
measured in K. After I unload all the chinese fonts except those default 
fonts installed by ubuntu , the pop-up time of the dialogue box reduced 
to 3s.
Moreover, I don't have this problem for libreoffice in Windows 7 version 
from the very beginning. Therefore I guessed that the way libreoffice 
linux read in the fonts when pop up the formatting dialogue is the major 
cause.  Large file size for chinese typeface means a lot of loading 
works need to be done. But I have no knowledge for the mechanism  
therefore I get no further comment.
In the mean time, I work around the problem with a new excellent feature 
of libreoffice, the Side Panel. But I am still longing for the removal 
of this bug so that libreoffice should become more perfect.
Finally, I think there are not sufficient asian or chinese open source 
programmers therefore any problem concerning these locales is difficult 
to be solved - I have also reported a problem unsolved until today that 
libredraw messed up  pdf containing chinese or 2 byte characters when 
read in. This will not happen in files contained only english or pictures.
Finally I also apologize for I cannot attend the forum discussion til 
the end for I am engaged in other bussiness.

best regards


Samson

於 2014年06月05日 星期四 05:02 下午, bugzilla-daemon@freedesktop.org 提到:
>
> *Comment # 7 <https://bugs.freedesktop.org/show_bug.cgi?id=63551#c7> 
> on bug 63551 <https://bugs.freedesktop.org/show_bug.cgi?id=63551> from 
> NuageBleu@gmail.com <mailto:NuageBleu@gmail.com> *
> For reference with:
> LibreOffice Version: 4.2.4.2 on Debian Jessie
> sudo fc-cache -f -v
> did reduce the problem from about 9[s] to 1[s].
>
> So thanks for the info! I wonder if this should be done by some installer to
> prevent problem to spawn on unaware users...
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You reported the bug.
>

With the latest version of LibreOffice, the problem is still here. (The last fix is not working any more).

How to reproduce :

1. Create a new LibeOffice Calc document (or open any, in any format)
2. Left-click on any cell.
3. Select "Format Cell..."
4. Wait ~11[s] before the panel appear.

(hardware is fast here : Haswell i7, 16Gb RAM, SSD)

OS: Debian
Version: 4.3.0.4
Build ID: 430m0(Build:4)

How can we track that down?

I afraid I can't seem to reproduce the bug in LibreOffice Calc 4.2.6.3 and in Ubuntu 14.04
It seems to be a bug about the software you have.
Maybe you could update Python?

Not reproducible for me with versions 4.x built at home under Ubuntu 14.04 x86-64.

Which window-manager do you use (Gnome, KDE, XFCE, etc.) ?
Do you have assistive technologies activated for accessibility?

Set status to NEEDINFO. Please set it back to UNCONFIRMED once you have provided requested informations. Thank you for your understanding.

Best regards. JBF

I've just installed a fresh LibreOffice 4.4.2.2 in Windows 7 (64-bit) and I've encountered the same issue - 15 seconds (with a watch in my hand) for the format cells dialog window to appear.

Have you installed on a previous LibreOffice version?
That doesn't remove the user profile.

Please try resetting the user profile.
https://wiki.documentfoundation.org/UserProfile

Works fine for me with 4.4.2.2 on Win7x64

No, this is the 1st time I've installed LibreOffice on this system.
Deleting %appdata%/LibreOffice did not resolve the issue.

However, I think I've narrowed the issue down a little bit. I'm working on a standard account in Windows 7 (it's not wise to be running as root all the time :). If I run LibreOffice as an administrator, the issue is gone.

I suspect that LibreOffice tries to access something which a normal user doesn't have access to and gives up after 15 seconds to display the Format Cell dialog.

I've used ProcessMonitor to capture the events LibreOffice is triggering while clicking on Format Cells and saved them in a .csv format.

Admin (works fine): http://sendfile.pl/pokaz/308118---WXkV.html
User (the issue): http://sendfile.pl/pokaz/308119---CbEb.html

Maybe someone can decipher them.

The cells fomatting dialog takes some time before it appears. Under linux when I run the build on master with dbgutil enabled, I see the following output:

warn:vcl:381:381:vcl/unx/generic/fontmanager/fontconfig.cxx:852: In glyph fallback throwing away the language property of en because the detected script for '0x9f3' is Bengali and that language doesn't make sense. Autodetecting instead.
warn:vcl:381:381:vcl/unx/generic/fontmanager/fontconfig.cxx:852: In glyph fallback throwing away the language property of en because the detected script for '0x9f3' is Bengali and that language doesn't make sense. Autodetecting instead.
warn:svtools.misc:381:381:svtools/source/misc/langtab.cxx:222: Language: 0x7e0 with unknown name, so returning lang-tag of: {en-AG}
warn:svtools.misc:381:381:svtools/source/misc/langtab.cxx:222: Language: 0x7e1 with unknown name, so returning lang-tag of: {en-NG}
warn:svtools.misc:381:381:svtools/source/misc/langtab.cxx:222: Language: 0x7e2 with unknown name, so returning lang-tag of: {en-ZM}
warn:svtools.misc:381:381:svtools/source/misc/langtab.cxx:222: Language: 0x7e3 with unknown name, so returning lang-tag of: {en-DK}
warn:svtools.misc:381:381:svtools/source/misc/langtab.cxx:222: Language: 0x3c09 with unknown name, so returning lang-tag of: {en-HK}
warn:svtools.misc:381:381:svtools/source/misc/langtab.cxx:222: Language: 0x4809 with unknown name, so returning lang-tag of: {en-SG}

Apparently Calc is trying to detect the fonts to be used for the special chars appears in the language list (and the cell format strings) within the "Numbers" tab.

This is not a big issue anyway, but I am putting the above information on the record just for FYI.

Actually there are many duplicate bug reports on this. 

Put back to NEW.

*** Bug 101990 has been marked as a duplicate of this bug. ***

*** Bug 95811 has been marked as a duplicate of this bug. ***

*** Bug 98132 has been marked as a duplicate of this bug. ***

Still not reproducible for me under Linux Ubuntu 16.04 x86-64 with current master and LO 5.4.4.0.0+ both with GTK3 backend.

Best regards. JBF

*** Bug 116162 has been marked as a duplicate of this bug. ***

If I recall well, we had more recent bug with Format Cells load time.
So this should be tested with recent LO vesion 6.2 (if not with master 6.3+).
I set to Needinfo for those in CC to test it. 
I kindly emphasize that testing with older LO is not relevant, except to compare.

Dear Samson Yeung,

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-FollowUp