<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><blockquote type="cite"><div>On 16 Aug 2023, at 16:23, Khaled Hosny <khaled@libreoffice.org> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br><div><br><blockquote type="cite"><div>On 16 Aug 2023, at 5:44 PM, Chris Tapp <opensource@keylevel.com> wrote:</div><br class="Apple-interchange-newline"><div><div>Hi Guys,<br><br>I’m supporting an organisation that is using LO to create pdfs that are used as inputs to a print-on-demand service, and we have identified a couple of issues that I would like to have a go at resolving:<br><br>1) The handling of font names differs between the Windows and MacOS builds, resulting in the rendering differing between the platforms;<br></div></div></blockquote><div><br></div><div style="caret-color: rgb(0, 0, 0);">This is <a href="https://bugs.documentfoundation.org/show_bug.cgi?id=105298">https://bugs.documentfoundation.org/show_bug.cgi?id=105298</a>, I had a stap at it recently on <a href="https://gerrit.libreoffice.org/c/core/+/155455">https://gerrit.libreoffice.org/c/core/+/155455</a>, but it is a complicated issue since macOS have no way of giving us the names we need for windows compatibility, and if we start to read the font name ourselves (like in the change above), more system API become useless (e.g. if we ask for font fallback, we will get names that is different from what we now have on our font list).</div><div style="caret-color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0);">I have some ideas to how to handle this, if you are still interested.</div><div style="caret-color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0);">Regards,</div><div style="caret-color: rgb(0, 0, 0);">Khaled</div></div></div></div></blockquote></div><div><br></div><div>Thanks.</div><div><br></div><div>I had tried looking to see if there were open bugs for these, but I hadn’t managed to find them.</div><div><br></div><div>Using the Open Sans Google Font, Font Book shows 12 styles:</div><div><br></div><div><ol class="MailOutline"><li>Regular</li><li>Italic</li><li>Light</li><li>Light Italic</li><li>Medium</li><li>Medium Italic</li><li>Semibold</li><li>Semibold Italic</li><li>Bold</li><li>Bold Italic</li><li>ExtraBold</li><li>ExtraBold Italic</li></ol></div><div><br></div><div>Within a local build (MacOS) of LO that includes your patch, I see the following Family / Typefaces:</div><div><br></div><div><ol class="MailOutline"><li>Open Sans / Regular, Bold, Italic, Bold Italic</li><li>Open Sans Extra Bold / Regular, Italic</li><li>Open Sans Light / Regular, Italic, Bold, Italic</li><li>Open Sans Medium / Regular, Italic</li><li>Open Sans Semibold / Regular, Italic</li></ol></div><div><br></div><div>Within the latest release, all 12 styles are shown as Typefaces under the “Open Sans” family - which is consistent with the identifiers shown for each font in Font Book.</div><div><br></div><div>I am definitely interested in any ideas you have to handle this.</div><br><div>Chris</div><div><br></div><div><div><blockquote type="cite"></blockquote></div></div></body></html>