Open a new Writer document with LO 24.2.0.1. Write a word, mark it an go to sidebar. Choose "Styles" → "Character Styles". Choose "No Character Style". Here is the first irritating moment: Why isn't "No Character Style" chosen? What style should be the style for a new entered text content? Now switch to "Applied Styles" at the bottom of the sidebar for styles. No character style is shown. Switch back to "All Styles". No character style seems to be connected to text content. I mostly work with "Applied Styles". It will reduce the styles to the styles I need for this special document. But it shouldn't exclude the default "No Character Styles", because it is in use for most of the text content and I need this for setting back a character style to default. Switching to Paragraph Styles will show the default paragraph style without any problem. This buggy behavior of character style appears under Version: 24.2.0.1 (X86_64) / LibreOffice Community Build ID: b4d45829793cddfe67b58a53f495528c75738d8a CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Won't appear in LO 7.6.4.1 on the same system. So a regression.
Reproducible Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 25276df12abd9d002f7f899900434617b256f745 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
This bug also affects 24.2.0.2 and 24.2.0.3 with Windows 11.
I also miss this function. I tried to bibisect this bug, but I get: Bisecting: 144 revisions left to test after this (roughly 7 steps) [9a513a30acfa0862303c46e83c81da8b1819944e] source c1586ef57b5770f80ef200ab38ff4538c2dfb145 soffice.bin: ../../../../src/cairo-surface.c:930: cairo_surface_reference: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed. soffice.bin: ../../../../src/cairo-surface.c:930: cairo_surface_reference: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed. soffice.bin: ../../../../src/cairo-surface.c:930: cairo_surface_reference: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed. But the document recovery continue forever...
If there is a way to bibisect avoiding this CAIRO assertion, I will be glad to bibisect again.
Seems to be related to Bug 158504. I verified that this issue was also introduced at the same commit: https://git.libreoffice.org/core/+/140079362502408c75ceee67e86d779f61c0ac1b. Not sure if we should keep this open to use as an additional test point once 158504 is fixed...
*** Bug 161254 has been marked as a duplicate of this bug. ***
*** Bug 161529 has been marked as a duplicate of this bug. ***
(In reply to BogdanB from comment #4) > If there is a way to bibisect avoiding this CAIRO assertion, I will be glad > to bibisect again. Please retry with setting "SAL_USE_VCL_PLUGIN=gen" in the environment, which should get you around the CAIRO issue -- although with a very ugly UI.
Hmmm, I cannot reproduce the bibisect in Comment 5. Using a build of 345b214c37d1f645dd0e6e084358f8ca81d9ed66 on Linux, the observations from Comment 1 are already there: Repro steps 1: -> open a new document -> go to styles->char styles (showing all styles) expected behaviour: -> 'no character style' is selected actual behaviour: -> nothing is selected Repro steps 2: -> open a new document -> go to styles->char styles (showing applied styles) expected behaviour: -> 'no character style' is selected actual behaviour: -> nothing is displayed
(In reply to Björn Michaelsen from comment #9) > Hmmm, I cannot reproduce the bibisect in Comment 5. Using a build of > 345b214c37d1f645dd0e6e084358f8ca81d9ed66 on Linux, the observations from > Comment 1 are already there It can confirm Kira's bibisect and reproduce the issue starting at build [438fb2945cd985e6afe2a368e38e9b03c25633c8] in linux-64-24.2, which is 140079362502408c75ceee67e86d779f61c0ac1b. I think you might be missing this step: (In reply to Robert Großkopf from comment #0) > Write a word, mark it an go to sidebar. > Choose "Styles" → "Character Styles". > Choose "No Character Style". You have to apply the "No Character Style" to some text first. I guess there's two issues here: A) the inherited issue that "No Character Style" is not always available, for ease of use to "remove" a character style (debatable if it should change or not) B) the regression from 140079362502408c75ceee67e86d779f61c0ac1b, which does not list "No Character Style" even though it is in use in the document I suggest we focus on B. Can you confirm you see the same with the extra step, Björn? (Regarding (A), I'm a bit confused by the fact that "No Character Style" is a actually a style. I feel like it should be a button rather than listed alongside styles - unless we make it the "Default Character Style" with all other styles inheriting from it. Bug 151874 is relevant.)
Hmm, I tried this with a build of 7f85415a2f07d62bf688cb33680054940d4dd7f1 and with reverting that commit. Both with and without that commit, I find that as long as no style is applied, "applied styles" for character styles is empty. Once an character style is used in the document (e.g. "emphasis"), _both_ that style and "no character style" show up in "applied styles" for character styles. Weather or not the above is desired behavior, I dont find 7f85415a2f07d62bf688cb33680054940d4dd7f1 changing it.
Created attachment 195466 [details] screencast showing results at bibisected commit and at commit~1 (In reply to Björn Michaelsen from comment #11) > Hmm, I tried this with a build of 7f85415a2f07d62bf688cb33680054940d4dd7f1 > and with reverting that commit. Why that commit? That wasn't the one this was bibisected to. But assuming that was a wrong copy-paste and you actually meant 140079362502408c75ceee67e86d779f61c0ac1b: > Both with and without that commit, I find that as long as no style is > applied, "applied styles" for character styles is empty. That's also what I see: (A) in comment 10, and has always been the case, related but not the regression that we see. > Once an character > style is used in the document (e.g. "emphasis"), _both_ that style and "no > character style" show up in "applied styles" for character styles. This is where we have different results, for some reason. See attached video.
(In reply to Stéphane Guillou (stragu) from comment #12) > > Once an character > > style is used in the document (e.g. "emphasis"), _both_ that style and "no > > character style" show up in "applied styles" for character styles. > This is where we have different results, for some reason. See attached video. Ah, can finally reproduce this now as a regression of 140079362502408c75ceee67e86d779f61c0ac1b: reproduction steps: - create new document - open sidebar as styles->character styles->applied styles - observation: no style is listed - enter two words, mark one - go to menu->styles->emphasis (to apply the style to the marked word) before 140079362502408c75ceee67e86d779f61c0ac1b (expected behavior): - now both "no character style" and "emphasis" show up in the sidebar as applied character styles 140079362502408c75ceee67e86d779f61c0ac1b and later (observed behavior): - only "emphasis" show up in the sidebar as applied character styles
proposed patch: https://gerrit.libreoffice.org/c/core/+/171096 makes 'No Character Style' show up in 'Applied styles' regardless if it appears used or not.
Bjoern Michaelsen committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c17659cc51e4eea7b26f936604c2c3a29b308ba7 tdf#159168: consider dflt char format 'applied', even if it apparently is not It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
It is ok in Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8118d1be1be11e8c8c70a0a12da25f0fb3c250f1 CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Thanks Björn, I see it fixed in my own build: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1a26552de2e692f205695e581166f5eeca67b100 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded
(In reply to Stéphane Guillou (stragu) from comment #17) > Thanks Björn, I see it fixed in my own build: resolving as fixed then.
*** Bug 163653 has been marked as a duplicate of this bug. ***