Description: When i set named range and use it into calculation, every interaction with that sheet become very slow (scrolling, opening sheet) Steps to Reproduce: 1.Make new spreadsheet 2.Put some number like 9,5 into cell a1 3.Set name for this cell like "some_named_cell" 4.Add sheet to that spreadsheet 5. Set some number like 100 into a1 6. Set formula =a1*some_named_cell into B1 7. Try to scroll page and open system monitor to view than libreoffice takes 100% cpu while interacting with Actual Results: Lags and slowdowns each time i open sheet with formula that includes named range Expected Results: Smooth and fast working (scrolling, sheet switching) Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Версия: 6.4.0.3 ID сборки: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8 Потоков ЦП: 4; ОС: Mac OS X 10.13.6; Отрисовка ИП: по умолчанию; VCL: osx; Локаль: ru-RU (ru_RU.UTF-8); Язык интерфейса: ru-RU Calc: threaded
I was fonund, that slowdown appears not by using named range, but when using currentcy formatting containing symbol "₽" (russian currency) Steps to Reproduce: 1.Make new spreadsheet 2.Put some number like 9,5 into cell a1 3. Apply currency format containing "₽" symbol for that cell Actual Results: Lags and slowdowns each time when cell with "₽" symbol appears on screen Expected Results: Smooth and fast working (scrolling, sheet switching)
This is a very wild guess, but I've heard similar lag issues with scrolling in Calc and Writer from the Chinese user community, and they are font related. Would you please have a look at your default font of your Calc, and check it indeed has the glyph of the "₽" symbol? Also try changing the default font (the default cell style, I believe) and see if it helps getting a smooth scrolling.
My default font is "Liberation Sans" and each time, when I use RUB symbol ("₽"), calc becomes very slow. I have some different fonts and has same effect on "Arial", "Tahoma", "TimesNewRoman". Each of this fonts have not "₽" symbol. When i switch to "PT sans" font (that contains "₽" symbol) all became ok - smooth scroll and no lags. So, the reason is that some fonts do not have symbol "₽". I think that is problem, because after 6.3 update the default Russian currency format not contains "₽" symbol. In 6.2 versions, the default format was "xxx р.".
I think that is problem, because after 6.3 update the default Russian currency format NOW contains "₽" symbol. In 6.2 versions, the default format was "xxx р.". - misprint
On 2014-05-30 a user is mentioning PT Serif, is this bug report has something to do with this? https://mobile.twitter.com/ceripher/status/472339037236109313 * Honestly speaking, I don't understand well about twitter, and don't know an easy way to find tweets just before this one to check whether the problem the tweeter has is actually the performance issue.
(In reply to himajin100000 from comment #5) > On 2014-05-30 a user is mentioning PT Serif, is this bug report has > something to do with this? > Oops, typo. is => does, has=> have
I can't confirm. Can you upload a sample document that exhibits the issue? Version: 7.0.0.0.alpha0+ Build ID: 0cb4f304abf6f8dd6b40eb800788d2fe80581813 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
(In reply to eisa01 from comment #7) > I can't confirm. Can you upload a sample document that exhibits the issue? It really doesn't need a sample document, for people affected by this, just filling your worksheet with the currency symbol will trigger it (or in cases I heard about, any Chinese text). From my (far from comprehensive or clear) understanding, this bug depends on the default fallback order of the fonts on the user's system, font rendering options (openGL? antialiasing?), and perhaps the final font that contains the problematic glyph in the fallback font list. All these make it super tricky to reproduce.
Dear koledennix, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear koledennix, 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