Description: **LibreOffice cannot recognize PMingLiU (新细明体)** I created a PPTX file in Microsoft PowerPoint and set the font to **PMingLiU (新细明体)**, which is a serif font. When I convert the file to PDF using `soffice`, I found that the corresponding font in the generated PDF is **fallbacked to a sans-serif font**. ``` /opt/libreoffice7.5/program/soffice --headless --convert-to pdf test.pptx ``` The same behavior can also be reproduced on macOS with the latest LibreOffice **25.8.4.2**. When opening the PPTX in LibreOffice GUI, the **PMingLiU font is fallbacked to a system HeiTi font**. ``` Version: 25.8.4.2 (AARCH64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 12; OS: macOS 26.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_CN.UTF-8); UI: en-US Calc: threaded ``` Steps to Reproduce: 1. Download test.pptx from https://github.com/MattCraftsCode/LibreOffice-issue-report/blob/main/test.pptx 2. Open it using Microsoft PowserPoint, check the font. 3. Open it using LibreOffice, check the font. 4. Compare font, they are different. Actual Results: The font "新细明体" in LibreOffice is different with Microsoft PowerPoint. Expected Results: The font "新细明体" in LibreOffice should same with Microsoft PowerPoint. Reproducible: Always User Profile Reset: No Additional Info: Please fix this bug — it’s critical for users.
Created attachment 205083 [details] The second slide of this PPT uses the PMingLiU font.
Hello Shiwei He, Thank you for reporting the bug. I can confirm that the bug is present in master. Version: 25.8.4.2 (X86_64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 680(Build:0) CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to Vignesh from comment #2) > Hello Shiwei He, > > Thank you for reporting the bug. I can confirm that the bug is present in > master. > > Version: 25.8.4.2 (X86_64) > Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df > CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; > VCL: win > Locale: en-US (en_US); UI: en-US > Calc: threaded > > Version: 26.8.0.0.alpha0+ (X86_64) > Build ID: 680(Build:0) > CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; > VCL: win > Locale: en-US (en_US); UI: en-US > Calc: threaded Hi Vignesh, Thanks for confirming this issue. May I ask if there is an estimated timeline (ETA) for fixing this issue, or whether it has been scheduled for a specific release? This would help us plan our workaround on our side. Thanks again for your help.
(In reply to Shiwei He from comment #1) > Created attachment 205083 [details] > The second slide of this PPT uses the PMingLiU font. It doesn't seem to be true. It is formatted with Microsoft YaHei. Extracting the content of the .pptx file (it is a zip file) and searching through the .xml files, I can't find PMingLiU or 新细明体. Please explain.
(In reply to Buovjaga from comment #4) > (In reply to Shiwei He from comment #1) > > Created attachment 205083 [details] > > The second slide of this PPT uses the PMingLiU font. > > It doesn't seem to be true. It is formatted with Microsoft YaHei. Extracting > the content of the .pptx file (it is a zip file) and searching through the > .xml files, I can't find PMingLiU or 新细明体. Please explain. Hi Buovjaga, Thanks for your reply. I conducted a small experiment for clarification. Please refer to the newly provided file: example-for-2-different-PMingLiu-fonts.pptx. - Slide 1 uses the font “新細明體 (Headings)”, which appears to be a built-in PPTX theme font (please correct me if this assumption is incorrect). - Slide 2 uses “PMingLiU”, which is a locally installed font on my system. Semantically, “新細明體” and PMingLiU refer to the same typeface family, so the expected rendering result should be consistent between the two. However, the actual behavior is different: - On Slide 1, the font is rendered using a fallback font that looks similar to a sans-serif (HeiTi-like) typeface. - On Slide 2, PMingLiU is rendered correctly. Based on my understanding, “新細明體 (Headings)” is a Heading font, i.e. a PPTX theme font, which likely means it is defined by the PPTX theme rather than being a concrete font file reference. Therefore, this issue seems to indicate that LibreOffice does not fully or correctly handle the PPTX theme font “新細明體 (Headings)”, while direct font references such as PMingLiU work as expected. However, the customer primarily uses “新細明體 (Headings)”, which is available by default in Microsoft PowerPoint (PPTX) and does not require manual installation. BR, Shiwei
Created attachment 205189 [details] Example for 2 different PMingLiu fonts This is an example for 2 different PMingLiu fonts.
(In reply to Buovjaga from comment #4) > (In reply to Shiwei He from comment #1) > > Created attachment 205083 [details] > > The second slide of this PPT uses the PMingLiU font. > > It doesn't seem to be true. It is formatted with Microsoft YaHei. I also see MS Yahei font when opening this attachment in LibreOffice. However, opening it in PowerPoint or WPS (a Chinese office suite notable for its MS file format compatibility), the second slide indeed displays in PMingLiU/新細明體 font. > Extracting > the content of the .pptx file (it is a zip file) and searching through the > .xml files, I can't find PMingLiU or 新细明体. Please explain. I believe the .xml files uses the traditional Chinese (zh-Hant) name of PMingLiU, 新細明體. For example, "新細明體" appears twice in the ppt/theme/theme1.xml file.
(In reply to Shiwei He from comment #6) > Created attachment 205189 [details] > Example for 2 different PMingLiu fonts > > This is an example for 2 different PMingLiu fonts. After I installed PMingLiu, the text in slide 2 is displayed with it just fine. About the issue with attachment 205083 [details], as the name is different, I'm not sure what the solution should be on our side. Let's ask font guru Khaled about how we should handle such cases in a smart way. Arch Linux 64-bit Version: 26.8.0.0.alpha0+ (X86_64) Build ID: e7edd94565e8dd323395ec316c482ec32f14638c CPU threads: 8; OS: Linux 6.18; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 23 January 2026
(In reply to Buovjaga from comment #8) > About the issue with attachment 205083 [details], as the name is different, > I'm not sure what the solution should be on our side. Let's ask font guru > Khaled about how we should handle such cases in a smart way. I’m not sure what is the issue being discussed here.
(In reply to Khaled Hosny from comment #9) > (In reply to Buovjaga from comment #8) > > About the issue with attachment 205083 [details], as the name is different, > > I'm not sure what the solution should be on our side. Let's ask font guru > > Khaled about how we should handle such cases in a smart way. > > I’m not sure what is the issue being discussed here. See comment 7. Can it be that MSO and WPS have some kind of mapping of traditional Chinese names of fonts? Should we add such a brute force method as well?
(In reply to Buovjaga from comment #10) > (In reply to Khaled Hosny from comment #9) > > (In reply to Buovjaga from comment #8) > > > About the issue with attachment 205083 [details], as the name is different, > > > I'm not sure what the solution should be on our side. Let's ask font guru > > > Khaled about how we should handle such cases in a smart way. > > > > I’m not sure what is the issue being discussed here. > > See comment 7. Can it be that MSO and WPS have some kind of mapping of > traditional Chinese names of fonts? Should we add such a brute force method > as well? Fonts can set their names in different languages, and this is particularly common in CJK fonts. I don’t know if we handle localized font names, most likely we don’t and I think we already have open issue(s) about this.
Ah, indeed, bug 63011 / bug 94631 / bug 154571 seem relevant. Not sure what to duplicate towards.
Hi Buovjaga, Thank you for the additional explanation. Font names can vary across different languages, which does seem to be a fairly common issue—especially for CJK languages. As you mentioned, the CJK user base is quite large, so I believe this is something that should be taken seriously. Do we have any plans to address this issue, for example by introducing a font mapping table? If so, could you please share an ETA? Thank you very much.
(In reply to Shiwei He from comment #13) > Do we have any plans to address this issue, for example by introducing a > font mapping table? If so, could you please share an ETA? It is something that our RTL/CJK specialist might work on at some point, but there is no ETA to give at the moment. I'll go ahead and duplicate to bug 154571 as it seems to request the same. *** This bug has been marked as a duplicate of bug 154571 ***