Home/ Questions/Q 8931029
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T09:01:09+00:00

Setup I’m using iText 5.3.0 and Fedora 17, testing with PDF readers llpp and

  • 0

Setup

I’m using iText 5.3.0 and Fedora 17, testing with PDF readers llpp and evince. My IDE is Eclipse Indigo r2. My terminal is urxvt with the same font as used in the PDF.

Problem

Other unicode characters show just fine. Listing 11.3 in the iText book shows just fine. But trying to get an X̲, X with an underline, like "X\u0332" won’t show up on a PDF. I can log the string to the terminal with System.out.println and it works just fine. Here’s an example of what I’m trying:

public static void main(String[] args) throws DocumentException, IOException {
  Document document = new Document(PageSize.LETTER);
  PdfWriter.getInstance(document, new FileOutputStream("fnord.pdf"));
  document.open();
  FontFactory.register("fonts/mplus-1mn-regular.ttf", "mplus");
  Font font = FontFactory.getFont(
    "mplus",
    BaseFont.IDENTITY_H,
    BaseFont.EMBEDDED,
    12
  );
  String s = "X\u0332";
  System.out.println(s);
  document.add(new Paragraph(s, font));
  document.close();
}

I found an ancient, possibly related, email from Paulo Soares saying “character combination must be done before presenting the text to iText”.

I’m not sure what this means, or how to do it, or if it’s still relevant.

Expected / actual

I expect: a PDF with an X with a line underneath the X, ie X̲.

I get: a PDF with an X, no line.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It seems that my pdf viewers aren’t displaying right. I copied and pasted the text output from the pdf viewer, copied into my terminal (where I’ve verified this character(s) work), and see the X̲.

    Copy and pasting works in

    • llpp with mupdf version a606f714258677688c67e9561b87cc70f9e9b6b0
    • adobe reader 9.5.1

    But does not work in evince 3.4.0 (poppler 0.18.4). The copied text is just a plain X.

    So it seems that iText is not at fault.

    • 0