Form fields: Missing glyphs for diacritics, plus v3.6 regressions (comb spacing ignored, diacritic fields turn completely blank)

[scscgit]

SumatraPDF version

• Versions:
  • v3.5.2 64-bit
  • v3.6 64-bit

Describe the bug
This report covers a pre-existing font rendering issue with PDF form fields, as well as two new regressions introduced in v3.6.

When filling out an official Slovak government tax form, the following issues are observed:

1. Pre-existing Bug (v3.5.2 and likely older): Missing Diacritic Glyphs
   SumatraPDF fails to render certain Central European/Slovak diacritics in form fields (specifically Č and Ň). Instead of rendering the letters, it displays missing glyph "tofu" boxes (e.g., POČÍTAČ renders as P O ▢ Í T A ▢).

2. v3.6 Regression #1: Comb Field Spacing Ignored
   In v3.5.2, comb fields (fields meant to evenly space characters into individual visual boxes) worked somewhat correctly. In v3.6, this formatting is completely ignored. Standard text is grouped to the left with standard kerning (e.g., T E S T E R now just displays squished as TESTER).

3. v3.6 Regression #2: Fields with Diacritics are Completely Blank
   While v3.5.2 showed missing glyph boxes for unsupported diacritics, v3.6 fails to render the field entirely. If a field contains a Č or Ň, the entire field content becomes invisible/blank.

To Reproduce
Steps to reproduce the behavior:

1. Generate the official Slovak Republic tax form PDF from: https://pfseform.financnasprava.sk/Formulare/eFormVzor/DP/form.620.html (located from here under Správa daní / Daň z príjmov fyzickej osoby / Daňové priznanie k dani z príjmov fyzickej osoby (typ A) / DPFOAv24 Daňové priznanie k dani z príjmov FO (typ A) za obdobie 2024 (platné od 1.1.2025))

2. Fill in the following fields:

• 03 - Priezvisko: TESTER
• 04 - Meno: POČÍTAČ
• 09 - Obec: MODRÝ KAMEŇ

3. Also fill in any mandatory fields to make the form errors disappear, such as:

• 01 - 000000000
• 02 - 01.01.1111
• 06 - Test
• 08 - 00000
• 10 - Slovensko

4. Press the "Vytlač" (print) at the bottom of the page to print as PDF, save as a new file.

5. Observe the rendering differences.

Expected behavior (Matches Firefox)

• 04 - Meno and 09 - Obec should display the text with proper Slovak diacritics.
• 03 - Priezvisko, 04 - Meno, and 09 - Obec should all have their characters evenly spaced to fit the individual comb boxes.

Actual Behavior

In SumatraPDF v3.5.2:

• Comb spacing works (mostly).
• Diacritics fail and render as missing glyph boxes (P O ▢ Í T A ▢ and M O D R Ý K A M E ▢).

In SumatraPDF v3.6:

• Comb spacing is broken (TESTER ignores the boxes and aligns left).
• Diacritic rendering is broken further (the fields containing POČÍTAČ and MODRÝ KAMEŇ vanish completely).

File that reproduces the problem

test_diakritika_danove_priznanie_form.620.pdf

Screenshots

In the middle you see the correct behavior in Mozilla Firefox 148.0 (64-bit):

Additional context

We often need to use this official government document, for example when proving our income to the banks. I hope you consider this issue to have an urgent severity level.

[GitHubRulesOK]

There are a few different Adobe form filling methods one is based on editor "recognition" so

1. an underline in MSWord or similar may be accepted as a "field" and font-based boxes detected and used as check boxes but that is AFAIK proprietary to Adobe editors like DC and not in the ISO standard and cannot be expected in other PDF readers.

2. There is another Adobe only method used mainly by government servers. This is known as eXtended Forms Architecture XFA and is excluded from the Open PDF ISO standard as cannot be expected to be supported by normal PDF readers.

3. Normal forms as described by the ISO standard MuPDF does support those but they are a form of complex annotation and SumatraPDF does not support those at present.
   In FACT MuPDF refuses to attempt that form as not a standard format

In all 3 cases Windows has an inbuilt Adobe forms editor in Edge so the file can be exported to that easily from SumatraPDF

