John,
I am facing basically the same issues as Cornelis.
Our application is running in a J2EE application server, so installing
anything into the operation system is usually not an option. It is already
difficult in a cluster environment managed by the customer, but becomes
virtually impossible in a dynamic cloud. Everything has to come from a
database. Some of our customers are (document) service providers working for
a bunch of other companies. There it is important to be able to use
different configurations for different groups of documents, because of
licencing and other reasons. Last but not least, the configuration
(available fonts) can be changed by storing some new resources into the
database. Restarting the application server (cluster) - so that a static
class gets instantiated again and reads the new configuration - is no
option.
Initialising FileSystemFontProvider can take 10 seconds or more, so it’s
not practical to create a new one for each document.
I do not care :-) I am not reading file system (usually not allowed to
anyway). And I know the place where to initialize and cache the fonts in my
application.
We could switch to having a per-document FontMapper or FontProvider, with
the default being to use a shared static provider
Would be perfect, I think.
Best regards,
Petr
-----Original message-----
From: Cornelis Hoeflake
Sent: Tuesday, September 01, 2015 2:26 PM
To: dev@pdfbox.apache.org
Subject: Re: Font provider since PDFBOX-2842
Sorry for my delayed reply, I missed your reply for some reason...
2015-08-24 20:54 GMT+02:00 John Hewson <j...@jahewson.com>:
Hi Cornelis,
> On 24 Aug 2015, at 02:20, Cornelis Hoeflake <c.hoefl...@postex.com>
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?
My customers have licensed (and custom made) fonts. So the first issue is
that a license for customer 1 is not valid for customer 2. The next problem
is dat the name of custom made fonts does not have to be globally unique.
The last problem is that the server environment is provisioned on services
like Amazon Elastic Beanstalk wit autoscaling etc. In that case there is no
decent option to copy fonts to the 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.
Ok, that is a nice feature. But for my case customers want the correct
font, not a best-fit.
> 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 have set a custom made 'general' FontProvider. Before doing any operation
which uses ExternalFonts.getProvider(), I set a customer FontProvider
(which knows all about the fonts of that customer) in a ThreadLocal in de
'general' FontProvider. The 'general' FontProvider delegates each request
to the customer FontProvider.
> 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.
Yes, that is true... On the other hand, more and more server software
products are switching to services like Amazon Elastic Beanstalk etc. And
last but not least, the API for FontProvider/Mapper and the previous
ExternalFonts is already broken. Withint 2.0 and between 1.8 and 2.0.
— John
> Kind regards,
> Cornelis Hoeflake
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
