Hi, I have a new solution for this problem. I’m going to make FontMapper into an interface and have a singleton instance available via FontMappers.instance(). You’ll be able to provide your own implementation via FontMappers.set(FontMapper) and the current FontMapper code will be moved to FontMapperImpl, which will be provided as a static default when FontMappers.instance() is called for the first time without a prior call to FontMappers.set.
The FontMapper interface simply contains the following three methods: FontMapping<TrueTypeFont> getTrueTypeFont(String baseFont, PDFontDescriptor fontDescriptor); FontMapping<FontBoxFont> getFontBoxFont(String baseFont, PDFontDescriptor fontDescriptor); CIDFontMapping getCIDFont(String baseFont, PDFontDescriptor fontDescriptor, PDCIDSystemInfo cidSystemInfo); You can put whatever implementation you like in there. See PDFBOX-2997 for more details. — John P.S. I’ve looked into having a per-document FontMapper or similar but in PDFBox fonts are not tied to a specific document, so it just won’t work. ThreadLocal lets you get round that though, given that PDDocument is single-threaded anyway. So you should be all set. > On 4 Sep 2015, at 03:22, Cornelis Hoeflake <c.hoefl...@postex.com> wrote: > >> 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
