[
https://issues.apache.org/jira/browse/FOP-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15526559#comment-15526559
]
Glenn Adams commented on FOP-2650:
----------------------------------
What you don't emphasize sufficiently is that this is only a problem when you
wish to run multiple renderers in the same VM. As this is an unusual usage
scenarios, such an optimization has not arisen previously (or if it has, then
it had a low priority). Given there is already a font cache, what you are
suggesting is a second cache level that shares font instances among renderers.
Since as you point out, current font instances record usage data for a given
rendering and use that to drive the font subsetting process, such usage data
would have to be moved into a Map that represents <renderer,per-renderer usage
data> pairs.
> Cache CustomFont instances
> ---------------------------
>
> Key: FOP-2650
> URL: https://issues.apache.org/jira/browse/FOP-2650
> Project: FOP
> Issue Type: Improvement
> Components: font/unqualified
> Reporter: Simone Rondelli
> Priority: Minor
>
> Custom fonts are loaded through the {{FontLoader}} class on every rendering
> (for every renderer). For big font files (Eg. Chinese/Japanese/Korean fonts)
> this can be a really CPU intensive operation.
> The aim of this improvement is to implement a cache mechanism that will cache
> the Font Instances or the informations contained into them.
> NB: The class {{Typeface}} has a {{charMapOps}} field that keeps track of the
> usage of the font during the rendering. This field is used in
> {{PDFResource.addFonts()}} to determine whether to include the Font into the
> PDF file. Caching this value will lead to problems.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
