AddFont (embedding fonts) implementation

[josedachao]

Hello, Daniel and everyone!

I have resumed the activity of implementing AddFont and also _loadfont to allow the ability to add other fonts to FPDF (Pascal). For this purpose, I have been studying the implementation in PHP, but I have noticed that they use the MakeFont script to convert the font file to another file with a .php extension, as shown below:

https://www.fpdf.org/en/doc/addfont.htm
https://stackoverflow.com/questions/13361900/add-font-on-pdf-report-with-fpdf
https://www.fpdf.org/makefont/index.php (online converter, available on the project website)
https://www.fpdf.org/en/tutorial/tuto7.htm
https://github.com/Setasign/FPDF/tree/master/makefont

When we download the code directly from the FPDF/PHP website (fpdf.org), the MakeFont code (font file converter) comes with it, and it is perfectly possible to translate it to Pascal, but it would be inconvenient for developers who use FPDF/Pascal to first use the converter so they can incorporate their fonts into their projects, having to distribute the converted file together with their application, since the library generates the PDF file on the fly.

So, I leave a question: does the leadership of this project want to implement it in the same way, using a converter beforehand to extract the information needed to add the font and maintain fidelity to the initial PHP project? Or use another approach like fcl-pdf or the Python implementation of FPDF, which apparently does not use the converter like the PHP version. Of course, regardless of the approach, the code should be implemented with FPC/Delphi compatibility in mind.

For reference - Python implementation:
https://pyfpdf.readthedocs.io/en/latest/reference/add_font/index.html
https://github.com/reingart/pyfpdf/tree/master

For reference - fcl-pdf implementation:

To add fonts to an fcl-pdf document, you'll need to embed them within the PDF. This involves using the gTTFontCache to locate fonts and then adding them to the TPDFDocument. You'll also need to specify the font directory and ensure the fonts are accessible to the PDF generation process.

Here's a breakdown of the process:

1. Include the fpttf unit: Ensure the fpttf unit is included in your application.

2. Initialize the Font Cache: The gTTFontCache is global and needs initialization. Use gTTFontCache.ReadStandardFonts; to load standard fonts.
   You can also add custom font directories using gTTFontCache.SearchPath.Add(), for example: gTTFontCache.SearchPath.Add('/usr/share/fonts/');.

3. Add the Font to the Document: Create a TPDFDocument instance and set its FontDirectory property to the location of your font files (e.g., C:\Windows\Fonts).
   Use the AddFont() method to add the desired font, providing the font file path and the font name (e.g., FontID := Document.AddFont('arial.ttf', 'Arial');).

4. Set Font Properties: After adding the font, use Page.SetFont(FontID, fontSize) to apply it to a specific text element on a page.

5. Embed the Font: Ensure that you are embedding the fonts. This is typically done by adding the poNoEmbeddedFonts flag to the document options. Without embedding, the font may not be displayed correctly if the recipient doesn't have the font installed.

Example Code Snippet:

procedure TMainForm.TestButtonClick(Sender: TObject);
var
FontID: Integer;
Document: TPDFDocument;
Section: TPDFSection;
Page: TPDFPage;
begin
Document := TPDFDocument.Create(nil);
Document.FontDirectory := 'C:\Windows\Fonts';
Document.StartDocument;
FontID := Document.AddFont('arial.ttf', 'Arial');
// Optionally, embed fonts (e.g., Document.Options := Document.Options + [poNoEmbeddedFonts])
Section := Document.Sections.AddSection;
Page := Document.Pages.AddPage;
Section.AddPage(Page);
Page.SetFont(FontID, 11);
Page.WriteText(20, 20, 'This is some text using Arial');
Document.SaveToFile('output.pdf');
end;

I send my best regards to everyone, stating that I do not wish to hinder anyone's efforts, I would just like to help in the implementation of this functionality.

[dopidaniel]

Hello @josedachao

Thank you for your help and for the extensive study you have already done...

I also found it strange to use an external application to generate an intermediate file, like MakeFont does in PHP...
I didn't think this was a good solution for Pascal.

I will study the implementation of fcl-pdf better, as I believe it would be a more appropriate way for us to proceed...

