On 11/9/2013 8:48 PM, Philipp Gesang wrote:
Scratch that, I just did some tests and memory consumption seems
to be the same. Thanks for revealing this feature!
fyi: it's one of the reasons why the overhead in terms of memory of the
initial loading of large fonts (pre-caching) became less (alr
On 11/9/2013 8:42 PM, Philipp Gesang wrote:
Aren’t you allocating fonts without freeing them? With this
approach you need fontloader.close() somewhere inside
check_names() which isn’t straightforward if you hide the font
data inside the metatable. Btw. calling fontloader.info() first
yields a t
·
> ·
>
> > On 11/9/2013 6:45 PM, Philipp Gesang wrote:
> > > Hi all,
> > >
> > > calling fontloader.to_table() appears to be redundant when
> > > extracting font names, see the attached patch. On my system I
> > > measured 42 (patched) vs 59 (vanilla) seconds for rebuilding the
>
·
> On 11/9/2013 6:45 PM, Philipp Gesang wrote:
> > Hi all,
> >
> > calling fontloader.to_table() appears to be redundant when
> > extracting font names, see the attached patch. On my system I
> > measured 42 (patched) vs 59 (vanilla) seconds for rebuilding the
> > entire index:
> >
> >
On 11/9/2013 6:45 PM, Philipp Gesang wrote:
Hi all,
calling fontloader.to_table() appears to be redundant when
extracting font names, see the attached patch. On my system I
measured 42 (patched) vs 59 (vanilla) seconds for rebuilding the
entire index:
mtxrun --script fonts --reload --force
Hi all,
calling fontloader.to_table() appears to be redundant when
extracting font names, see the attached patch. On my system I
measured 42 (patched) vs 59 (vanilla) seconds for rebuilding the
entire index:
mtxrun --script fonts --reload --force
The resulting index is -- except for the uuid,
