Description: According https://help.libreoffice.org/latest/en-US/text/shared/01/font_features.html , LibreOffice supports otf font (OpenType). Unfortunately, LibreOffice failed to embed such fonts, no problem for ttf format (if shared, installable flag is set) Steps to Reproduce: 1.Install provided font (blogger-sans-medium) 2.Create a text in Writer, see test-example. 3.In files->properties->font tab, check font embedding 4.Rename odt type in zip file, extract contents 5.Locate fonts directory, check instead blogger-sans-medium font, you have Times-New-Roman (or other substitution ttf font) Actual Results: The font is substitued in file. Expected Results: Otf is embedded. Reproducible: Always User Profile Reset: No Additional Info: Embed the right font.
Created attachment 187492 [details] Test file Should contain embedded font
Created attachment 187493 [details] Blogger font
Such a line of code may show some lack of support. https://opengrok.libreoffice.org/xref/core/vcl/source/gdi/embeddedfontshelper.cxx?r=5aad191e#204
The file extension have nothing to do woith this. What OS are you using and what version of LibreOffice.
Hi, Windows 10/11 (but question is open for Linux too) Rename test file in .zip, open it, look at the 'font' folder, it's where embedded font stand. I have never seen other font than ttf type. It works for ttf... Now user have otf fonts. I would be happy to know that is independant from any format, but i want to have know precisely how it is supposed to work. tks
Tested in 7.4.6.2, 7.5.1, 7.6 alpha.
I tried other OTF fonts and they embed fine, something about this font weight being Medium is tripping the font embedding code.
Which otf font do you succeed to embed ?
I will test other weight
It worked with any .otf file I tried. Note that the embedded file will end up with the .ttf extension (and this is what the line of code you pointed to is about), but this is inconsequential.
So i understand the otf file is renamed (why ?) in ttf in the odt file... I have never seen such behavior, i must alway use a ttf version...or the font is substitued. and 100% of my test to embed otf is unsuccessful...even if i try to change editable/installable flag of the font... Could you tell me the name of an OTF font you succeed in embedding ?
Ok, spotted, i have succeeded in embedding Unna otf font. The font is renamed with ttf extension.
So, i don't understand why otf fonts are renamed with ttf extension. It is not exactly same format. Is it a convention ?
(In reply to Regis Perdreau from comment #13) > So, i don't understand why otf fonts are renamed with ttf extension. It is > not exactly same format. Is it a convention ? The file extension is immaterial, OpenType is a superset of TrueType and almost all fonts with .ttf extension are actually OpenType fonts. The choice of file extension is a convention: https://learn.microsoft.com/en-us/typography/opentype/spec/recom#filenames
The link you pointed almost explains the opposite... but with many "should" conditionnal, the author is probably embarassed with this question. "A file containing a single font resource with TrueType outlines should have either .OTF or .TTF extension. The choice between .OTF and .TTF may depend on the desire for backward compatibility on older systems or with previous versions of the font. A file containing a single font resource with only CFF outline data (no TrueType outlines) should have an .OTF extension." I have an otf font which have never previous ttf version and only CFF outline, so we could expect to have a conservative attitude and keep otf extension. If extension is not hard linked to the real file content, it's an user indicator of what the file is supposed to be... I don't think it's a good practice to change it on the fly. Help doesn't mention it. I close the ticket. Thanks for your help.
(In reply to Regis Perdreau from comment #15) > The link you pointed almost explains the opposite... but with many "should" > conditionnal, the author is probably embarassed with this question. > > > "A file containing a single font resource with TrueType outlines should have > either .OTF or .TTF extension. The choice between .OTF and .TTF may depend > on the desire for backward compatibility on older systems or with previous > versions of the font. > A file containing a single font resource with only CFF outline data (no > TrueType outlines) should have an .OTF extension." > > I have an otf font which have never previous ttf version and only CFF > outline, so we could expect to have a conservative attitude and keep otf > extension. > > If extension is not hard linked to the real file content, it's an user > indicator of what the file is supposed to be... I don't think it's a good > practice to change it on the fly. Help doesn't mention it. > > I close the ticket. > > Thanks for your help. When we embed the font, we don’t know what its original file extension is, and on some systems (namely Windows and macOS) we never get access to the original file, only its data loaded in memory. So whatever file extension we use will always be a guess. We can add some code to detect if the font has a CFF table and change the file extension accordingly, but that is so much work for something users are not supposed to see any way (I don’t think extracting the ODT file and looking at its content is a general practice that we need to worry so much about).
Tks for explanation.
Gerrit patch: https://gerrit.libreoffice.org/c/core/+/153007
luigiiucci committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e7c885389bfb9387acf8a21ea38769e678a76aac tdf#155486 Adding fonts to .odt when there is "no perfect match" 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.
As an explanation to the fix, the reason why the font wasn't embedded is because it wasn't matching the style used in the document, ie. attachment 187493 [details] is an italic style of the font, and when it is present, it is used as substitute to regular style as well, but since there's no regular style of the font present in the system, it didn't get embedded in the document. The fix addresses that, and adds such fonts to the document if no perfect match is found.
luigiiucci committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/cc631df53da60b486ececd620064a65c6683a20c tdf#155486 Adding fonts to .odt when there is "no perfect match" It will be available in 7.6.0.2. 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.