Hi Cornelis, > On 1 Sep 2015, at 05:26, Cornelis Hoeflake <c.hoefl...@postex.com> wrote: > > 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.
I guess I’m not quite sure why these custom fonts aren’t embedded in the PDFs already? You need custom fonts for rendering PDFs? And you expect these to change regularly? > 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. You might want to look at something like jimfs, which is an in- memory filesystem for Java. https://github.com/google/jimfs >>> 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. Then they should be embedding their fonts! >>> 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. I didn’t mention the API for FontProvider/Mapper... I mentioned the PDFont constructors and PDType1Font constants. Those are widely used APIs which depend upon having a static FontMapper. So, as I said, there’s some really important PDFBox APIs which will break if we change this. I’d like to see some suggestions for how we’re supposed to deal with that. — John >> — 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
