Just a reminder from your favorite standards person… While it is permissible (well, not mentioned as such) to substitute a local font for an embedded font in ISO 32000 (aka regular PDF), it is FORBIDDEN in all of the subset standards. So if you are going to be rendering PDF/A, PDF/X, etc. - you MUST use the embedded font program.
Leonard On 9/3/15, 3:43 PM, "Petr Slabý" <[email protected]> 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. > >Now searching for question marks in your previous mail: > >> So you have fonts for specific customers for rendering only their >> documents and you expect those to change frequently? > >Not frequently, but yes, they can change. The frequency does not matter then >as the change has to be immediate while the application server cluster is >restarted only once or twice a year. > >> Really? > >Yes. > >> 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. > >> 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. > >> 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. > >> 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. > >Best regards, >Petr. > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
