What 's difference between font is embedd fonts and nonembedd font?

Question

In book i see example :

BaseFont bf = BaseFont.createFont(\"KozMinPro-Regular\", \"Identity-V\", BaseFont.NOT_EMBEDDED);
Font font = new Font(bf, 20);
VerticalTe         


        

Answer 1

When a font is not embedded, the PDF viewer does not know what the font looks like. Instead of using the actual font, it searches for a font with a similar name on the operating system of the person viewing the document.

For instance: there are 14 so-called Standard Type 1 fonts that do not need to be embedded:

• zapfdingbats
• times-roman
• times-italic
• helvetica-boldoblique
• courier-boldoblique
• helvetica-bold
• helvetica
• courier-oblique
• helvetica-oblique
• courier-bold
• times-bolditalic
• courier
• times-bold
• symbol

If you use these fonts in iText, iText will ignore the embedded parameter, because it is safe to assume that Adobe Reader and other viewers can render these fonts correctly.

Now suppose that you use a special font, such as the Coca Cola font to draw the text you see on a Coca Cola advertisement, or such as a Walt Disney font to draw text using the curly Walt Disney glyphs. In that case, it is better to embed the font. If you don't, there's a huge chance that the font won't be displayed correctly when a user opens his PDF document.

Embedding a font, means that you include the glyph descriptions of the full font or a subset of the font into the PDF. This results in an increased file size, but in some cases, it is mandatory to embed the font. For instance: if you want to comply with the PDF/A standard, all fonts need to be embedded.

When using a CJK font (one that is defined in the itext-asian.jar), iText will ignore the embedded parameter. It will never embed a CJK font, because CJK fonts expect the presence of an Asian font pack in your viewer (if it's not present, Adobe Reader will ask you to download such a font pack).

When using IDENTITY_H or IDENTITY_V, iText will also ignore the embedded parameter because the PDF specification demands that you embed a subset of the font when using these values for the encoding parameter.

It is unclear why you would expect glyphs to be rotated 90 degrees clockwise when changing the embedded parameter. It seems to me that you are mixing some concepts. IDENTITY_V isn't about rotating glyphs. It's about rendering text vertically instead of horizontally. For Western languages, we write text horizontally in lines that go from left to right and top to bottom. Arabic and Hebrew are written in horizontal lines from right to left. Some Asian languages, such as Japanese, are written vertically, in columns from right to left. This is when you are going to use IDENTITY_V, not as much to rotate the glyphs by 90 degrees, but to make sure that the vertical spacing between the different glyphs is correct (whereas IDENTITY_H defines the horizontal spacing).

See vertical_text_1.pdf for an example where the V makes sense. There's also an example where we rotate the text:

/**
 * Converts the CIDs of the horizontal characters of a String
 * into a String with vertical characters.
 * @param text The String with the horizontal characters
 * @return A String with vertical characters
 */
public String convertCIDs(String text) {
    char cid[] = text.toCharArray();
    for (int k = 0; k < cid.length; ++k) {
        char c = cid[k];
        if (c == '\n')
            cid[k] = '\uff00';
        else
            cid[k] = (char) (c - ' ' + 8720);
    }
    return new String(cid);
}

The result looks like this: vertical_text_2.pdf (not that good, I admit). The full code for this example, can be found here.