Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

PdfWriter writes non-conformant `/MarkInfo << /Marked true >>` instead of `/MarkInfo << /Tagged true >>` (ISO 32000-1)

Open Beginner friendly
  • Is something wrong?
#1,643 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
backend

Research direction

In PdfName, the MARKED constant is defined, and PdfWriter.getCatalog(PdfIndirectReference) uses it when building the catalog’s MarkInfo dictionary. Read those two locations, then check the generated catalog after calling PdfWriter.setTagged(). Done when it contains /Tagged true as specified, rather than /Marked true.

Written by the indexing model from the issue text.

Description

bug
Describe the bug

When a document is marked as tagged via PdfWriter.setTagged(), the catalog of the generated PDF contains:

/MarkInfo << /Marked true >>

According to ISO 32000-1:2008 §14.8.2 (Mark Info), the entry that marks a tagged document in the MarkInfo dictionary is Tagged:

Tagged (Optional; PDF 1.4) — A boolean indicating whether the document contains semantic information that aids accessibility (true) or not (false).

The name Marked is not defined by the specification. The structural tree (StructTreeRoot) is generated correctly, but the flag that tells viewers and assistive technology the document is tagged is invalid — so documents produced with setTagged() are not recognized as tagged by PDF validators and PDF/UA (ISO 14289) conformance checks. In practice this makes it impossible to produce conformant tagged / PDF/UA documents with this library.

org.openpdf.text.pdf.PdfName (line 1677):

public static final PdfName MARKED = new PdfName("Marked");

consumed by org.openpdf.text.pdf.PdfWriter.getCatalog(PdfIndirectReference) (line 1056):

PdfDictionary mi = new PdfDictionary();
mi.put(PdfName.MARKED, PdfBoolean.PDFTRUE);
...
catalog.put(PdfName.MARKINFO, mi);

The value appears to have been carried over from iText 2.1.x, where the same non-conformant constant exists.

To Reproduce
Document doc = new Document();
PdfWriter writer = PdfWriter.getInstance(doc, new FileOutputStream("out.pdf"));
writer.setTagged();
doc.open();
doc.add(new Paragraph("Hello tagged PDF"));
doc.close();
Expected behavior
/MarkInfo << /Tagged true >>

Suggested fix

public static final PdfName MARKED = new PdfName("Tagged");
System
  • OS: Windows
  • Used font: Helvetica
  • OpenPDF version: 3.0.5
Additional context

PdfName.MARKED has exactly two occurrences in the 3.0.5 source: its definition and PdfWriter.getCatalog — nothing in the library ever reads this entry back, so changing the constant to the spec value "Tagged" only affects newly written documents (and documents written with /Marked were non-conformant to begin with, so there is no conformant reading behaviour to preserve). Suggested one-line fix:

public static final PdfName MARKED = new PdfName("Tagged");
Dominant language
Java
Stars
4.4k
Forks
714
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LibrePDF/OpenPDF

All issues in LibrePDF/OpenPDF

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.