Created attachment 193472 [details] Frame showing the styles after having upgraded Writer After upgrading from LibreOffice 7.5.9 to 7.6.6 I immediately noticed two incompatibilities (regressions): 1) The selector for the styles (like "All styles", "Used styles", etc.) was almost unreadable due to a scrollbar issue. The issue vanished when horizontally resizing the frame (making it wider), and it could not be reproduced when making the frame more narrow again. 2) The guide showing the text area does not appear any more, and I found no setting to make it appear.
Created attachment 193473 [details] Frame showing the styles after having resized it
Created attachment 193474 [details] Screenshot showing the lack of guides for text area (table) When inserting a table the lack of guidelines for the text area is most obvious!
You can see the guides for text area in attachment #193469 [details].
Thanks for the report. Please note that we try to only have one issue per report, so it is more likely it will get actioned. (In reply to Ulrich Windl from comment #0) > 1) The selector for the styles (like "All styles", "Used styles", etc.) was > almost unreadable due to a scrollbar issue. The issue vanished when > horizontally resizing the frame (making it wider), and it could not be > reproduced when making the frame more narrow again. This is already tracked in bug 145698. > 2) The guide showing the text area does not appear any more, and I found no > setting to make it appear. I tested in 7.6.6 and could not reproduce. I tested inserting a table with borders (via the toolbar, shows the borders) and without (via Table > Insert table, shows the cell boundaries). Version: 7.6.6.3 (X86_64) / LibreOffice Community Build ID: d97b2716a9a4a2ce1391dee1765565ea469b0ae7 CPU threads: 4; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Visibility of table borders and boundaries depend on a few settings: - display of tables with Tools > Options > LibreOffice Writer > View > Display > Tables (on by default) - automatic borders when table inserted via toolbar widget with Tools > Options > LibreOffice Writer > Table > New Table Defaults (on by default) - when the table has no border (for example when inserting one with Table > Insert Table), display (and colour) of boundaries controlled by Tools > Options > LibreOffice > Application Colors > General Table Boundaries (on by default) Can you please: - test in safe mode / with a new profile (after backing it up if you don't want to lose your settings): https://wiki.documentfoundation.org/UserProfile - paste here the full version information copied from Help > About LibreOffice - check the settings I listed above - give precise steps to reproduce the issue with the table Thank you!
(In reply to Stéphane Guillou (stragu) from comment #4) Version I have: Version: 7.6.6.3 (x86) / LibreOffice Community Build ID: d97b2716a9a4a2ce1391dee1765565ea469b0ae7 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded You might have mis-understood, or I did not express very well (occasionally I don't know the correct phrases in English): I'm NOT talking about table borders that would be visible when printing, but I refer to "input aids" showing the page's text boundary (and also boundaries for table cells). Assuming the feature still exists, I must assume that either the setting was lost during upgrade, or the setting isn't interpreted correctly. Maybe it's a setting like this (my wild guess): <item oor:path="/org.openoffice.Office.Writer/Layout/Line"><prop oor:name="Guide" oor:op="fuse"><value>true</value></prop></item> Regarding the instructions in https://wiki.documentfoundation.org/UserProfile: I have no program named libreoffice, but I have soffice.exe in C:\Program Files\LibreOffice 5\program. Also soffice does not know about the "--safe-mode" option. So I renamed the "Libreoffice" directory to "remove" the profile temporarily. When I pressed the "paragraph button" (Ctrl+F10), the guide lines appeared (replacing the crosshair-like markings at the page's edges). However when I switch back to my saved profile, I see neither: No crosshair-like corner markings and not grey lines, and pressing the "paragraph button" changes nothing. So I think there's a bug.
(In reply to Ulrich Windl from comment #5) > I'm NOT talking about table borders that would be visible when printing, but > I refer to "input aids" showing the page's text boundary (and also > boundaries for table cells). > [...] > When I pressed the "paragraph button" (Ctrl+F10) [...] Ah, thanks for clarifying. So there's at least two things that you are referring to: - the "Table Boundaries" I mention in my comment 4 (unrelated to borders) - the full margin guides that are shown when activating the "Formatting Aids" (that's the name in English) with Ctrl + F10. > So I renamed the "Libreoffice" directory to "remove" the profile temporarily. > When I pressed the "paragraph button" (Ctrl+F10), the guide lines appeared > (replacing the crosshair-like markings at the page's edges). So there's an issue in how your profile is reused when moving to 7.6. Without access to the profile, this can be tricky to investigate. But the profile does contain personal information, so wouldn't recommend sharing in full. Please do check what the table boundary setting looks like in LO 7.6: Tools > Options > LibreOffice > Application Colors > General > Table Boundaries Can you consider using a fresh profile? And possibly, when customising again, you might find out which setting makes the issue reappear. Alternatively, you could try bibisecting the issue: https://bibisect.libreoffice.org/
Created attachment 193522 [details] Screenshot showing options Eventually I found the problem (see screenshot): The "Schema" for user-defined colors was blank; when I opened the pull-down list, there was only one choice available: "Automatic" As soon as I had selected that, the missing lines re-appeared. Of course such incompatibility is undesirable, and programmers should try to find out what went wrong.
(In reply to Stéphane Guillou (stragu) from comment #6) > Can you consider using a fresh profile? And possibly, when customising > again, you might find out which setting makes the issue reappear. My personal opinion: The difference between professional software and the rest is that you can upgrade professional software without having to re-install. Software you'll have to re-install frequently isn't worth using it.
(In reply to Ulrich Windl from comment #7) > Eventually I found the problem (see screenshot): > The "Schema" for user-defined colors was blank Great, we've now pinpointed the issue! So, in summary, it's: "Upgrade from 7.5 to 7.6+ does not map Application Colors scheme properly when profile kept" Steps to reproduce: 1. In LO 7.5, choose the "LibreOffice Dark" scheme in Tools > Options > LibreOffice > Application Colors > Color Scheme > Scheme 2. Exit, go to user profile directory, copy registrymodifications.xcu across to the user profile of a 7.6 installation 3. Open Writer 7.6 4. Insert table with Table > Insert table > OK Results: - no margin crosshairs - no table boundaries - Ctrl + F10: no margin lines - go to Tools > Options > LibreOffice > Application Colors > Custom Colors > Scheme: empty selection, and all optional elements in the list are ticker off. Same happens if going from 7.5 to 24.2. Note that this does not happen with a custom named scheme. Heiko, I assume this started with 5675937f7564fa5614f7be5aec0d7f20ba91d02c. Can we fix the mapping from: "Scheme = LibreOffice Dark" to: "Scheme = Automatic" + "Automatic = Dark" somehow ?
(In reply to Stéphane Guillou (stragu) from comment #9) > Can we fix the mapping from: > "Scheme = LibreOffice Dark" > to: > "Scheme = Automatic" + "Automatic = Dark" > somehow ? The first solution for a dark mode was an additional color scheme, which now became an internal set of automatic colors. We map in cui/source/options/optcolor.cxx COLOR_SCHEME_LIBREOFFICE_AUTOMATIC to the localization of "Automatic". Some special mapping of "if lastversion() == 7.5 and colorscheme == "LO Dark" then..." sounds wrong to me. I would rather deal with the messed-up registry and apply the default if a name is not found. Should not happen and we may also just accept the temporary hick-up for my mistake. Sorry for this.