Created attachment 165898 [details] sample Writer document showing the small capitals issue LibreOffice should be smart to detect when the font file has a “smcp” tag and then apply the built-in small capitals instead of simulating the effect when the user chooses to apply the small capitals effect: The explanation below needs the Libertinus Serif available at “https://github.com/alerque/libertinus/releases”, but any OpenType font with the “smcp” tag will show the difference from simulated small capitals to real small capitals: The first line was directly formatted with Libertinus Serif and then applied LibreOffice’s Small Capitals effect from Menu Format, Character, Font Effects, Case, Small capitals. The effect applied was simulated by LibreOffice. Notice how the small capitals have a thinner stroke than the regular capitals and even the lowercase letters (when they should blend) and are noticeable higher than the lowercase letters. The XML code on the document is <style:text-properties fo:font-variant="small-caps" style:font-name="Libertinus Serif"/>. The second line was directly formatted with Libertinus Serif and then applied Advanced OpenType Feature Small Capitals (use “Libertinus Serif:smcp” as the font name or go to Menu Format, Character, Font, Features, Lowercase to Small Capitals). The effect applied was built-in on the typeface’s font file (true small capitals). Notice how the built-in small capitals have the same stroke width as the capitals and are bolder than the simulated small capitals, blending perfectly with the capitals and the lowercase letters. The XML code on the document is <style:text-properties style:font-name="Libertinus Serif:smcp"/>. The third line was directly formatted with both methods: simulated and built-in/true small capitals. LibreOffice 7.0.0.2 renders them as if it was applied only the simulated method when it should apply the built-in/true small capitals. The XML code on the document is <style:text-properties fo:font-variant="small-caps" style:font-name="Libertinus Serif:smcp"/> (notice there are the two tags). Almost all LibreOffice components which deals with choosing typefaces have this defect that could be enhanced: Base (when creating forms), Calc, Draw, Impress, Writer. Only Math does not have the common window called when Menu Format Character is selected. I think a good compatibility option should be accepting the documents written with the old behavior (documents with the “<meta:generator>LibreOffice/7.0.1.2</meta:generator>” or lower, for example) so there is no text reflow, and then add to them a compatibility option similar to the ones found at Menu Tools, Options, Load/Save, Microsoft Office and HTML Compatibility. I suggest a new section named Advanced Typography Compatibility, so other OpenType enhancements as true superscripts and true subscripts could be added there too. I don't know where should be the best place/tag to save that compatibility option on the document, but no tag written should mean no compatibility. And with new documents, the Menu Format, Character, Font Effects, Case, Small Capitals should cause the documents to be saved only with “<style:text-properties fo:font-variant="small-caps" style:font-name="Libertinus Serif"/>” (even if the user goes to Menu Format, Character, Font, Features, Lowercase to Small Capitals, which now creates the “:smcp” code appended to the font name) and render the typeface with true built-in small capitals (if it exists) and only fallback to simulated small capitals if the font file does not have it. I don’t like the “:smcp” appended on the typeface name because it creates problems when changing fonts: it loses the “small capitals” feature, even if the new font chosen has true small capitals, which is something that doesn’t happen with other font attributes and effects (regular, bold, italic, italic bold, color, underlining, etc.).
Created attachment 165899 [details] sample PDF showing the small capitals issue As the typeface size was 12 points, maybe using a zoom of 150% when reading the first three lines of this sample PDF will make it easier to see.
Sounds reasonable -> NEW
Is the following further bug report closely related? <https://bugs.documentfoundation.org/show_bug.cgi?id=98367> (I apologise for the philistine formatting - I have trouble discovering what formatting BugZilla allows.) Is the following germane? In some (all?) instances, _small caps in a PowerPoint file render as all-caps in Impress_. That can wreak havoc upon a presentation. Thus, it is a serious problem. Indeed it is almost a deal-breaker for my use of Impress. (It is a shame that though Impress has taken strides in Microsoft Office compatibility, this breakage remains. It is almost enough to send me back to Windows.)
Might I bump this issue? For, if it is related to small caps in PowerPoint files ending up always as actual capitals within Impress, then that this a fairly serious problem. (Impress compatibility with PointPoint has come a long away. It is a shame to let that compatibility founder on a small but important point such as this one.)
So far as I can see (though it is not easy to tell) this bug report is open. Yet, judging by documentation for LibreOffice 24.2, the bug has been fixed.
(In reply to nj from comment #5) > So far as I can see (though it is not easy to tell) this bug report is open. > Yet, judging by documentation for LibreOffice 24.2, the bug has been fixed. I just tested it on 24.2.0.3 64 bits on Windows 11, the bug still exists. Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: pt-BR (pt_BR); UI: pt-BR Calc: threaded