Cid Font F1 F2 F3 F4 May 2026

If your PDF shows F1 as Type 0 and F2 as Type 2, you know one is PostScript-based and one is TrueType-based.

If you can share a small snippet of the raw source (HTML or the email MIME structure), I can point to the exact lines to change.

In PDF document structures, CIDFont+F1, F2, F3, and F4 are internal labels assigned by PDF-generation software (like Adobe Distiller or Microsoft Print to PDF) when it cannot or chooses not to embed the original font names. These are not "real" font names you can find in a standard font library; rather, they are placeholders for Character Identifier (CID) fonts used to handle large character sets or encoding issues. Breakdown of CID Font Labels

The labels F1 through F4 (and beyond) are generally assigned incrementally by the PDF producer. While the exact mapping can vary between documents, they typically represent different styles or weights of the primary fonts used in the original source:

CIDFont+F1: Often represents the primary typeface in Bold style (e.g., Arial Bold).

CIDFont+F2: Typically represents the primary typeface in Regular style (e.g., Arial Regular). cid font f1 f2 f3 f4

CIDFont+F3 & F4: These usually correspond to other variations like Italic, Bold Italic, or secondary typefaces used in the document. Technical Overview

Structure: A CID-keyed font is a "composite" font that uses Character IDs (CIDs) to index glyphs, making it more efficient for languages with thousands of characters, such as Chinese, Japanese, or Korean (CJK).

Encoding: These fonts often use the Identity-H or Identity-V encoding. This maps character codes directly to glyph indices in the font file, which can sometimes make text extraction difficult if the mapping is incomplete.

Anonymization: Because these names are randomly generated during the export process, they do not tell you the original font's name. To identify the actual font, you must often use advanced tools like iTextSharp to look inside the embedded font program itself. Common Issues and Solutions How to fix font issue to make PDF file show properly?

Here is what you might see when inspecting a PDF: If your PDF shows F1 as Type 0

8 0 obj
<<
  /Type /Font
  /Subtype /CIDFontType2
  /BaseFont /MS-Gothic
  /CIDSystemInfo <<
    /Registry (Adobe)
    /Ordering (Japan1)
    /Supplement 5
  >>
  /FontDescriptor 9 0 R
  /DW 1000
>>
endobj
10 0 obj
<<
/Type /Font
/Subtype /Type0
/BaseFont /MS-Gothic-H
/Encoding /Identity-H
/DescendantFonts [8 0 R]
/ToUnicode 11 0 R
>>
endobj
In the page’s /Resources:
/Resources <<
/Font <<
/F1 10 0 R
>>
>>

Here, /F1 references a Type0 CID font (MS-Gothic-H). Thus, CID Font F1 is the logical name used on that page to invoke that Japanese font.

To avoid confusion with F1, F2, F3, F4, follow these rules: Here is what you might see when inspecting

When a Raster Image Processor (RIP) receives a file with CID font F1, it looks at the CIDFontType. If it is Type 0 (PostScript), the RIP must have a PS3 interpreter. If it is Type 2 (TrueType), the RIP handles it natively. Print errors often appear as: "Error: Undefined resource /F2" – meaning the RIP never received the embedded font data.

Why it happens: The PDF uses a custom CMap for F3 that doesn't map CIDs back to Unicode correctly. The visual glyph (what you see) is correct, but the internal text layer is code 0234 which your OS interprets as a Latin character. Solution: Use OCR (Optical Character Recognition) via Adobe Acrobat’s "Enhance Scans" tool to rebuild the text layer over the existing CID glyphs.

Effect: Copy-pasting text from that font yields garbage characters.

Solution: Add a /ToUnicode stream using tools like cpdf or Adobe Acrobat Pro’s "Preflight" fixups.