Hmm, that may not be a very representative example, since:
- Arial Unicode MS is one of the largest fonts (23MB, 50377 glyphs)
- read{GDEF,GSUB,GPOS} is a one-time event when reading the font
It would be useful for you to try:
- one page versus 2000 pages
- same but with another font, such as Arial or Times New Roman
In any case, I do not expect there to be any optimization opportunities in
read{GDEF,GSUB,GPOS} other than possibly pre-compiling this data and storing
it in the FOP font cache for future reuse.
G.
On Tue, Jul 19, 2011 at 8:21 AM, mehdi houshmand <[email protected]> wrote:
> Hi Glenn,
>
> What we did isn't very complex, a 2000-odd page document filled with
> Loret ipsum... That's about it, the font used was ArialUnicodeMS.ttf
> and was embedded in the PDF. The version was i18n.arabic@09c38b8b and
> the major blocking point was in TTFFile.java readGDEF(in) readGSUB(in)
> and readGPOS(in). Commenting these out reduced the performance impact
> from 150% to 110% as compared to trunk.
>
> Mehdi
>
> On 19 July 2011 15:02, Glenn Adams <[email protected]> wrote:
> > I'm not sure what you mean by "the layout tests don't cover fonts,
> > rendering". While it is true that those tests do not cover rendering, it
> > does include use of fonts.
> > Could you send me the "large latin only document" in FO form (preferably
> > compressed if large), so I may test it?
> > G.
> >
> > On Tue, Jul 19, 2011 at 7:51 AM, mehdi houshmand <[email protected]>
> wrote:
> >>
> >> Hi Glenn,
> >>
> >> We took a look at the complex scripts support, and a big chunk of the
> >> code-base is in the fonts, and the layout tests don't cover fonts,
> >> rendering etc. What are you finding for end-to-end performance? We
> >> created a large latin only document and found about 50% increase in
> >> time.
> >>
> >> Mehdi
> >>
> >> On 19 July 2011 14:36, Glenn Adams <[email protected]> wrote:
> >> > Taking the average of the best 3 out of 5 runs for a couple of the
> junit
> >> > tests, I get the following:
> >> > TRUNK CMPLX DIFF%
> >> > junit-basic 4.87s 4.92s 1.01%
> >> > junit-layout-standard 36.34s 36.72s 1.04%
> >> > In the case of junit-layout-standard, there are 25 more tests run in
> the
> >> > Complex Script branch.
> >> > So, I'd say that there is about a 1% decrease in speed performance
> based
> >> > on
> >> > this data.
> >> > I doubt if users will even notice this, so this would argue for
> enabling
> >> > by
> >> > default.
> >> >
> >> > On Tue, Jul 19, 2011 at 2:08 AM, Pascal Sancho <
> [email protected]>
> >> > wrote:
> >> >>
> >> >> Hi Glenn,
> >> >>
> >> >> IMHO, the default setting should depend on how much it affects the
> >> >> performances.
> >> >> Can you give an approximative impact?
> >> >>
> >> >>
> >> >> Le 19/07/2011 03:40, Glenn Adams a écrit :
> >> >> > I'm adding a feature to allow enable/disable of complex script
> >> >> > features
> >> >> > (bidi, complex char to glyph mapping) at runtime, using either (or
> >> >> > both)
> >> >> > command line option and config file element; the question I have is
> >> >> > whether to enable or disable by default?
> >> >> >
> >> >> > If enabled by default, those who don't use complex scripts or don't
> >> >> > want
> >> >> > advanced typography features in non-complex scripts will incur a
> >> >> > minor
> >> >> > performance penalty.
> >> >> >
> >> >> > If disabled by default, then those users who use complex scripts or
> >> >> > want
> >> >> > advanced typography features in non-complex scripts will need to do
> >> >> > something special to enable this support.
> >> >> >
> >> >> > What does the group think? I don't have a strong preference either
> >> >> > way.
> >> >> >
> >> >> > G.
> >> >> >
> >> >>
> >> >> --
> >> >> Pascal
> >> >
> >> >
> >
> >
>
