[9fans] writememimage slowness

[9fans] writememimage slowness

[Skip Tavakkolian]

I am running into a problem when, after building a large Memimage
of some 22800 glyphs and trying to write it out, writememimage()
seems to run forever.  The size of the Memimage is (22800×font_width,
font_height).

Any ideas?

Re: [9fans] writememimage slowness

[plan9]

fst@centurytel.net (Skip Tavakkolian) wrote in message news:<eadd21c7d266dffbcf1b7f2bd13a8523@centurytel.net>...
> I am running into a problem when, after building a large Memimage
> of some 22800 glyphs and trying to write it out, writememimage()
> seems to run forever.  The size of the Memimage is (22800×font_width,
> font_height).
>
> Any ideas?

writeimage() has shown excellent (immediate) results for 512*31*31 in CMAP8
but we prefer not to readsubfont() more than 0xFF glyphs at a time and then
spare as much memory as possible.


Is that a good idea to assemble such an amount of glyphs together ?

Why not use Plan 9 ability to get font from many files ?

0x0000 0x007F Latin
0x0080 0x00FF next
and so on

rather than
0x0000 0x00FF Complete_font_file

Re: [9fans] writememimage slowness

[Skip Tavakkolian]

> Even if writememimage finishes, you'll have a hell
> of a time using that font.  Breaking it up will let it
> be loaded in pieces (paged in, as it were) rather than
> paying for one huge load all at once.

bdf2subf does provide a flag to print the ranges and with
a script around it can be invoked multiple times to extract
the different ranges. So, as a practical matter this is not a problem.
I was not sure if this slowness pointed to some flaw or
if it was a design decision.

Re: [9fans] writememimage slowness

[Russ Cox]

Even if writememimage finishes, you'll have a hell
of a time using that font.  Breaking it up will let it
be loaded in pieces (paged in, as it were) rather than
paying for one huge load all at once.

Russ