To expand on the selected answer (by o11y_75) when you convert your fonts, you need to use a specific name to include also the bold and italic variants.That way, you only add one font definition like this
notice that behind the original name, you add b, i and bi on each case.I have found no documentation on this issue, but I followed the nomenclature found on the fonts that already came with TCPDF and it worked.
Add Font Html2pdf
Download File: https://tlniurl.com/2vHZux
I have solved this as follows:I searched for TCPDF in the vendor directory and found the Fonts directory there.Then I created my own separate PDF script and used it once to create the necessary font files from the ttf.
Up until now, we haven't spent much attention to the fonts that were used when we converted HTML to PDF. We know that Helvetica is the default font used by iText when no font is specified (chapter 2), and we know that pdfHTML ships with some built-in fonts if you need to embed a font (chapter 4), but we didn't get a clear overview of which fonts are supported as of yet.
The "iText core" library supports Type1 fonts (.AFM/.PFB), the old TrueType fonts (.TTF), OpenType fonts with Type1 outlines (.otf), OpenType fonts with TrueType outlines (.ttf) and TrueType collections (.ttc), as well as the Web Open Font Format (.woff).
The pdfHTML add-on uses a DefaultFontProvider (Java/.NET) that by default only provides support for the 14 Standard Type 1 fonts and 12 fonts that are built-in into pdfHTML. You can configure the font provider to support more fonts.
In this chapter, we're going to look at some examples that use the default fonts provided in pdfHTML, and we're going to unlock access to all the other types of fonts that are supported by the core library.
The PostScript names of 14 Type 1 fonts, known as the standard 14 fonts, are as follows: Times-Roman, Helvetica, Courier, Symbol, Times-Bold, Helvetica-Bold, Courier-Bold, ZapfDingbats, Times-Italic, Helvetica-Oblique, Courier-Oblique, Times-BoldItalic, Helvetica-BoldOblique, Courier-BoldOblique.
The shall in that last sentence means that you don't have to embed these fonts when creating a PDF document, because you can expect that every PDF viewer knows how to render these fourteen fonts. iText ships with the 14 Adobe Font Metrics (AFM) files that correspond with these Standard 14 fonts, which means that these fonts are always supported. However, since the corresponding Printer Font Binaries are proprietary, iText will never embed these fonts.
The fonts_standardtype1.html HTML page lists the fourteen fonts: 4 Helvetica fonts, 4 Times fonts, 4 Courier fonts, Symbol, and ZapfDingbats. As you can tell from figure 6.1, Helvetica, Times, and Courier are rendered correctly by the browser.
The Symbol and ZapfDingbats are fonts with a custom encoding. They don't play well with HTML. In the FAQ chapter, we'll discover that there are other fonts that are better suited for symbols such as the ones provided in Symbol and ZapfDingbats. For now, we only have numbers for the symbol font (0123456789) font and a non-breaking space character ( ) for the ZapfDingbats font.
None of these fonts are embedded, because iText only ships with the font metrics, not with the font binaries. The fonts are substituted by a font that is available on the local machine. In this case, Courier has been replaced by CourierStd, Helvetica has been replaced by ArialMT, and Times-Roman by TimesNewRomanPSMT.
Different PDF viewers on different operating systems may use other fonts as the "Actual Font." This can be problematic, for instance when you want to create PDF/A documents. To solve this problem, the pdfHTML add-on ships with 12 free fonts.
The pdfHTML add-on supports font embedding of three font families out-of-the box: a sans font, a serif font, and a monospaced font family. For each of these font families, four fonts are available: a regular font, a bold font, an italic (or oblique) font, and a bold-italic (or bold-oblique) font.
In the fonts_shipped.html HTML file, we use the font-family: FreeSans, font-family: FreeSerif, and font-family: FreeMono. We could also have used font-family: sans, font-family: serif, and font-family: mono instead; that would have led to the same result. We use different combinations of the font-weight: bold and font-style: italic so that we can show the four fonts of every font family.
Looking at the Font panel of the Document Properties in figure 6.4, we see that a subset of each of the twelve fonts was embedded, as opposed to Helvetica and Helvetica-Bold which aren't embedded at all.
That's pretty limited, so let's find out how we can add support for more fonts. For instance: wouldn't it be nice if we had access to all the system fonts that are provided by the operating system we're working on?
In the fonts_system.html HTML file, we introduced font families such as Calibri and Verdana. I am writing this tutorial on a Windows machine, and my browser can render the different Calibri and Verdana fonts correctly (see figure 6.5), because the corresponding font programs are available in the C:\Windows\Fonts directory.
The default value for registerSystemFonts is false, because when you set this value to true, iText will search for directories that contain system fonts on your operating system. This has the some disadvantages:
But let's not worry about that right now, and let's change the font provider to support system fonts anyway. Let's set all the Boolean values to true in the C06E03_SystemFonts.java example, and see what happens.
Now that we have changed the ConverterProperties(Java/.NET), we can use almost any font that is in C:\\Windows\Fonts. Among those fonts are the fonts of the Calibri and Verdana family. Subsets of these fonts are now embedded in the PDF as shown in figure 6.6.
Support for WOFF fonts is especially welcome if you want to convert web pages found in the wild to PDF, but please take into account that your HTML to PDF conversion process risks being slow when using this approach. The fonts are downloaded over a network, and that typically slows things down.
This way, we add one selected font to the font provider. As a result, the words "quick brown fox jumps over the lazy dog" for which we defined a regular font, will be rendered using the font Carbo-Regular. Since we didn't provide any bold or italic font of the Carbo family, the Standard Type 1 fonts Roman-Bold and Roman-Italic are used for the other two lines.
Let's fix this. In the C06E06_ExtraFonts.java example, we don't use the addFont()/AddFont() method to add one font at a time. Instead, we use the addDirectory()/AddDirectory() method to add three Cardo fonts at once:
When we talked about using system fonts, we mentioned that we can't control the order in which the fonts are added if we register full directories. We'll find out why this is a disadvantage using the simple hello.html HTML file from chapter 1. See figure 6.12.
We'll convert this simple HTML file to PDF twice, using the same createPdf()/CreatePdf() method, but we'll create a DefaultFontProvider (Java/.NET) instance that doesn't register any of the Standard Type 1 fonts, doesn't register any of the built-in fonts, nor any of the system fonts. This will exclude the use of fonts such as Helvetica, FreeSans, or any other font as the default font.
We'll use the same selection of fonts, NotoSans-Regular.ttf and Cardo-Regular.ttf, in two examples, C06E07_ExtraFontsOrder1.java and C06E08_ExtraFontsOrder2.java, yet the PDFs generated by these two examples will be different.
These two examples explain an important aspect of the inner workings of pdfHTML. When pdfHTML needs to render a character as a glyph, it will first search for a font name in the HTML, and it will ask the font provider if there's a font available with that name. If no font is found, or if no font name was provided, pdfHTML will loop over the different fonts that are registered to the font provider, in the order in which they were registered, As soon as pdfHTML finds a font that can render the character as a glyph, it will use that font.
When you register a full directory, for instance by including all system fonts, you can't control the order in which the different font programs are added to the font provider. This makes it very hard to predict which font will be used by pdfHTML. This is especially problematic if you write an application that can be migrated to different systems. Different systems may have different system fonts, and this may lead to PDF documents that look completely different because a different font is used. There's also the risk that a font directory contains a font with embedding restrictions. When pdfHTML encounters such a font, an exception will be thrown.
There's one important aspect of fonts that we didn't spend any attention to so far. When we use a font, we map characters in an HTML file to glyphs in a PDF document. An a character can be mapped to different visualisations of the letter a, for instance 'a', 'a', 'a' , or even 'Î' or '@' or any other glyph depending on the encoding that is used.
In the case of Winansi encoding, iText creates a simple font. A simple font maps a maximum of 256 characters to 256 glyphs, which means that each character can consist of only one byte. If you want support for more than 256 characters in one font, you need a composite font. For instance: if you use the Identity-H encoding, the characters are stored as Unicode characters.
The pdfHTML add-on will try to use Unicode whenever possible. That explains why many of the examples show Identity-H for the encoding in the screen shots, except in the cases where Standard Type 1 fonts are used. The Standard Type 1 fonts don't have Unicode support, hence Winansi is used instead.
The Chinese and Korean titles are still missing, and so are several characters in the Japanese title. The Arabic characters are there, and they are now in the right order, but they are all wrong because the ligatures aren't made. Ligatures are supported out of the box when you use pdfCalligraph, but this add-on uses information that is stored inside the font to create the ligatures. Unfortunately, the built-in fonts don't support Arabic ligatures. 2ff7e9595c
Comentarios