Bug 506426

Related:
https://bugs.kde.org/show_bug.cgi?id=506403 - On MS Windows, Okular tends to embed huge fonts by default.
https://bugs.kde.org/show_bug.cgi?id=503529 - On MS Windows, Okular switches comments to Segoe UI when editing them.

https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1400 is trying to not embed e.g. 'nimbus' if that's what one get for asking for one of the standard fonts.

The description text contains some cruft that I forgot to delete before posting. If possible to someone, please remove the part starting with including "The PDF format has three standard font families:" and ending before "REFERENCES".

*** Bug 510441 has been marked as a duplicate of this bug. ***

________________________________________
WORKAROUND

It is currently possible to edit “okularpartrc” located e.g. in

    ~/.var/app/org.kde.okular/config/  # for flatpak
    ~/.config/okularpartrc    # for regular installations

to achieve the wanted behavior.

________________________________________
STEP BY STEP

1. In Okular, change the font for new typewritter and inline notes to anything but the default. Also adjust the font size, as changing it later will require editing the “okularpartrc” file again. E.g. “Monospace” for typewriter comments and “Sans Serif” for inline note comments.

2. Open the “okularpartrc” file and replace the font names chosen above by one of “Helvetica”, “Courier”. I didn't test whether you need “Times Roman” or “Times” for a serif font.

Now inserting new comments uses standard PDF fonts.

________________________________________
LIMITATIONS

1. When you reopen or reload the file later and edit the text content of the comment, that comment is switched to the default GUI font, i.e. this workaround is largely sabotaged by an unrelated bug. On Windows 11, the default font is "Segoe UI Emoji", which is HUGE (several MB). On my Linux system it is “Noto Sans”, which still adds 300 KB by itself. Since the fonts are fully embedded and not as subset fonts, you can quickly end up with very large PDFs when commenting. To avoid this you have to avoid editing existing comments, and instead have to rewrite them (augmented by cut+paste). Within the same session, editing works without that issue.

2. Font embedding does not work consistently. Sometimes the font gets embedded despite having a standard PDF font name, sometimes not. Might be related to font substitution.

(In reply to Klaus from comment #5)
> ________________________________________
> WORKAROUND
> 
> It is currently possible to edit “okularpartrc” located e.g. in
> 
>     ~/.var/app/org.kde.okular/config/  # for flatpak
>     ~/.config/okularpartrc    # for regular installations
> 
> to achieve the wanted behavior.
> 
> ________________________________________
> STEP BY STEP
> 
> 1. In Okular, change the font for new typewritter and inline notes to
> anything but the default. Also adjust the font size, as changing it later
> will require editing the “okularpartrc” file again. E.g. “Monospace” for
> typewriter comments and “Sans Serif” for inline note comments.
> 
> 2. Open the “okularpartrc” file and replace the font names chosen above by
> one of “Helvetica”, “Courier”. I didn't test whether you need “Times Roman”
> or “Times” for a serif font.
> 
> Now inserting new comments uses standard PDF fonts.
> 
> ________________________________________
> LIMITATIONS
> 
> 1. When you reopen or reload the file later and edit the text content of the
> comment, that comment is switched to the default GUI font, i.e. this
> workaround is largely sabotaged by an unrelated bug. On Windows 11, the
> default font is "Segoe UI Emoji", which is HUGE (several MB). On my Linux
> system it is “Noto Sans”, which still adds 300 KB by itself. Since the fonts
> are fully embedded and not as subset fonts, you can quickly end up with very
> large PDFs when commenting. To avoid this you have to avoid editing existing
> comments, and instead have to rewrite them (augmented by cut+paste). Within
> the same session, editing works without that issue.
> 
> 2. Font embedding does not work consistently. Sometimes the font gets
> embedded despite having a standard PDF font name, sometimes not. Might be
> related to font substitution.

Please note that this also requires newest Poppler (25.10)

And yes, if we ask to embed "Helvetica" and we get something actually "Helvetica", we still embed it (for all the 14 base fonts). We only skip the embedding in poppler if we get a substitute font.

I do think that font-subsetting (and something slightly smarter font refcounting in poppler) is the real fix here, but please don't hold your breath for that.

> Please note that this also requires newest Poppler (25.10)

I checked, and the Flatpak version has Poppler 25.10 as backend. Not sure about the current Windows version, but I think the workaround worked there too.

> And yes, if we ask to embed "Helvetica" and we get something actually
> "Helvetica", we still embed it (for all the 14 base fonts). We only skip the
> embedding in poppler if we get a substitute font.

I have a "Courier" font from the org-x11-fonts-converted package, but no "Helvetica" font on my system. I guess that explains why Courier gets embedded but not Helvetica. Since embedding might actually be desired for exact glyphs, I guess that can't be handled generically.

This just confirms to me though, that a separate "use only PDF standard fonts" setting for the commenting tools would be useful, as it would help unintentionally inflating the PDFs.

(In reply to Klaus from comment #7)
> I have a "Courier" font from the org-x11-fonts-converted package, but no
> "Helvetica" font on my system. I guess that explains why Courier gets
> embedded but not Helvetica. Since embedding might actually be desired for
> exact glyphs, I guess that can't be handled generically.

That was at least my thinking when I wrote the patch a couple of years ago that was recently merged.