[ 
https://issues.apache.org/jira/browse/FOP-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455902#comment-15455902
 ] 

Simone Rondelli edited comment on FOP-2644 at 9/1/16 4:22 PM:
--------------------------------------------------------------

Thanks Adam for clarification. The reason why I was trying to us the Font 
Metrics was to force the Java2D based renderer to use a lazy font otherwise, as 
I stated in my previous comment, I have a too high memory/CPU overhead all 
related to font reading. The point is that I have a stack of 20 fonts but not 
all of them are used at the same time in the same document. With the LazyFont I 
can spread the loading overhead in a bigger window of time. This indeed works 
for the PDF renderer but not for the PNG renderer that is not able to 
instantiate a LazyFont instance without the Font Metrics 
({{org.apache.fop.render.java2d.ConfiguredFontCollection}}).

My questions are:

* What would be a way to get the 
org.apache.fop.render.java2d.ConfiguredFontCollection to generate LazyFont 
without the Font Metrics? For my understanding the reason why the Font Metrics 
are necessary is that the LazyFont is read immediately after its creation 
({{font = new CustomFontMetricsMapper(fontMetrics, fontSource);}}) forcing the 
reading of the Font Metrics if available (fast) or the reading of the Font file 
(slow). A possible solution could be to create something like 
LazyFontMetricsMapper.
* Why every renderer reload the font from scratch? If I have 20 fonts and 8 
renderers it means that we have 160 font reading (with huge memory/CPU impact) 
while there could be just 20 font reading. Wouldn't it be better to just share 
the font informations across the renderers?





was (Author: rondelli):
Thanks Adam for clarification. The reason why I was trying to us the Font 
Metrics was to force the Java2D based renderer to use a lazy font otherwise, as 
I stated in my previous comment, I have a too high memory/CPU overhead all 
related to font reading. The point is that I have a stack of 20 fonts but not 
all of them are used at the same time in the same document. With the LazyFont I 
can spread the loading overhead in a bigger window of time. This indeed works 
for the PDF renderer but not for the PNG renderer that is not able to 
instantiate a LazyFont instance without the Font Metrics 
({{org.apache.fop.render.java2d.ConfiguredFontCollection}}).

My questions are:

* What would be a way to get the 
org.apache.fop.render.java2d.ConfiguredFontCollection to generate LazyFont 
without the Font Metrics? For my understanding the reason why the Font Metrics 
are necessary is that the LazyFont is read immediately after its creation 
({{font = new CustomFontMetricsMapper(fontMetrics, fontSource);}}) forcing the 
reading of the Font Metrics if available (fast) or the reading of the Font file 
(slow). A possible solution could be to make LazyFont to implements 
FontMetricsMapper or to create something like LazyFontMetricsMapper.
* Why every renderer reload the font from scratch? If I have 20 fonts and 8 
renderers it means that we have 160 font reading (with huge memory/CPU impact) 
while there could be just 20 font reading. Wouldn't it be better to just share 
the font informations across the renderers?




> Generated font metrics do not contains GSUB, GPOS, GDEF tables
> --------------------------------------------------------------
>
>                 Key: FOP-2644
>                 URL: https://issues.apache.org/jira/browse/FOP-2644
>             Project: FOP
>          Issue Type: Bug
>          Components: font/opentype
>    Affects Versions: 2.1
>         Environment: All OS/Platforms affected
>            Reporter: Simone Rondelli
>
> In order to reduce the memory footprint of an ApacheFOP based application, 
> where I have several Java2D based renderers, I created the XML metrics for 
> the fonts used (more then 20). This way 
> {{org.apache.fop.render.java2d.ConfiguredFontCollection}} creates instances 
> of {{LazyFont}}.
> THE PROBLEM:
> The generated metrics.xml do not contain the GSUB, GPOS, GDEF tables info . 
> This led to an incorrect generated output. 
> Eg: instead of this  🇮🇹  the generated pdf has 🇮 🇹. 
> (I'm working on a for ApacheFOP that supports Surrogate Pairs and I'm testing 
> it with Emojis FOP-1969)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to