[jira] [Commented] (PDFBOX-2467) Remove substitute logic from ExternalFonts

["John Hewson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PDFBOX-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193359#comment-14193359 ] 

John Hewson commented on PDFBOX-2467:
-------------------------------------

{quote}
As user of PDFBox I want to have the control over substitutes.
{quote}

Actually you don't, because you'll just end up breaking compatibility with Acrobat, or worse: with the ISO PDF spec. The PDF spec defines a number of built-in fonts, and some other fonts which are "well known" and have special handling. Arial is one of these, and so PDFBox manages the substitutions itself. We aim to have working substitutions to fonts which ship by default with Mac/Win/Linux.

It sound like what you really want to do is report a bug with our built-in substitution for Arial:

{quote}
For example when a PDF has font TrueType Arial,Bold (windows style), and my font provider has only a Type1 font for Arial Bold, the current mechanism returns the Helvetica Bold font True Type font (if have one in my font provider).
{quote}

You'd be better off installing the TTF for Arial on your system, because Arial is natively a TTF font, it's very strange for you to have a Type 1 Arial. What's your setup? How did you end up with those fonts?

> Remove substitute logic from ExternalFonts
> ------------------------------------------
>
>                 Key: PDFBOX-2467
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-2467
>             Project: PDFBox
>          Issue Type: Improvement
>    Affects Versions: 2.0.0
>            Reporter: Cornelis Hoeflake
>             Fix For: 2.0.0
>
>         Attachments: patch1.diff, patch2.diff
>
>
> The ExternalFonts class does some substitute logic for fonts. There is a static map which holds the substitutes and is loaded in the ExternalClass file and some substitutes are got from Standards14.
> Next that map also contains some substitutes for registry fonts (I don't know what it is), but it feels a bit like misusing the substitutes mechanism (with prepending a $ to omit conflicts).
> As user of PDFBox I want to have the control over substitutes. For example when a PDF has font TrueType Arial,Bold (windows style), and my font provider has only a Type1 font for Arial Bold, the current mechanism returns the Helvetica Bold font True Type font (if have one in my fontprovider).
> So I wrote a patch which allows you to wrap a fontprovider in a SubstituteFontProvider. That SubstituteFontProvider does the substitute logic like ExternalFonts did before. The user is in control to wrap (or let ExternalFonts wrap) his own fontprovider in the SubstituteFontProvider.
> The registry fonts issue is kept in ExternalFonts and uses an own map.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)