[jira] [Comment Edited] (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=14221689#comment-14221689 ] 

John Hewson edited comment on PDFBOX-2467 at 11/22/14 1:15 AM:
---------------------------------------------------------------

PDFBox has a built-in substitution from "Arial,Bold" to "Helvetica-Bold" and so you end up with Helvetica instead of Arial. As you say, this is due to the standard 14 adding mechanism in ExternalFonts. The copySubstitutes method adds the original Type 1 font name as the first substitute, so the first substitute for "Arial,Bold" is ""Helvetica-Bold", even though the first substitute for "Helvetica-Bold" is "Arial-BoldMT".

It seems unlikely that this first substitute is actually going to exist on many systems, whereas the well-known fallbacks (e.g. Arial, Liberation sans, Numbus Sans) usually do. Given that the alternative names are all Microsoft fonts, it makes sense _not_ to add the original Type 1 name as the first substitute. That means that the first substitute for "Arial,Bold" will now be "Arial-BoldMT", which should work nicely.

This should be a one-line fix to copySubstitutes().


was (Author: jahewson):
PDFBox has a built-in substitution from "Arial,Bold" to "Helvetica-Bold" and so you end up with Helvetica instead of Arial. As you say, this is due to the standard 14 adding mechanism in ExternalFonts. The copySubstitutes method adds the original Type 1 font name as the first substitute, so the first substitute for "Arial,Bold" is ""Helvetica-Bold", even though the first substitute for "Helvetica-Bold" is "Arial-BoldMT".

It seems unlikely that this first substitute is actually going to exist on many systems, whereas the well-known fallbacks (e.g. Arial, Liberation sans, Numbus Sans) usually do. Given that the alternative names are all Microsoft fonts, it makes sense _not_ to add the original Type 1 name as the first substitute. That means that the first substitute for "Arial,Bold" will now be "Arial-BoldMT", which should work nicely.

This should be a 1-line fix to copySubstitutes().

> 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
>            Assignee: John Hewson
>             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)