[
https://issues.apache.org/jira/browse/PDFBOX-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14313181#comment-14313181
]
John Hewson commented on PDFBOX-2665:
-------------------------------------
{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-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
