Created attachment 196396 [details] testcase (triggering the issue only when some fonts are not available) PDF export should provide a way to detect font substitution for converters like unoconv (which uses the UNO bindings / standard LibreOffice API), which then could warn the user (or exit with a failure). I've attached a .odt file as a simple testcase, which has 2 characters "n" using different fonts (respectively Times New Roman and TimesNewRomanPSMT, according to the UI). FYI, the styles (e.g. font names) come from a copy-paste of text from the IEEE 754-2019 standard (I've replaced the text by just 2 characters "n"). In the official PDF version of the original document, the fonts are the same (or at least look identical), but here under Debian/unstable, the first "n" uses a serif font and the second "n" is larger and uses a sans-serif font; this occurs both in the UI[*] and in the PDF obtained with unoconv (where the pdffonts utility says that the fonts are LiberationSerif and NotoSans-Regular). To be clear: This bug is not about "fixing" the output, but to warn the user that there is a potential issue with the document (in the present case, the change of the style in the original document in unintended). [*] There is no warning in the UI either, which is bug 96872 (covering only the UI: see bug 96872 comment 29).
Created attachment 196397 [details] PDF file obtained with odt2pdf (unoconv) I've attached the PDF file obtained with odt2pdf (unoconv) under Debian/unstable, without any warning about the font substitution.
Note: this also concerns "libreoffice --convert-to pdf", which uses the writer_pdf_Export filter.
OK