Created attachment 123169 [details] Display while editing Small caps were added to Draw/Impress in Bug 91932, but they seem to be broken. It will display small caps while editing, but as soon as you click out, it reverts to displaying regular caps. Also, while displaying small caps while editing, the displayed text is much too small, but the cursor and selections are for the actual size, and don't match the displayed text. Still present in 5.1.1.1rc.
Created attachment 123170 [details] Display after clicking away
Created attachment 123171 [details] While editing, with the actual "Networks" selected
I confirm this bug on LO Version: 5.2.0.0.alpha0+ Ubuntu 15.10 To access that feature: Format menu >> Character... >> Font effects >> effects >> Small capitals
*** Bug 99540 has been marked as a duplicate of this bug. ***
Well, I don't really know how bugs are managed ; when I try to list bugs in bugs list : https://bugs.documentfoundation.org/buglist.cgi?bug_status=UNCONFIRMED&component=Writer&order=bug_id&product=LibreOffice&query_format=advanced this bug don't appear ; but, I consider it as a major bug because I can't figure some workaround to work and it's a feature that I use very often, for exemple to fill a text form that I put under an image, to make a title and so on... But, it seems that noone is in charge of this bug that don't appear except when I click on the link of an old received message. So I fear if it will be corrected in the next release... cordialement,
Bonjour, This very annoying bug is still present in 5.2.0 cordialement,
Confirmed - still here in 5.2.2
(Also still in 5.3rc3 - the current version in Ubuntu Zesty)
*** Bug 106530 has been marked as a duplicate of this bug. ***
Still present in 5.3.1 RC 2
Caolán, * for bug 91932, http://cgit.freedesktop.org/libreoffice/core/commit/?id=ff178cca3384a1d15dcf51491df6196e487f47f4 provides UI for setting case effects, but as noted here as soon as you leave a Text box with Small Caps formatting applied it shifts and just a Capitals effect results. Lowercase and Title effect apply and are retained along with Capitals effect on leaving the Text box. So CaseMap is mostly correct, but for some reason the Small Caps does not remain intact.
Still present in current stable 5.3.4.2. Quite annoying that this makes it impossible to apply nice typography through SmallCaps in Impress :(
*** Bug 117338 has been marked as a duplicate of this bug. ***
*** Bug 105307 has been marked as a duplicate of this bug. ***
Is someone working on this bug ? It's a 2 years old bug and seems not to be hard to solve (I'm not angry and I know it's easier to say, rather to do). Thanks :)
+1
Confirmed - still present in 6.0.6.2 - in Writer text box and in Impress.
*** Bug 122869 has been marked as a duplicate of this bug. ***
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
Still present in 7.1.4.
Is this related to the lack of Small Caps in Calc? The most interesting question is why Small Caps function is OK in Writer except for text in boxes, and the behavior in Base/Draw/Impress is the same as Writer text boxes -- where the preview is right but the execution fails. IOW, if the question is confined to the Writer module, what is the difference in character handling between text in boxes (where SC fails) and out of boxes (where it's OK)? Presumably that would lead to solution for other modules, and might open up Calc for Small Caps.
Still broken in 7.2.3.2.
This bug was first reported in LO 5.1.0.3, a bit under six years ago. Two years ago Xisco Fauli wrote: "Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20". Today (two years later, to the day), with no explanation, Caolán McNamara reduced priority from 'high' to 'low' [or 'normal'? - I'm hazy on the relationship between "Priority" and "Importance"] immediately following a report that the bug remains in 7.2.3.2 -- though the number of dups remains at 5 and the number on CC (for all dups) is 21. This prompts an observation, not a complaint, with accompanying question: How is this supposed to work? - Presumably Priority (or Importance?) affects resource assignments? - Is explanation required to raise, but not reduce, Priority? - After two years at high priority, and two major releases (and numerous minor releases) with no change, what is the effect of reducing priority?
I don't know if this could be of help, but I do believe this bug for Write and Draw is somewhat related to how Text Boxes are handled. I say so because if you create a Text Box in Write, you can't make the text in it Small Caps no matter what, but if you use the Frame structure there are no such issues, you can create Small Caps text as much as you. Since Draw uses Text Box too that's how this bug show there. Maybe if the Text Box were made more similar to the Frame structure this bug could be fixed. This aside I can Confirm it still exists in 7.3.0.
*** Bug 147732 has been marked as a duplicate of this bug. ***
Created attachment 181650 [details] Broken underline with different font size manual workaround I'm also seeing this issue in LibreOffice 7.4.0.2 when using text boxes in Impress. Sometimes I have been able to work around it by making a word all caps myself and manually reducing the font size of all but the first letter. However, this doesn't work when text is underlined, as changing the font size results in the position of the underline changing and not lining up with the rest of the text. Is there any way to make the text appear correctly when underlined?
(In reply to Marco Mazza from comment #24) > I don't know if this could be of help, but I do believe this bug for Write > and Draw is somewhat related to how Text Boxes are handled. I say so because > if you create a Text Box in Write, you can't make the text in it Small Caps > no matter what, but if you use the Frame structure there are no such issues, > you can create Small Caps text as much as you. Since Draw uses Text Box too > that's how this bug show there. ... Yes. This comment replicates comment #21, which is slightly more general.
(In reply to Theodore Brown from comment #26) > Created attachment 181650 [details] > Broken underline with different font size manual workaround > > I'm also seeing this issue in LibreOffice 7.4.0.2 when using text boxes in > Impress. ... Yes. This comment replicates comment #21. > ... Sometimes I have been able to work around it by making a word all > caps myself and manually reducing the font size of all but the first letter. > However, this doesn't work when text is underlined, as changing the font > size results in the position of the underline changing and not lining up > with the rest of the text. Is there any way to make the text appear > correctly when underlined? I'm afraid that questions involving prospective work-arounds would be more appropriate on the user forum than in this bug thread, which is oriented toward identifying and fixing operating problems rather than working around them.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/97469c2cac442fc3231694e35a8cd7a0f8d16af4 Related: tdf#98367 export editeng EE_CHAR_CASEMAP the same as writer does It will be available in 24.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ffaed5cae29d6bb14faf870cb935ccd3c35d4a3c tdf#98367 implement rendering of draw/impress small capitals It will be available in 24.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.
The bug is NOT Fixed in LibreOffice 7.5.5.2 on MacOSX, Windows and Debian
(In reply to Peter Milbradt from comment #31) > The bug is NOT Fixed in LibreOffice 7.5.5.2 on MacOSX, Windows and Debian of course it's not. it's fixed in master ( LibreOffice 24.2.0) only at the moment. That's why it's marked as RESOLVED FIXED.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e46e663cc350d89e4997095466d675b875eb2e04 Related: tdf#98367 allow drawing shapes in calc to have smallcaps It will be available in 24.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.
Nice, thank you so much!
In the 24.2 release notes: https://wiki.documentfoundation.org/ReleaseNotes/24.2#Impress Verified in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a2ccc25ccb2e94f5990d6d413541dbcdd3a72338 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
*** Bug 108902 has been marked as a duplicate of this bug. ***
(In reply to Stéphane Guillou (stragu) from comment #36) > *** Bug 108902 has been marked as a duplicate of this bug. *** Thank you Caolan for the fix, and Stephane for noticing the duplication :-)
(In reply to Eyal Rozenberg from comment #37) > Thank you Caolan for the fix, and Stephane for noticing the duplication :-) It was more Stuart than me, I just can't leave dupe-of-dupes alone :)
I think that small caps support caused a regression in right-to-left languages like Hebrew: https://bugs.documentfoundation.org/show_bug.cgi?id=160401