pdfbox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Hewson (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (PDFBOX-2467) Remove substitute logic from ExternalFonts
Date Sat, 22 Nov 2014 01:15:34 GMT

    [ 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)

Mime
View raw message