Hello Steps to reproduce 1. File> New> Text document 2. Type "test" 3. Check File> Properties> Font> Embed fonts in the document 4. Save the document (test.odt for instance) 5. Unzip the archive As expected we have a Fonts subfolder in the archive. What I do not understand is that, whatever the fonts used in the document, the fonts Mangal and Mangal Bold are incorporated. Platform: Windows XP & 7 64bits Version: 4.1.0.0.beta1+ Build ID: 36b5efd733c68c67bb4a1b9489a775aed1fe98e TinderBox: Win-x86_9-Voreppe, Branch:libreoffice-4-1, Time: 2013-05-31_17:43:42 Regards Pierre-Yves
Hello Pierre-Yves, I confirm with LO 4.2.0.0.alpha0+ Build ID: 60790b3f0ccc1779bcff2ddcc278a9027aedabe Windows 7 Home Premium Have a nice day, Jacques Guilleron
Lubos - any thoughts on this ?
Well, they are used, in a way, the are used by certain styles. And e.g. SwXMLFontAutoStylePool_Impl::SwXMLFontAutoStylePool_Impl() writes out all fonts referenced by the document, even if it's just a fallback font for asian characters. The ODF export filters would need to get smarter about this.
Hello Thank you for replying (In reply to comment #3) > Well, they are used, in a way, the are used by certain styles. And e.g. > SwXMLFontAutoStylePool_Impl::SwXMLFontAutoStylePool_Impl() writes out all > fonts referenced by the document, even if it's just a fallback font for > asian characters. I see... > The ODF export filters would need to get smarter about this. The problem is not that annoying but it would be great... :) The API provides the isInUse method for the interface XStyle, may be ? Or at least check if the "bi-directional writing" option is enabled ? Regards Pierre-Yves
*** Bug 70669 has been marked as a duplicate of this bug. ***
*** Bug 75553 has been marked as a duplicate of this bug. ***
Testing on Linux Mint, i've observed that the saving of the document takes ~10 seconds, even with the document only had 'Hi' in it. So this is a time waster as LibO is unusable at that moment. And things are getting worse with each version as a 4.1 document was 23.6mb, 4.2 document was 24.7 and now a 4.3 beta document is a whopping 32mb. Hopefully once this is dealt with, my requesting for an easy means to know which fonts are available in a document will be easy to accomplish [bug 78186].
(In reply to comment #7) > Testing on Linux Mint, i've observed that the saving of the document takes > ~10 seconds, even with the document only had 'Hi' in it. So this is a time > waster as LibO is unusable at that moment. I just tried with LO 4.3.0.0.beta1+ on Ubuntu 14.04 x86-64 with 3 words in the document. The saving of the document is less than 1 second and the file takes 3.2 mb. If I open the odt archive, the fonts directory takes 6 mb and contains 9 fonts (ttf files). Best regards. JBF
Andras - potentially one to track for cp-4.2 ? =)
(In reply to comment #8) > I just tried with LO 4.3.0.0.beta1+ on Ubuntu 14.04 x86-64 with 3 words in > the document. The saving of the document is less than 1 second and the file > takes 3.2 mb. If I open the odt archive, the fonts directory takes 6 mb and > contains 9 fonts (ttf files). It is no doubt different people will have different experiences with this depending on what fonts are installed on their system. With me the 4.1 document saved 14 fonts at 39.1mb, 4.2 saved 16 fonts at 41.1mb and 4.3 saved 15 fonts at 56.1mb. This test was on the same system with the same fonts installed on the system. I thought it maybe due to the user profile, so i reset it in 4.3 and the resulting file had 13 fonts at 54.8mb with a file size of 32.9mb. So ultimately the delay in the UI will depend on the number of fonts its saving. With a stock Ubuntu 14.04 32-bit, the 'Hi' document is 5.5mb with 13 fonts in it at 10.4mbs and halted the UI for 2 to 4s. This test was on my laptop which has an Intel Core 2 @ 1.3ghz and 2.5gb of ram.
There appear to be multiple problems with font embedding: a) Fonts used in default (common) / automatic / pre-defined styles appear to be embedded in a non-obvious manner. b) Some fonts appear to be embedded twice (refer bug 83675). In the example XLSX in that report I did not reproduce this, but under GNU/Linux using v4.3.1.2 a new document containing "a" embeds two copies each of FreeSans and FreeSansOblique e.g.: <style:font-face style:name="FreeSans1" svg:font-family="FreeSans" style:font-family-generic="swiss"> <style:font-face style:name="FreeSans" svg:font-family="FreeSans" style:font-family-generic="system" style:font-pitch="variable"> c) Some fonts in use are not being embedded at all (again, refer bug 83675). Is this particular report only going to focus on (a) or expanded to cover (b) and (c) also? Just after some clarity about how to treat seemingly related reports. Thanks.
Hi (In reply to comment #11) > There appear to be multiple problems with font embedding: > ... > Is this particular report only going to focus on (a) or expanded to cover > (b) and (c) also? Several bugs (not yet assigned) are related to this feature (is there not also the multiplication of files?). I do not know if a "meta" bug was created or whether to create one. I do not enough know our use of BZ to have an opinion... I would like to get more competent than me on this matter :) Regards Pierre-Yves
Created attachment 113302 [details] sample of embedded fonts in 4.4.0.3 Attached file is from simple template with only custom styles applied throughout, all of which use the same font (Crimson). The resulting file does contain Crimson and its variants, but also FreeSans and its variants (twice), Times New Roman and variants, Arial and variants and Droid Sans Fallback, a total of 17 embedded fonts where only 4 were needed. These extra fonts are not used in the document, nor referenced in the style hierarchy; opening the file up they are only referenced in content.xml & styles.xml, and that's in both the attached file and in a version without embedded fonts. Therefore I assume font embedding is being done by simply looking for fonts referenced in the file. However all the fonts referenced but not used are contained in one small part at the beginning of content.xml within the tag office:font-face-decls, while only the font actually used is referenced after that tag - so cannot the embedder exclude fonts referenced within that tag? Alternatively, while the fonts referenced in that tag are referenced with style:font-face style:name= and svg:font-family=, fonts actually in use seem to be referenced within the document with style:font-name= so perhaps could be used as a reference when looking for fonts to embed.
*** Bug 92701 has been marked as a duplicate of this bug. ***
This bug is reproduced in Version 5.0.0.5 in Linux and Windows.
Perhaps a way forward is to add a further config option that says: only embed fonts used by text in the document. The aim being that the document is viewable and to a great extent editable. What is gained is that it minimises the fonts embedded while giving users the expected results. If someone really wants everything, they just don't click that option!
Happy to have another option if it's useful to you Martin; at least for now - I think its worth focusing on this as a bug; no point in embedding fonts (several times?) for styles etc. that are not used in the text =) looks like a normal bug to me - which we should fix (perhaps with the extra option there).
@Martin: No i dont think we need an extra option, as the option to embed fonts is only supposed to embed fonts used in the doc.
*** Bug 97874 has been marked as a duplicate of this bug. ***
*** Bug 99654 has been marked as a duplicate of this bug. ***
So i see that whatever fonts are set to be used for asian and ctl language support, even though the fonts arent actually set to any text but are set in various styles like the default paragraph and graphic styles, they will be saved within the document. On Windows 8.1, for asian support, Microsoft YaHei and SimSun are selected[1], and it embeds SimSun, but strangely didnt for YaHei, but corrupts the SimSun 17.4mb file as it removes the first 32 bytes from its beginning. For ctl support, Mangal is set and it embeds it totaling 377kb. A resulting blank document with these fonts takes up 11mb. On Linux Mint 18 (clean installation), for asian support, WenQuanYi Micro Hei is selected and takes up 4.9mb, while for ctl support, Lohit Devanagari is selected and takes up 137.5k, as it saves two copies of the same file. A resulting blank document with these fonts takes up 3.8mb. On Linux Mint 18 (with various MS fonts installed), for asian support, Microsoft YaHei and SimSun are selected and take up 51.8mb, while for ctl support, Lucida Sans is selected and takes up 127kb. A resulting blank document with these fonts takes up 3.8mb. A resulting blank document with these fonts takes up 32.9mb. Separate from the asian and ctl support, LO saves Liberation Sans and Serif for latin support which take up 2.8mb. @Olivier: in your duplicate bug, what do you have set for latin, asian and ctl fonts to get the whopping 94mb file you mentioned. [1] Tools > Options > LibreOffice Writer > Basic Fonts (Asian)
(In reply to Yousuf Philips (jay) from comment #21) (snip) > @Olivier: in your duplicate bug, what do you have set for latin, asian and > ctl fonts to get the whopping 94mb file you mentioned. > > [1] Tools > Options > LibreOffice Writer > Basic Fonts (Asian) Tested again in 5.4.1 (Kubuntu). A simple odt file with just "Hi" inside - No font embedded: 8k - Fonts embedded: 19M No Asian, no CTL set for my doc (UI=pt-BR). Basic (Western) fonts are Liberation Serif for all entries (Default, ..., Index).
(In reply to Olivier Hallot from comment #22) > Tested again in 5.4.1 (Kubuntu). > A simple odt file with just "Hi" inside > - No font embedded: 8k > - Fonts embedded: 19M Open up the 19mb file and see which fonts are embedded by 1. renaming the .odt to .zip 2. unzipping the file 3. check the 'Fonts' directory the first set of fonts are normally CTL, then the next set is Liberation fonts and the last set is asian fonts > No Asian, no CTL set for my doc (UI=pt-BR). Yes of course it isnt set, but find out which asian and ctl fonts LO is using by 1. go into tools > options > language settings > languages and check the asian and complex text layout checkboxes 2. open writer 3. go into tools > options > writer and see what is listed in Basic Fonts (Asian) and Basic Fonts (CTL) > Basic (Western) fonts are Liberation Serif for all entries (Default, ..., > Index). Yes this never changes unless a user changes it, as LO always bundles Liberation fonts.
*** Bug 113570 has been marked as a duplicate of this bug. ***
*** Bug 113656 has been marked as a duplicate of this bug. ***
As an author I often have documents of 400 plus pages, and as they evolve some have attracted numerous font references, resulting in very large files with a number of unwanted embedded fonts. I work in Linux and my manual solution is thus. Save the document as odt with the embed fonts button unchecked Change file suffix to zip open with archive. examine the file styles.xml for each unwanted " <style:font-face style:name="..." line at the top of the file do a global search & replace substituting the name of a required font as shown in the list. remove duplicate " <style:font-face style:name="... " lines created. save change the suffix back to odt Load in Libreoffice, check embed fonts and save. You now have a smaller file without the unwanted fonts. This is a dirty solution and probably leaves a lot of redundant tags in the file, but it works. An automated process based on this would be a fair solution.
This is a problem for me still in 6.0.0.1, first observed in the last 5.4, but only in one particular document, and only in the PDF export, where the font NanumMyeongjo is embedded. This is not used in the document, does not appear in an RTF export, and I cannot see it when unzipping the ODT and inspecting content and styles. It would be good if one of the suggested fixes were enabled.
I found the source of my Nanum font - in a badly-imported umlauted character in a footnote on p.108. Writer showed it as in Liberation Serif, but changing the character to remove the umlaut removed the unwanted NanumMyeongjo font from the PDF-1a export
Created attachment 140800 [details] empty document, 17MB The problem is present in LibreOffice Writer 5.4.6.2 too. (Build ID: 1:5.4.6~rc2-0ubuntu0.16.04.1)
The problem is still present in LibreOffice Writer 5.4.7.2 (x64).
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=eb6ff07605a55675e7007ac0cb5604fb13a9ddf9 [API CHANGE] tdf#65353 Add more doc. settings more embedding fonts It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3bc3ddc11fd94877d9c5d2b8313ab53150818236 tdf#65353 filter fonts when embedding (unused, font script) It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=39e5b2c174c6a27b5c3e2a08b00dd4c26677e07f tdf#65353 test for font embedding in ODF documents It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1a8435a23e84f3ceeee580eb9d4404a738d98888 tdf#65353 separate autostyle collection and export It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A polite ping to Tomaž Vajngerl: Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing? Thanks
Hmm. I tried a simple, one font document of some Awami text and said just to only include fonts used in documents, and the resulting .odt contained: "Courier New" (4 faces), Liberation Mono (4 faces), Liberation Serif (4 faces), Tahoma (1 face) in addition to the intended Awami (1 face). It's tricky because the character formatting for that one line of text says: Western Font = Awami Nastaliq, Asian = Courier New and CTL = Awami Nastaliq Beta 3 (which is referenced by the .odt but not included, perhaps because the font has gone away). So perhaps the Courier New inclusion makes sense. Not so sure about the Liberation and Tahoma, though. It does look like these fonts are referenced by the default styles. The question is whether fonts for unused styles should be included. I would argue that they not be included. Even a basic document of simply saying: new document, then select a font and type some text, ends up with quite a bit of cruft. Yes this is a distinct improvement over including all the system fonts. But it's still quite a big file.
Ah - is that specific to the fonts used by the default style I wonder ? I wonder if that style is used in some way that is not entirely obvious (?) any thoughts Quikee?
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
Changing priority to 'highest' since the commit caused regressions.
(In reply to Timur from comment #39) > Changing priority to 'highest' since the commit caused regressions. In that case, the priority of those regressions should be raised ( if it's justified, of course ) but not this one...
I don't agree here. Because this bug is still open and I don't see those commits worth regressions and it's duplicates. Shouldn't they just be reverted?
I hope my following discovery may shed a light on this rather strange behaviour: It appears that Microsoft forces fonts into a PDF file that are not in the Writer file at all. I saved one of the files I have as Rich Text. I opened it up in Wordpad. Wordpad would not care in the slightest what font I have set in the original Writer file. Wordpad would bluntly replace it with a Windows preloaded font. In my example I am using LO 7.0.3.1 on Windows Pro 10. The file that I created contains a section using the Droid Arabic Naskh font. Once I opened the converted .rtf file up in Wordpad the font was changed to Arial. I tried manually to change the font from Arial to Droid Arabic Naskh, however Wordpad would not accept this change of font and still force Arial in as font. Host OS = Windows 10 Pro build 1909. Hope this my observation helps.
Could someone explain current status of this bug and give exact steps to test? Steps and samples should be minimal. Like: open ODT with Liberation as default, type some text and change to Cantarell. File Properties : check Embed and Only used, check Čatin, uncheck others. Save. Via zip see that ODT has 2 font Cantarell and 4 font Liberation files. Expected : what exactly, that there are no used style fonts? But it is used as a style, regardless if there's some text, if not desired change style.
Saving is one part of the problem and using embedded fonts is another, bug 126936.
Hi (In reply to Timur from comment #43) > Could someone explain current status of this bug and give exact steps to > test? Steps and samples should be minimal. The only difference from what I wrote in comment #1 is that there are now additional options not used here. So the steps to reproduce are still the same: 1. File> New> Text document 2. Type "test" 3. Check File> Properties> Font> Embed fonts in the document 4. Uncheck all Font scripts to embed (latin, asian, complex) 5. Save the document (test.odt for instance) 6. Unzip the archive Actual result: The fonts Font_Mangal_1.ttf and Font_Mangal_2.ttf are still in the folder. Expected result: Only Font_Liberation_Sans_x.ttf in the folder
Sorry I forgot to specify my version: Version: 7.1.2.2 (x64) / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: threaded
The font embedding is all over the place. I've been using "embed fonts...", "only embed fonts that are used...", and leaving all the font scripts options unchecked, and it's a bit random what fonts are embedded. Extra fonts are embedded, and some fonts actually used are sometimes omitted. I upgraded from 7.1.1.2 to 7.2.0.4, and that helped, but it's still wonky. I am on Ubuntu 18.04. I have a document that uses Arimo and Allegreya Sans (from fonts.google.com). The default font is Liberation Sans, however the document doesn't use that font anywhere. I added some text using yet another font, Ubuntu, then changed it to Allegreya Sans. There is nothing in Ubuntu font left in the document, anywhere, as far as I can tell, but ever since I used it, Ubuntu is added to the save file. Liberation Sans may also end up in the save file. Without fonts, the file is 30k. With embedded fonts, I have seen sizes of 800k, 1.7M, 2M, 2.1M, and 3M. When Liberation Sans gets added back into the fonts LibreOffice decides to embed, I can get rid of that one by saving the file without embedded fonts, quitting LibreOffice, starting LibreOffice, loading the file without the embedded fonts, turning on the embed fonts option, and saving. That gets rid of Liberation Sans, but Ubuntu is still in there. If I make any edit at all, then save again, Liberation Sans will be shoved in again. I tried a direct approach of simply using an archiver (7-zip) to remove the Ubuntu fonts from the odt file, but that corrupted it. I also fiddled with the Paragraph Style: Default Paragraph Style, changing the default font from Liberation Sans to Arimo. That made it worse-- Arimo was left out, and Liberation Sans put in. One final note about embedding fonts: it doesn't work for the text entry fields of PDF forms either. If you add a Text Box, set the font to something custom, and export to PDF, the text entry field in the PDF form will not use the font you chose, it will use the default font of Helvetica.
*** Bug 153226 has been marked as a duplicate of this bug. ***
*** Bug 158588 has been marked as a duplicate of this bug. ***