Is your idea to try to convert the fcl-pdf units to make them compatible with FPDF-Pascal, in Delphi and Lazarus ?

[limelect]

JOSE which PDF uses are you using
all free ones do not have you functions

[josedachao]

Hi, Daniel, how are you?

I don't like the idea of ​​using an external service to generate sources at all, and from what I understand, you didn't like it either. So I don't think it's a good choice use something like MakeFont.

A few days ago I was still unsure about which approach to take, whether to adapt the fcl-pdf concept or use the same concept as the original FPDF, but without using a service external to the library, as they did in the Python version of FPDF.

It became clear to me that maintaining conceptual integrity (as Fred Brooks' concept advocates) should be the most important thing, so in my opinion, the best path would be to base it on the Python source code of FPDF library. At first glance, it may seem like a greater challenge to search in another language than in Pascal code, but conceptual integrity is fundamental.

As well as users will be able to search for references and examples and documentations of use directly in the Python and PHP implementations.

Conceptual integrity not only makes the system easier to use, but also contributes to its quality and maintainability. The user will be able to use the library intuitively and without major conflicts in the future. A system without conceptual integrity can become confusing, difficult to use and maintain.

So, I'm in favor of translating/converting and adapting the Python FPDF library code.

[josedachao]

JOSE which PDF uses are you using all free ones do not have you functions

Hello, limelect, how are you?

I develop in Free Pascal/Lazarus so I am not aware of any free report/PDF generators for Delphi.
So I can only speak about my development environment.

A few months ago I translated most of our report sources to FPDF/Pascal, which has the great advantage of being compatible with Free Pascal and Delphi, congratulations to Projeto ACBr and Daniel.

The limitation of embedded fonts was not a problem for us, but I certainly believe it could be one day, so the functionality should be implemented (in my opinion).

Below I give examples of two free tools that generate PDFs with support for embedded fonts, but are not compatible with Delphi. These tools are my favorites, but there are others (https://wiki.freepascal.org/PDF).

1. By the way, fcl-pdf has the functionality of embedding fonts, and it's free (https://wiki.freepascal.org/fcl-pdf)
   The fcl-pdf package contains the generating unit fppdf that does not depend on any external libraries (like FPDF).
   The PDF generator has the following features:

Support for basic shapes.
Support for basic line styles.
Dictionary support.
Multi-page PDF.
Image support.
TTF Font support.
Font embedding.
Unicode font support.
Stream Compression.
Image embedding.
Several paper types.
Portrait/Landscape.
Support for multiple units.
Rotation matrix system.
PDF creator information.
Output validates by several PDF validators.

2. fpReport (https://wiki.freepascal.org/FPReport), which is also free, is a Free Pascal report generator (is a banded reporting tool, like QuickReport, Fast or Fortes) that does not depend on graphical environments (an X server, for example), you can use a graphical report generator to make templates and save this to future uses.

https://wiki.freepascal.org/FPReport

FPReport is a banded reporting tool.

It was designed from zero, to be able to run on a headless webserver, with minimal dependencies. An important use-case was a Linux server running in a container without X libraries installed. Creating a report is just placing squares with contents on a page, usually based on a data loop. This can be done entirely in-memory, and does not need a display or GUI.

Reports can be created entirely in code, or they can be read from a definition file. The default shipped file uses JSON as the format to store the report definition. The reports can also be designed visually, using a designer. A stand-alone designer exists, as well as the possibility to design a report within the Lazarus IDE.

Once the report is created, it can be saved to disk, or rendered. Rendering is the act of creating visual output.

Various renderers have been implemented:

To PDF. The PDF renderer is the renderer of choice
To a series of images. The FPImage renderer creates a bitmap per page, and the bitmaps can be saved in a directory in any of the supported FPImage formats.
To HTML: each page is rendered as a HTML page using appropriate CSS markup.
Parts that cannot be rendered as HTML and CSS will be rendered as an image and placed in the HTML page.
To the LCL (a canvas).
This is in fact the basis of the preview, the designer and the printing support.
To an AggPas canvas. AggPas is a powerful graphics library, and this renderer is similar in scope to the FPImage renderer
To fpGUI - this can be used to preview the report in a FPGUI report