[
https://issues.apache.org/jira/browse/PDFBOX-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hewson updated PDFBOX-2842:
--------------------------------
Description:
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.
was:
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.
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
