LayoutProcessor and multi-threading environment

[hvbtup]

Describe the bug

For different TrueType fonts, it seems that one needs to change static (read: global) flags of the LayoutProcessor class.

https://github.com/LibrePDF/OpenPDF/blob/master/openpdf/src/main/java/com/lowagie/text/pdf/LayoutProcessor.java

This will sooner or later lead to hard-to-find bugs in a multi-threaded environment due to race conditions, when OpenPDF is used by more than one thread to create PDFs.

To Reproduce

Due to its nature, this can only reproduced in a multi-threading environment when OpenPDF is used by several threads to create PDF docs, and each thread toggles some of the flags during execution, for example to render arabic text inbetween latin text. And then you still need luck to spot the bug.

So, in practice, this bug will inevitably occur in production, and probably only there.

See my comment on https://github.com/eclipse-birt/birt/pull/2144 for more details

Your real name

Henning von Bargen

Additional context

I think the LayoutProcessor class should be made a normal class (not only static attributes) and an instance of this class should be part of one the basic classes needed to add content to a PDF.

[vk-github18]

So far, there hasn't been any example that required changing the options. If you have a use case, please describe it, then we can think about a solution. And no, mixing RTL and LTR languages does not require changing the options. See https://github.com/LibrePDF/OpenPDF/blob/2.0.3/pdf-toolbox/src/test/java/com/lowagie/examples/fonts/GlyphLayoutDocumentBidi.java. The LayoutProcessor should be activated once at the beginning and not changed afterward.

[hvbtup]

What if (in a multi-threaded environment) one thread wants/needs to create PDF text with kerning and ligatures enabled, and a different thread running at the same time wants to create PDF text explicitly without ligatures?

[vk-github18]

See example GlyphLayoutDocumentKernLigaPerFont.java

Henning von Bargen @.***> schrieb am Mo., 19. Mai 2025, 11:42:

What if (in a multi-threaded environment) one thread wants/needs to create PDF text with kerning and ligatures enabled, and a different thread running at the same time wants to create PDF text explicitly without ligatures?

[hvbtup]

@andreasrosdal

After a (quite long) discussion in the BIRT issue 2144, according to Volker it seems that one of our problems is a bug which is already fixed in the OpenPDF trunk, but not in the latest release. However, AFAIK the BIRT Eclipse project can only use release builds of 3rdParty libs. This bug - and the way we tried to work around it - causes us serious headache.

When is the next release of OpenPDF scheduled?

[andreasrosdal]

2.0.4 was released today.

[vk-github18]

This issue is not about a bug, but about an enhancement request. For this, more information about possible use cases would be helpful.

[balaji-pc]

@vk-github18 After gone through issue. Realized, I fallen to the same situation in multi threaded environment that you faced. In addition to this,

1. The line haven't repositioned to middle, After the Glyph Substitution which occurs a little gap at the EOL particularly for right/center alignment.
2. Following this discussion: comment My use case requires loading the same font multiple times with different options, so I need to bypass/disable the global font cache. When I enable LayoutProcessor once at startup, subsequent loads fail with “not.found.as.file.or.resource” because our fonts live in a Google Cloud Storage bucket (fetched via HTTPS), not on the local filesystem/classpath. Is there a supported way to provide a custom FontProvider/loader so LayoutProcessor can load fonts from a URL/InputStream?

I not sure this is an issue or not

[vk-github18]

@balaji-pc Looks, like these are two issues. Please create these issues and provide minimal working examples.

Loading fonts from URL should work.