You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Cornelis Hoeflake <c....@postex.com> on 2014/10/29 10:35:29 UTC

Delegate ExternalFonts substitute 'magic'

Hi,

The ExternalFonts class does some magic. What I mean is the magic around
substitutes and windowsToPsName.

I have my own FontProvider and I want to do that things in my class (or
not). So why not create a delegating SubstitudeFontProvider which does this
substitude logic? And delegates the real get font methods to another
provider (in default case the current default FileSystemFontProvider).

I offer myself to implement this.

Kind regards,
Cornelis Hoeflake

Re: Delegate ExternalFonts substitute 'magic'

Posted by John Hewson <jo...@jahewson.com>.
Hi Cornelis

Yes, there is some magic, mostly in order to emulate the behaviour of Acrobat.
Generally speaking, it you were to subclass what we do here then you’re likely
to break compatibility with Acrobat, which is one reason why we don’t make it
possible. The other reason is that by exposing internal details as protected
members it makes us hard to change those details later without breaking the
API.

What is it that you want to do that ExternalFonts does not permit? We might
be able to add a specific API or suggest a better approach.

Thanks

-- John

> On 29 Oct 2014, at 02:35, Cornelis Hoeflake <c....@postex.com> wrote:
> 
> Hi,
> 
> The ExternalFonts class does some magic. What I mean is the magic around
> substitutes and windowsToPsName.
> 
> I have my own FontProvider and I want to do that things in my class (or
> not). So why not create a delegating SubstitudeFontProvider which does this
> substitude logic? And delegates the real get font methods to another
> provider (in default case the current default FileSystemFontProvider).
> 
> I offer myself to implement this.
> 
> Kind regards,
> Cornelis Hoeflake