Hi Cornelis,
> On 24 Aug 2015, at 02:20, Cornelis Hoeflake <[email protected]> wrote:
>
> Hi,
>
> In the before PDFBOX-2842 situation we set the FontProvider on
> ExternalFonts to a thread bound font provider (uses ThreadLocal).
> This is done because we have a systemen where multiple customers which have
> their own fonts. That fonts could also dynamically added to the system at
> runtime. We have implemented the FontProvider so that it looks in the
> database for a font request.
My first question is: do you really need this? What fonts are your users
uploading and
why are they missing from PDFs? Could you make them available in some other way?
Do the fonts really need to be locked down to a given user? Why not keep it
simple and
copy the font files to the local system?
> In the new situation FontMapper reads the font information once (at
> setProvider) and uses this global for the whole system.
The old approach, ExternalFonts used the font name to perform a direct lookup,
delegating this to the FontProvider. The new FontMapper performs a best-fit
lookup using multiple attributes such as the name, ROS, weight, family, unicode
ranges, style, and panose classification. This requires that we first build an
index
of those attributes for each font.
> How can we create a situation like we had but then with the new code? I do
> not see an option.
Could you explain how you’re currently using ThreadLocal? There might be a
workaround. Failing that we could provide a mechanism to allow the font index
to be updated dynamically.
> I think it is a good idea to drop static FontMapper, FontProvider etc. And
> replace it with a given FontProvider/Mapper at start of a document.
Initialising FileSystemFontProvider can take 10 seconds or more, so it’s not
practical
to create a new one for each document. We could switch to having a per-document
FontMapper or FontProvider, with the default being to use a shared static
provider,
with the user being able to set their own, however we have static APIs which
require
a FontMapper to exist independently from a document, namely:
- all PDFont subclass constructors
- PDType1Font constants (TIMES_ROMAN, HELVETICA, COURIER, etc.)
I don’t see any way to make the changes you’re after without breaking all those
APIs.
— John
> Kind regards,
> Cornelis Hoeflake
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]