How to provide font substitution list when using --convert-to pdf in headless mode (without GUI or modifying registrymodifications.xcu)?

[satya_kompella]

I am using the --headless --convert-to pdf command line option in LibreOffice and not using the GUI at all.

My requirement is to provide a font substitution list for fonts that are not available on Linux, or to map commercial fonts to equivalent open-source alternatives.

I know that:

• This can be configured through Tools → Options → Fonts in the GUI.
• It is also possible to edit the registrymodifications.xcu file, but I would like to avoid this, as modifying this file directly could potentially corrupt the user profile.

Question:
Is there any alternative way to define or provide a font replacement table when using only the command-line --convert-to pdf (headless) option, without relying on the GUI or modifying registrymodifications.xcu?

[mikekaganski]

No. Modify registrymodifications.xcu.

@satya_kompella

but I would like to avoid this, as modifying this file directly could potentially corrupt the user profile

Use a dedicated user profile. In general, using the default user profile for command line operations is a bit odd, especially when such operations are important part of the workflow. Every change you make in your main profile may affect your command line pipeline - do you really expect that? Your command line operations should use something configured separately. See -env:UserInstallation in help.

[satya_kompella]

@mikekaganski I’ve been using a base user profile (let’s call it base/prime), which I let LibreOffice generate once during initialization. For each subsequent document conversion, I copy the contents of this base profile into a new working folder instead of creating a new user profile from scratch. This significantly reduces profile setup time.

However, there’s a challenge when the user requests dynamic font substitution, for example, replacing font A with font B. In such cases, I need to modify the registrymodifications.xcu file before executing the --convert-to pdf command. Because the substitution varies at runtime, I can’t always rely on the static base profile.

Creating a fresh user profile for every conversion would introduce noticeable delays. One workaround I’m considering is copying the base profile and then programmatically updating only the registrymodifications.xcu file with the required substitutions.

Do you know of any better approaches or alternatives to handle dynamic font substitution through the CLI, possibly without modifying the user profile each time?

[Wanderer]

@satya_kompella

Creating a fresh user profile for every conversion would introduce noticeable delays.

Create one or more additional profiles as a install. Then only tell LibreOffice by env: wich one to use. (You may still restore theese profiles as a cleanup, if you are concerned the will be contaminated by using them.)
.

@satya_kompella

better approaches or alternatives

You may file a request for enhancement at Bugzilla to ask for a command-line parameter for substitution lists. But it still eludes me, why you need more than one substitution list.

[mikekaganski]

@Wanderer

But it still eludes me, why you need more than one substitution list.

Exactly.

@satya_kompella

Because the substitution varies at runtime

This is the unclear part. So you have some varying requirements each time? You run the --convert-to, each time knowing an exclusive requirement like "substitute foo with bar, but keep baz"; and the next time, you can do --convert-to with "substitute foo with bar2, and baz with bar3"?

If so, then just keep adding stuff to the registrymodifications.xcu programmatically. Add a specific XML comment like <!-- FONT_SUBSTITUTIONS_HERE -->, and replace that literal string with the needed substitutions (or just let it stay, when you don’t need them - it’s a comment).

But I think, that for most, it would make sense to just have a (growing?) common substitution list in your template registrymodifications.xcu, covering all fonts you need.