Apache OpenOffice (AOO) Bugzilla – Issue 19544
Small Caps Font Effect Not Available in Calc
Last modified: 2019-05-16 09:48:23 UTC
In Writer, when modifying a paragraph style, under the Font Effects tab there is drop down list labeled "Effects" which includes Capitals, Lowercase, Title and Small Capitals. A similar listing is not available under the Font Effects tab in Calc.
Hi, this is not a defect but an RFE. So I set the flags. Frank
Corrcted target milestone according PCD.
It's missing in Impress as well... A pity when one has to create a presentation about some name that has to be written in small caps :-/
*** Issue 103189 has been marked as a duplicate of this issue. ***
Happens the same in Draw; the small caps effect is missing. Version: OOO320m12 (Build:9483)
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".
This has been around for a long time. Is it that hard to fix? It would seem that the code is already in Writer. 3.4 made the Print dialog the same in Write and Calc. Can't the Format Font Effects be made the same also?
I just stumbled over this issue in Impress and found this 12-year-old bug. Is this for real or was it just an oversight not to close this?
(In reply to cmertes from comment #9) > I just stumbled over this issue in Impress and found this 12-year-old bug. > Is this for real or was it just an oversight not to close this? It is not a bug, in that Calc (let's keep this about Calc) is that way by design. There has been no change in the behavior of the product as of Apache OpenOffice 4.1.2. It's a bit more complicated than just using the paragraph rendering and styles already available in the product, although a small test document could be created to see if that actually works. It seems that the ODF 1.2 specification allows this to be implemented, with the additional styling communicated in the .ods file format. However, successful interchange of ODF documents using that capability is a concern, both for its impact on older versions of the software and other-product support for the ODF format. Correct Export to other formats (e.g, .xls and .pdf) matters too. I mention these to point out that it is not just about the rendering of cell text, but successful communication of such settings and, where not recognized, not breaking anything. There are some simple experiments that can be done without changing the product. Going farther that that is more involved.
(In reply to orcmid from comment #10) > It is not a bug, in that Calc (let's keep this about Calc) is that way by > design. Well, I would argue that it is an even bigger issue for Draw and Impress where such design aspects are usually closer to the core of the purpose of the software. If this bug shall be kept to Calc and maybe it being even more difficult to implement for Calc, should we open separate bugs for Draw and Impress respectively? By the way, I tried copying over some small caps text from Writer into a text field of Impress and the behavior was that the small caps were sorta kinda correctly displayed while still editing the text (the kerning seemed off and the width of the text was much larger than the width of the letters, leading to some whitespace after the text) but as soon as I left the editing mode, the rendering basically reverted to something like all caps. I didn't test this in detail but maybe this is already helpful to some.
(In reply to cmertes from comment #11) > Well, I would argue that it is an even bigger issue for Draw and Impress > where such design aspects are usually closer to the core of the purpose of > the software. I am not disputing this. My concern is that tail-gating onto an issue originally about Calc is inappropriate. There is no reason to consolidate onto a single issue at this point. There should be separate issues about this for Draw and Impress. There are different analyses required, although some of the interoperability issues are the same.
(In reply to cmertes from comment #11) > I tried copying over some small caps text from Writer into a > text field of Impress and the behavior was that the small caps were sorta > kinda correctly displayed while still editing the text (the kerning seemed > off and the width of the text was much larger than the width of the letters, > leading to some whitespace after the text) but as soon as I left the editing > mode, the rendering basically reverted to something like all caps. I didn't > test this in detail but maybe this is already helpful to some. The same exercise from Calc does not carry the Small Caps into the cell, although I am not surprised that an action that causes any refresh, such as a Save, would lose what appears to be accomplished. This happens in other situations too. Please continue that on an Impress issue. There are some other things to try for Calc, such as "faking" a sheet that already has SmallCaps in it and seeing what happens. Doing this in Impress and Draw may be quite different and should be kept separate.
(In reply to orcmid from comment #10) > successful interchange of ODF documents using that capability is a concern, > both for its impact on older versions of the software and other-product > support for the ODF format. > > Correct Export to other formats (e.g, .xls and .pdf) matters too. > > I mention these to point out that it is not just about the rendering of cell > text, but successful communication of such settings and, where not > recognized, not breaking anything. Another factor that occurred to me in a restless sleep is internationalization. I am not certain how this situation is dealt with in different language settings, especially ones not based on the conventional Roman alphabet. It will be interesting to understand how Writer copes with that. Side Note: Of the 40 internationalizations of 4.1.2 that are being downloaded weekly, 8 languages account for 90%. In decreasing order they are English (with 41%), French, German, Italian, Spanish, Russian, Polish, and Japanese (with 3.3%). Nationally, only about 15% of downloads are to the United States, about the same as the proportion to France.
Hello, (In reply to orcmid from comment #12) > (In reply to cmertes from comment #11) > > Well, I would argue that it is an even bigger issue for Draw and Impress > > where such design aspects are usually closer to the core of the purpose of > > the software. > > I am not disputing this. My concern is that tail-gating onto an issue > originally about Calc is inappropriate. There is no reason to consolidate > onto a single issue at this point. > > There should be separate issues about this for Draw and Impress. There are > different analyses required, although some of the interoperability issues > are the same. For what it's worth, two separate bug reports are currently in the tracker for Draw: bug #93066 and bug #118302.