How this works — the SDK calls behind this sample ↓
The two formats share nothing. A PDF stores its fonts as numbered resources, so the SDK walks them by index; a Word file declares font names and the converter reports how each one resolved. Both normalize into the single response the table above renders.
PDF — GdPicturePDF exposes a 1-based index. Read the count, then ask for each font in turn:
GetFontCount— how many fonts the document uses. The loop runs1..GetFontCount(), not from zero.GetFontName— the PostScript name. Subset-embedded fonts carry a six-letter prefix such asABCDEE+.GetFontTypeandGetFontEncoding— e.g.TrueTypeandWinAnsiEncoding. These fill the second line of each row above.IsFontEmbedded— whether the font program travels with the file. This is the one that decides whether a viewer can render the document faithfully on its own.
DOCX — SaveDocumentFontsInfo writes a single XML report rather than exposing an index. It has four buckets: DocumentRequestedFonts is the inventory, and EmbeddedFonts, SystemAvailableFonts and MissingFonts classify each entry. A stream overload exists, so no temp file is needed.
That is why a DOCX row shows a style — "Regular", "Bold" — but no type or encoding. Those are PDF concepts, and the XML does not report them.
Deliberately unused. Two more exist: GetFontData, which extracts an embedded font's bytes, and UnembedFont, which strips one. Both work, and neither is called here: this endpoint only reads. Worth knowing they exist if you need to repair or repackage a document rather than inspect it.