> Hi, > > Sorry, please can you answer all of the questions in my previous mail or I >> can’t help you. >> > > Not sure whether I need any help right now. All I wanted to do is to vote > for the "per-document FontMapper or FontProvider" solution and explain some > reasons for that. >
I'm still searching for a solution, so any help is welcome! > Why don’t your customers embed such fonts? >> > > Because they have the PDFs in an archive created 20 years ago or they get > the PDF from a funny marketing department which they are not able to teach > anything or ... For all kinds of reasons. Same here. And another case is that the customers now send their PDF's to a printing house. Some printing houses don't like embedded fonts because they take more memory on their printer. 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”? >> > > Both. Both. Really? Yes > Are you wanting to customise the substation behaviour, or just provide >> additional font files? >> > > Both, although in most use cases the need is just to provide > “MyCorporateFont.ttf” for the font "MyCorporateFont" that is referenced > from PDFs produced by some reporting tool or whatever fancy source of > external PDFs. In our configuration, one can setup font name aliases, which > could be used to avoid the heuristics done in FontMapper.findFont. We use > it that way in our PDFBox 1.7 based solution. Both Initialising FileSystemFontProvider can take 10 seconds or more, so it’s >> not practical to create a new one for each document. >> > > Just to avoid misunderstanding of my previous comment on this. I do care > about the speed of a document rendering of course. But > FileSystemFontProvider is of no use for me. I have to initialize the font > provider myself, from our configuration and from fonts in our database. I > do not want to do that per document, but I have to do that again each time > when the configuration changes. No matter whether frequentyl or just from > time to time, but for sure not just once per lifetime of a JVM. > In my case, I do not want to initialize a FontProvider which takes 10 seconds and does all that matching algorithms you named. I want to substitute the FontProvider/Mapper with a custom one where I can do that myself. We are not looking for a best match, but for the only perfect match. And if there is no perfect match, the system has to throw an error. We render thousands of PDFs of hundreds of customers in a short time range. So memory wise we will not be happy if we have to instantiate hundreds FontProviders/Mappers which all have loaded fonts and keep them in memory because the startup costs are to high. A per document solution is in my opinion the holy grail. But as John said that will brake a lot of API's, i agree. But a solution like we had on 2.0 some weeks ago is also working for me (which I implemented with a ThreadLocal) and without the best-fit font matching algorithms. Kind regards, Cornelis
