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] [Commented] (PDFBOX-2467) Remove substitute logic from ExternalFonts
Date Sat, 01 Nov 2014 18:58:33 GMT

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

Mime
View raw message