Created attachment 165746 [details] Can't see last font name Last font name in font list cannot be read. See attached image for more info. Version: 7.0.1.2 Build ID: 00(Build:2) CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US =7.0.1-1 Calc: threaded Operating System: Manjaro Linux KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.73.0 Qt Version: 5.15.0 Kernel Version: 5.4.64-1-MANJARO OS Type: 64-bit
I confirm it with standard toolbar and Version: 7.0.1.2 (x64) Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded on my notebook display. Haven't tested with external screen, but I assume, that height increased in comparison with earlier versions of LO.
Created attachment 165779 [details] Screenshot that shows the problem
Let's treat it as duplicate of bug 91130. Medmedin, feel free to change it back to NEW with a short reasoning, if you disagree. *** This bug has been marked as a duplicate of bug 91130 ***
(In reply to Dieter from comment #3) > Let's treat it as duplicate of bug 91130. Medmedin, feel free to change it > back to NEW with a short reasoning, if you disagree. > > *** This bug has been marked as a duplicate of bug 91130 *** The item 91130 is just an enhancement to modify the whole list view for better usability, but this bug is regression because the combobox is there and what should be fixed is just its height to fit inside screen and using the scrollbar thumb user can reach any item in the list.
(In reply to medmedin2014 from comment #4) > but this bug is regression because the combobox is there > and what should be fixed is just its height to fit inside screen and using > the scrollbar thumb user can reach any item in the list. If you think it is a regression, please add information of (probalbly) the last version without that bug.
(In reply to Dieter from comment #5) > (In reply to medmedin2014 from comment #4) > > but this bug is regression because the combobox is there > > and what should be fixed is just its height to fit inside screen and using > > the scrollbar thumb user can reach any item in the list. > > If you think it is a regression, please add information of (probalbly) the > last version without that bug. It's totally a regression, I can't point from which version this bug started to appear but if you take any old version like 6.4.2.2 you can clearly see how it looked.
Created attachment 179387 [details] List of fonts in LibreOffice 6.4.2.2
Dear medmedin2014, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
On MacOS Sonoma 14.1.2, I was unable to reproduce the bug in the following two builds: Stable Build Version: 24.2.2.2 (AARCH64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Master/Daily Build Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: c4023d3ec604abfff38be2053e2989c7ec2ba8c1 CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded I tried using older LibreOffice versions but they're crashing on my MacBook Pro. Can anyone else please test this bug on Windows and/or Linux and verify if it was present in version 7.0.1.2. Thank you.
Since it was verified that it was present in version 7.0.1.2, I'll change the status to RESOLVED WORKSFORME.
It's still reproducible on X11. But not persistent on Wayland. Operating System: Manjaro Linux KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.7.0 Kernel Version: 6.8.5-1-MANJARO (64-bit) Graphics Platform: X11 LibreOffice: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 2; OS: Linux 6.8; UI render: default; VCL: kf6 (cairo+wayland) Locale: en-US (en_US.UTF-8); UI: en-US 24.2.2-2 Calc: threaded
Bibisected with win64-7.0. The first observable change was with 16309a9516c1f173056fc103c6428e74217c7927 weld StylesPropertyPanel which made the height larger, but placed the box higher, so we could actually see all the items. We arrived at the current state with 822f94e260b8351dc3459d2c05180af2de96d4c7 tdf#132435 only place menu vertically if up/down requested It is indeed fine when I test on Linux with kf6 and gtk3 on Wayland.