Bug 137080 - LibreOffice should use built-in OpenType Feature Small Capitals (smcp tag) when the typeface has it instead of simulated Small Capitals
Summary: LibreOffice should use built-in OpenType Feature Small Capitals (smcp tag) wh...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.4.0.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Effects
  Show dependency treegraph
 
Reported: 2020-09-27 21:41 UTC by João Paulo
Modified: 2024-02-01 20:55 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
sample Writer document showing the small capitals issue (31.62 KB, application/vnd.oasis.opendocument.text)
2020-09-27 21:41 UTC, João Paulo
Details
sample PDF showing the small capitals issue (55.16 KB, application/pdf)
2020-09-27 21:43 UTC, João Paulo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description João Paulo 2020-09-27 21:41:12 UTC
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.).
Comment 1 João Paulo 2020-09-27 21:43:11 UTC
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.
Comment 2 Buovjaga 2021-07-26 16:12:52 UTC
Sounds reasonable -> NEW
Comment 3 nj 2023-01-31 17:45:31 UTC
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.)
Comment 4 nj 2023-12-08 00:03:35 UTC
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.)
Comment 5 nj 2024-01-31 15:58:08 UTC
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.
Comment 6 João Paulo 2024-02-01 20:55:54 UTC
(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