You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "John Hewson (JIRA)" <ji...@apache.org> on 2015/02/10 00:48:34 UTC
[jira] [Comment Edited] (PDFBOX-2665) PDType1Font (HELVETICA)
encode getting NullPointerException
[ https://issues.apache.org/jira/browse/PDFBOX-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14313181#comment-14313181 ]
John Hewson edited comment on PDFBOX-2665 at 2/9/15 11:48 PM:
--------------------------------------------------------------
{quote}
I'm not too sure what the API should do, but all of the smart ways I've seen on Stackoverflow of formatting text use a technique of judging the width of a Font rendered String, by multiplying the getStringWidth() by a factor.
{quote}
There were bugs in 1.8 which I've seen worked-around in this manner. It's not a meaningful or correct workaround, but it clearly worked well enough for certain users. The underlying bugs have been fixed in 2.0 and all glyph metrics are now accurate.
{quote}
What I'd ideally like is for Type 1 fonts not to suck as much. If I have to deal with width estimation, I'll need a hashmap, to convert my Strings before they reach PDFBox.
{quote}
Type 1 fonts are old and deprecated, I'd recommend not using them at all. There's no estimation... we know the exact width of glyphs in any font format.
{quote}
For some reason I couldn't get \u0000 and \u0096 mapping, perhaps because they're too crazy for Java. I can't get a String to print out at all if it has a null character. I will take a look when I get back to work on Wednesday and let you know. It's some obvious bug but it might be a pdfbox issue yet.
{quote}
Java can handle those characters just fine but it might be a bug in PDFBox, if it looks that way, please do open a new issue for it. I doubt that any Type1 font contains these characters, but you should at least get an exception from PDFBox rather than a silent failure of a bad PDF.
{quote}
I think there should be a better way than whatever I'm doing, mapping Strings, and it should be a default implementation option, since I'd think it would be pretty common to deal with special characters and PDF fonts.
{quote}
There's no reasonable way to map strings: what satisfies one user may thwart another. It' just too subjective to be part of our API. What we could do is add an API so that you can check if a particular Unicode code point is supported by a font, e.g. boolean hasCodePoint(int codePoint). That way you can iterate through the characters in the string and do your own substitution.
{quote}
Like almost an ability to subclass the PdType1Fonts to add a default to the glyph map, so that I don't have to deal with exceptions.
{quote}
What are you going to do, map tab to a single space? That won't help much.
was (Author: jahewson):
{quote}
I'm not too sure what the API should do, but all of the smart ways I've seen on Stackoverflow of formatting text use a technique of judging the width of a Font rendered String, by multiplying the getStringWidth() by a factor.
{quote}
There were bugs in 1.8 which I've seen worked-around in this manner. It's not a meaningful or correct workaround, but it clearly worked well enough for certain users. The underlying bugs have been fixed in 2.0 and all glyph metrics are now accurate.
{quote}
What I'd ideally like is for Type 1 fonts not to suck as much. If I have to deal with width estimation, I'll need a hashmap, to convert my Strings before they reach PDFBox.
{quote}
Type 1 fonts are old and deprecated, I'd recommend not using them at all. There's no estimation... we know the exact width of glyphs in any font format.
{quote}
For some reason I couldn't get \u0000 and \u0096 mapping, perhaps because they're too crazy for Java. I can't get a String to print out at all if it has a null character. I will take a look when I get back to work on Wednesday and let you know. It's some obvious bug but it might be a pdfbox issue yet.
{quote}
Java can handle those characters just fine but it might be a bug in PDFBox, if it looks that way, please do open a new issue for it. I doubt that any Type1 font contains these characters, but you should at least get an exception from PDFBox rather than a silent failure of a bad PDF.
{quote}
I think there should be a better way than whatever I'm doing, mapping Strings, and it should be a default implementation option, since I'd think it would be pretty common to deal with special characters and PDF fonts. Like almost an ability to subclass the PdType1Fonts to add a default to the glyph map, so that I don't have to deal with exceptions.
{quote}
There's no reasonable way to map strings: what satisfies one user may thwart another. It' just too subjective to be part of our API. What we could do is add an API so that you can check if a particular Unicode code point is supported by a font, e.g. boolean hasCodePoint(int codePoint). That way you can iterate through the characters in the string and do your own substitution.
> PDType1Font (HELVETICA) encode getting NullPointerException
> -----------------------------------------------------------
>
> Key: PDFBOX-2665
> URL: https://issues.apache.org/jira/browse/PDFBOX-2665
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
> Affects Versions: 2.0.0
> Environment: Win 7, JDK 7, JBoss AS 7
> Reporter: Daniel Brownell
> Assignee: John Hewson
> Fix For: 2.0.0
>
>
> Hi,
> I have been trying to revert to previous pdfbox-2.0.0 versions, which is why the error is from a previous build, but this is applicable to the latest (2.0.0-20150204.015951-1042) too.
> I am getting this error, which I was not getting a month ago.
> Regards...
> Error: java.lang.NullPointerException
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:309) [pdfbox-2.0.0-20150129.080600-1013.jar:2.0.0-SNAPSHOT]
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:267) [pdfbox-2.0.0-20150129.080600-1013.jar:2.0.0-SNAPSHOT]
> at org.apache.pdfbox.pdmodel.PDPageContentStream.showText(PDPageContentStream.java:316) [pdfbox-2.0.0-20150129.080600-1013.jar:2.0.0-SNAPSHOT]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org