The codes info for the selected D is displayed below the table. Here is the font that does display properly - Noto Sans Italic. as I am writing I see Huelle just posted above.įlexiPDF (and Infix) Have a useful feature to remap characters.īut you can also use it to look at the codes behind various characters. So it is having issues trying to figure-out the embedded fonts.Īhh. In PDF-Exchange Editor it displays the Noto Sans KR Bold as Regular, and shows both Noto Sans KR Regular & Bold as not embedded. Note: I did check the fonts and did not find any issues. There is definitely some problems in this PDF. This seems to be a problem only with Adobe software I'm afraid The same issue also occurred on my laptop running Windows 10. I'm running the latest Publisher version on Windows 11. I haven't conducted any testing with other non-latin fonts but this may yield similar results. I think this may be a bug in the PDF exporter. Unchecking Embed subsets fixes the issue, at the expense of increasing file size from 1MB to almost 8MB (since the Korean font is quite large) ( Font Embed Example (non-subset).pdf) which is too large for some file upload limits.
The regular Noto Sans font however embeds perfectly well: However, when exporting the document as a PDF from Publisher with the Subset fonts option checked, the exported PDF ( Font Embed Example (subset).pdf) is missing all styles (i.e bold and regular) of only the KR font: afpub) using Noto Sans Korean Bold (Google Fonts) and Noto Sans (Google Fonts) but still only using Latin characters.īoth fonts are listed as 'Installable' in Windows font settings: