Feature idea: make `get_fonts` also return the font objects

[Lucas-C]

Current state

_get_fonts() is a method of PageObject.

It is a bit unclear to me if this method is part as pypdf public API, as there are unit tests for this method,
but it starts with an underscore and is used nowhere in pypdf internal code.

Goal

I'd like to be able to know the size of the embedded fonts in a PDF document.

Hence I suggest this:

• rename _get_fonts() into get_fonts() to make it clearer that it is a public method
• instead of return 2 sets, it could now return 2 dicts, with the associated fonts mapped to their names in the PDF document

What do you think?
Would you be open to this idea?

[stefan6419846]

It is a bit unclear to me if this method is part as pypdf public API, as there are unit tests for this method, but it starts with an underscore and is used nowhere in pypdf internal code.

All functionality which is not part of the public modules and/or does start with an underscore is considered internal API. Breaking changes to these might be done without any further notice.

For this specific functionality, see #153 (comment) as well.

instead of return 2 sets, it could now return 2 dicts, with the associated fonts mapped to their names in the PDF document

I guess it should be refactored further to use proper data structures, maybe even considering the new font classes as requested in #3602 for example.

[Lucas-C]

Thank you for your answer @stefan6419846

I will try to make this refactoring.

[PJBrs]

It seems that we have two somewhat similar functions in _page.py:

_get_fonts

pypdf/pypdf/_page.py

Line 2090 in 4740225

def _get_fonts(self) -> tuple[set[str], set[str]]:

and _layout_mode_fonts

pypdf/pypdf/_page.py

Line 1834 in 4740225

def _layout_mode_fonts(self) -> dict[str, Font]:

The former seems to dive much deeper in the PDF structure to find fonts and has dedicated code to identify embedded fonts, whereas the latter instantiates the fonts as Font classes. With #3602 added, and using Font instances as is used in _layout_mode_fonts, we would only need to check if Font.font_descriptor.font_file is not None to see if a font is embedded.

With that, it would seem to me that we might integrate these two functions into one public function?

One final question, I wonder whether a "new" get_fonts function should return only font names, Font instances, and/or maybe also font resources.

I myself have been considering something like this as well, while looking into the code that creates appearance streams for text widget annotations. That code currently allows setting the font for the resulting appearance stream, overriding the font specified by the text widget annotation itself. However, in practice there is no code currently that tries to find an existing font resource for a given font name, meaning that it will only work in very rare examples. I've found that it is easy to create font resources for the 14 Adobe Core Fonts, but other examples will probably all fail. If _page.get_fonts would return the font resources, that information would be useful for setting custom fonts in widget annotation appearance streams. I hope, @Lucas-C that these considerations help you with your refactoring!

[PJBrs]

... I just remembered that there is a third place in _page.py that collects Font instances and font resources to initiate a TextExtractor class:

pypdf/pypdf/_page.py

Lines 1708 to 1722 in 4740225

	if (
	not is_null_or_none(resources_dict)
	and "/Font" in resources_dict
	and (font_resources_dict := cast(DictionaryObject, resources_dict["/Font"]))
	):
	for font_resource in font_resources_dict:
	try:
	font_resource_object = cast(DictionaryObject, font_resources_dict[font_resource].get_object())
	font_resources[font_resource] = font_resource_object
	fonts[font_resource] = Font.from_font_resource(font_resource_object)
	# Override space width, if applicable
	if fonts[font_resource].character_widths.get(" ", 0) == 0:
	fonts[font_resource].space_width = space_width
	except (AttributeError, TypeError):
	pass