[
https://issues.apache.org/jira/browse/PDFBOX-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14604641#comment-14604641
]
Tilman Hausherr commented on PDFBOX-2842:
-----------------------------------------
Most are now OK, but not all. The exception with
GWG091_FontSupport-OpenType_X4.pdf is still there;
PDFBOX-142-acroform,pdf: font on top not bold
PDFBOX-870-a_metro-vlc.pdf: station names with non serif font
PDFBOX-1422.pdf: different font at the bottom
PDFBOX-1743.pdf: complete mess
PDFBOX-2307-159827.pdf, page 2, 5, 8, 11, 14, 17, 19, 20, 21, : boxes instead
of "........"
PDFBOX-2499-076595-p74.pdf: footnote
PDFBOX-2526.pdf: Arial black different
PDFBOX-2642-277053-p3.pdf: bad font
PDFBOX-2573-865252-p4.pdf:
{code}
java.lang.NullPointerException
at
org.apache.pdfbox.pdmodel.font.FontMapper.getFontBoxFont(FontMapper.java:333)
at
org.apache.pdfbox.pdmodel.font.PDType1Font.<init>(PDType1Font.java:221)
at
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:96)
at
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:50)
{code}
> Overhaul font substitution
> --------------------------
>
> Key: PDFBOX-2842
> URL: https://issues.apache.org/jira/browse/PDFBOX-2842
> Project: PDFBox
> Issue Type: Improvement
> Components: FontBox, PDModel
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Assignee: John Hewson
> Fix For: 2.0.0
>
>
> The improved font substitution mechanisms in 2.0 are not quite sufficient to
> handle all PDFs. Specifically, CJK substitution and substitution of TTF in
> place of CFF fonts is not possible with the current design.
> The CJK problems can be seen in PDFBOX-2509 and PDFBOX-2563, which does not
> solve the problem. Additional font API weaknesses can be found in PDFBOX-2578
> and PDFBOX-2366. This meta-issue aims to address all of those sub-issues.
> The current problems are:
> - FontBox does not provide a generic font type, so we have handle
> TrueTypeFont, CFFFont, and Type1Font separately. This hinders cross-format
> substitution.
> - ExternalFonts has no knowledge of the CIDSystemInfo which is necessary for
> CJK substitution
> - FontProvider contains too much public logic which should be internal to
> PDFBox, e.g. substitution logic, this makes it brittle and means we won't be
> able to add additional logic after 2.0 is released, e.g. CJK substitution.
> - Too much confusion about the role of ExternalFonts, particularly with
> regards to mapping of built-in fonts and the definition of substitute vs.
> fallback font.
> - ExternalFonts is a black box: the user cannot tell whether the font
> returned is an exact match, or a last-resort fallback.
> - Confusing font substitution API, users preferred having a flat file format
> - PDSimpleFont#getEncoding() can return null for TTFs which use built-in
> encodings. This has caused a lot of bugs - there must be a better way.
> - We still have some confusing names, for example a CustomEncoding is known
> as a "built-in encoding" in the spec.
> - There is no fallback CFF font, we resort to AdobeBlank instead, which has
> no rendering.
--
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
