Sorry, please can you answer all of the questions in my previous mail or I can’t help you.
— John > On 2 Sep 2015, at 03:03, Petr Slabý <sl...@kadel.cz> wrote: > >> As with Cornelis, I’d direct you to look at jimfs, which is an in- memory >> filesystem for Java > > That is not needed, I think. All I need to do is to implement FontProvider on > top of our internal resource provider API which reads the stuff from the > database. But I need multiple instances of FontMapper/FontProvider in one JVM > (because more than one application/customer can be running in the > application server instance) and I need to be able to flush the FontMapper if > the configuration changes and the FontProvider has new files. > >> So you have fonts for specific customers for rendering only their documents >> and you expect those to change frequently? >> Really? Why don’t your customers embed such fonts? ... > > Customers do all kind of wild things. Most usually, the PDFs we are dealing > with are supposed to be PDF/A, so there is no problem. But I have already > seen PDFs in a company's archive which were using external fonts. Or > customers with an old application nobody is able to touch, producing such > PDFs. I cannot send the customer to hell then. > > The fonts do not change frequently, of course. But as the Universe wants it, > a missing font or wrong configuration is never found on a test system. It > happens somewhere in the production and then it is really impossible to > restart the JVM. > > In any case, external fonts are possible and in a perfect solution I need to > cover the two previously mentioned use cases - multiple FontMapper instances > in a single JVM and a change of fonts available to a FontMapper after it has > already been initialized. > > As a minimal solution, it should be enough for me if I can re-initialize the > FontMapper using a new instance of FontProvider. It will be tricky to make it > thread safe, but I hope I will manage to do that using a "readers–writer > lock" pattern. This does not cover the multiple different configurations case > very well (or at all because only a single configuration can be used for > concurrent renderings), but at least enables to change the configuration at > runtime. Maybe this should already work if I use FontMapper.setProvider()? > > Unfortunately, PDFBox 2.0 release escaped our own release cycle by one year > once again, so I will have no resources to really try to implement against > the new version until somewhere in the next year. If you say having a > non-static FontMapper would break all the APIs and postpone the 2.0 release > by yet another year, I will rather live with what we have now. > > Best regards, > Petr. > > -----Původní zpráva----- From: John Hewson > Sent: Wednesday, September 02, 2015 4:43 AM > To: dev@pdfbox.apache.org <mailto:dev@pdfbox.apache.org> > Subject: Re: Font provider since PDFBOX-2842 > > >> On 1 Sep 2015, at 06:12, Petr Slabý <sl...@kadel.cz> wrote: >> >> 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. > > As with Cornelis, I’d direct you to look at jimfs, > https://github.com/google/jimfs <https://github.com/google/jimfs> > <https://github.com/google/jimfs <https://github.com/google/jimfs>> which is > an in- memory filesystem for Java. You could pull fonts from your database > into there. Maybe one directory for each customer. > >> 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. > > So you have fonts for specific customers for rendering only their documents > and you expect those to change frequently? Really? Why don’t your customers > embed such fonts? > > Are you talking about providing “desired” mappings, e.g. allowing “Helvetica” > to be mapped to the customer’s own “Helvetica.ttf” or are you talking about > support for custom fonts, e.g. “MyCorporateFont.ttf”? > > Are you wanting to customise the substation behaviour, or just provide > additional font files? > >> 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. > > Yes, obviously you don’t want to have to restart. So we do need some way in > PDFBox to allow the FontMapper to be re-initialized at runtime. Note that > PDFBox no longer requests one font at a time, it requests all fonts because > we need to examine all fonts to find the best match. You’re also going to > need to store all of the font metadata in your database, so that your custom > FontProvider can pull all of it when it’s initialised. That means all of the > fields in the FontInfo class need to be present in your database. > >>> 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. > > Everyone else does care if it takes 10sec to open every PDDocument but... > >>> 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. > > … this mitigates that issue, so it should be fine. > > — John > >> 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 >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org > <mailto:dev-unsubscr...@pdfbox.apache.org> > For additional commands, e-mail: dev-h...@pdfbox.apache.org > <mailto:dev-h...@pdfbox.apache.org>
