pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thad Humphries <thad.humphr...@gmail.com>
Subject Re: U+000A ('controlLF') is not available in Helvetica
Date Mon, 03 Jul 2017 20:09:15 GMT
On Mon, Jul 3, 2017 at 11:42 AM, Tilman Hausherr <THausherr@t-online.de>
wrote:

> Am 03.07.2017 um 17:37 schrieb Thad Humphries:
>
>> I'm getting an error when trying to print text created by Windows:
>>
>> Servlet failed with an Exception
>> java.lang.IllegalArgumentException: U+000A ('controlLF') is not available
>> in this font Helvetica (generic: NimbusSanL-Regu) encoding:
>> WinAnsiEncoding
>> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Fon
>> t.java:406)
>> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:316)
>> at org.apache.pdfbox.pdmodel.font.PDFont.getStringWidth(PDFont.java:345)
>> ...
>>
>>
>> As you know, Windows uses CRLF (0x0D0A) for end-of-line, but
>> PDType1Font.HELVETICA does not seem to recognize 0x0A. This seems like a
>> bug with the font.
>>
>> Is there a fix for this? I'd rather not have to search all text to remove
>> 0x0A.
>>
>
> It's not a bug. There is no glyph for CR LF. You need to clean up your
> input.
>
> Tilman
>

Thanks. I see that logic, though I think they should be ignored vs throwing
an exception.

As is, the Windows application I'm reading output from is creating many
troublesome horizontal and vertical whitespace errors. I've managed to
purge them with String.replaceAll(regex, replacement).

-- 
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v. 121-24)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message