[scscgit]

Well, my point is only the fact that all browsers basically natively support this flawlessly, despite not being led by Adobe.

I have no idea how complex it can be to find a workaround, but I'd beg you to at least consider displaying a warning to the user whenever you load a file that you cannot guarantee properly rendering (or especially - printing). PDF is supposed to be immutable and fixed/deterministic in its form, so it's a huge deal - and arguably a security hazard too - if some viewers render it inconsistently :(

And regarding form filling: I'm also aware of a separate requirement where SumatraPDF is used to actually edit the form inputs before saving a changed file, but this is not the case in this specific bug report.

Thank you very much for the analysis

[GitHubRulesOK]

I am not the developer but can say If the form is not well handled by MuPDF then it would be difficult to improve on that inbuilt ability so the simplest way to deal with forms is add

ExternalViewers [
	[
		CommandLine = c:\windows\system32\cmd.exe /r start="msedge.exe" --app="%1#page=%p"
		Name = Edge-i&t
		Filter = *.pdf
		Key = t
	]
]

and then for a form press T HOWEVER that Acrobat reader will NOT edit that form !! (There must be an inbuilt problem that stops it being edited)

[scscgit]

I'm not sure if you mean that we should be opening the PDF in Edge, or if you're trying to edit the form - because this exported PDF isn't supposed to have editable forms.

[GitHubRulesOK]

Agreed I don't read Slovakian but my understanding is that form is for print to paper then

Data is filled in with block letters (according to this pattern), typewriter, or printer, using black or dark blue ink.

If there is an enhanced official version on a SERVER then the SERVER fills it in

[scscgit]

Well yes, it's definitely a paper document, but organizations routinely exchange it in this digital form. I agree that these may be some very specific components generated on the server side, so sadly, it's any viewer's job to work through the trouble of any rendering standardization.

I also saw some client-editable forms like this one - a property tax document (from here), in which case the SumatraPDF rendering seems to work fine. It can't do the editing though (or even inform us that the document is editable at all), which is a shame anyway (so we have to keep relying on the browser's PDF tool for that - I pity people who aren't knowledgable in IT and only install one PDF tool to be always used by default).

[GitHubRulesOK]

I searched and am informed that for the first form
There are two official methods, both provided by the Slovak Financial Administration:

This is the only place where the online forms live.
Once logged in, you can access:
Daňové priznanie FO typ A (employees)
Daňové priznanie FO typ B (self‑employed, rental income, etc.)
The forms are interactive and submitted directly to the tax office.
You need one of these to log in:
Slovak eID card with chip
KEP (qualified electronic signature)
Login credentials issued by the portal
Without login, the forms are invisible.

for the form https://www.mfsr.sk/files/archiv/55/Priznanie_komplet_tlacivo.pdf you could open that from SumatraPDF but it needs Edge to fill it then SumatraPDF can display the changes the main issue is ensuring both are watching the same version

Using native MuPDF is counter intuitive as it does not display the fields just the input when editing So EDGE is ADOBE!

[GitHubRulesOK]

I have edited the form in an editor for general usage that means the text is accessible and visible offline here is the fixed file it should have text visible in SumatraPDF but that does not mean it can edit text it is a Reader.

formfixed.pdf

[scscgit]

Yes, once you use an external PDF tool, you can use SumatraPDF to view the edited fields in the second document. When I use Edge, I see the inputs editable directly, without the popup you displayed.

And yes, the "formfixed.pdf" is indeed displaying the correct diacritics of the letters - however, it also permanently destroys the official structure of the document, which is primarily intended for printing purposes and requires the exact rendering typography with absolutely no modification (because the source of truth is the document exported from the government website, where it's digitally signed and no longer editable).

[GitHubRulesOK]

The best bet is because it was frozen in a state that MuPDF considers half baked and you dont want it "repaired" to be usable then Adobe viewer in Edge is the closest to the Adobe 2010 product program in the server.

Title: DPFOAv25 v1.10
Created: 2/4/2010 1:08:24 PM
Application: PScript5.dll Version 5.2.2
PDF Producer: Acrobat Distiller 7.0 (Windows)