[Bug 60240] New: gdi32/win32u: memory font without OS/2 table is skipped by the font engine, breaking embedded fonts of LibreOffice-generated PDFs

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60240

            Bug ID: 60240
           Summary: gdi32/win32u: memory font without OS/2 table is
                    skipped by the font engine, breaking embedded fonts of
                    LibreOffice-generated PDFs
           Product: Wine
           Version: 10.9
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdi32
          Assignee: [e-mail]
          Reporter: [e-mail]
  Target Milestone: ---
      Distribution: ---

Created attachment 81939
  --> http://bugs.winehq.org/attachment.cgi?id=81939
trace, reproducer, proposed fix

LibreOffice (tested with 24.8) exports PDF files with subset-embedded
TrueType fonts that contain no `OS/2` table. When such a document is opened
in a WPF-based viewer running under wine (in our case DevExpress
Xpf.PdfViewer, .NET Framework 4.7.2), all glyphs of these fonts render as
boxes/nothing. On native Windows 11 the very same document and application
display correctly.

WINEDEBUG=+font pinpoints the cause — dlls/win32u/freetype.c, new_ft_face():

```
0024:trace:font:new_ft_face Loading font from ptr 0x... size 9160, index 0
0024:trace:font:new_ft_face Font (null)/0x... lacks either an OS2, HHEA or HEAD
table.
Skipping this font.
```

The loader requires OS/2 **and** HHEA **and** HEAD to be present. The
LibreOffice subsetter emits head/hhea but never OS/2, so every embedded font
of such documents is silently dropped.

Minimal reproducer (attached):

* `lo.ttf`   — TrueType subset extracted from a problem PDF (no OS/2 table,
  only a Macintosh (1,0) format-0 cmap; produced by LibreOffice);
* `a_os2.ttf` — byte-identical file except a synthesized minimal OS/2 v4
  table added;
* `addfont_probe.cs/.csproj` — tiny C# console program calling
  gdi32!AddFontMemResourceEx on both files.

Results under wine-11.16:

```
lo.ttf    -> AddFontMemResourceEx returns NULL ("Skipping this font" in +font
log)
a_os2.ttf -> registered OK, fontsAdded=1
```

Full trace excerpt attached (`wine_trace_excerpt.txt`).

Note for triage: native Windows 11 applies *different* additional
requirements in AddFontMemResourceEx itself (it rejects both attached files,
apparently because of the missing Unicode cmap). The divergence relevant to
this report is that Windows font loaders used by real applications (WPF /
DirectWrite path) happily consume the OS/2-less font — the LibreOffice
document renders fine on Windows 11 — while wine's loader rejects it solely
because of the missing OS/2 table. Since LO-exported PDFs are extremely
common, any PDF viewer relying on the Wine font engine is affected.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.