Search code examples
androidpdftextfont-face

Getting strange results with PdfDocument on single android device


In an android app I'm using PdfDocument to save a report to a pdf file. On a customer's device I'm getting a strange result with the text of the report.

The following is image of header with the following text rendered in DroidSansMono:


Baus Demo Company
4727 4TH AVE SW STE 202
Seatle, WA 9816
Tel: 206-932-986
Fax: 206-932-986

Header

I this same process renders well on most devices. I checked the pdf file and it has the correct font.

here is the full PDF file: PDF File

Can anyone help me figure out why the text is rendered so?


Solution

  • The reason for this weird look is that this is exactly the formatting the PDF describes.

    Horizontal scaling

    The content stream of the page consists of three sections:

    The top section, all text above the image of a signature, contains at the beginning the instruction

    2000 Tz
    

    Inside the section after some text a 1000 Tz follows, then again a 2000 Tz and yet again a 1000 Tz.

    The Tz operator sets the horizontal scaling to the preceding number as a percentage value. Thus, these instruction cause all following text (until the end of the section where the graphics state is reset) to be horizontally stretched by a factor of either 10 or 20!

    This explains why the glyphs are so wide but not why they overlap so much.

    Glyph widths and positioning

    The reason why they overlap so much is that each glyph is individually positioned at a distance appropriate for a layout without horizontal scaling.

    First of all, the DroidSansMono font information in the PDF declare that virtually all glyphs in the font have a width of 0. Thus, whenever a glyph is drawn, the text insertion point does not wander along to the glyph's end but remains at its start.

    Furthermore, each glyph is drawn using an individual operation and between two such single glyph drawing operations the text insertion point is advanced by a separate instruction. But the distance parameter of this instruction is appropriate for the glyphs without horizontal scaling!

    This causes all the overlaps.


    If this very PDF is rendered "well" (i.e. incorrectly ignoring the Tz operations) on most devices, the PDF renderer used on those devices clearly does a lousy job of PDF rendering.