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