1. OCR and fonts....Jiri or anyone else?
I know I have been over this before, but as it is all such a massive set of
character fonts I am using (those 45,000+ Chinese characters again!) I just
thought it would be better to ask a simple question before I get much
further along.
I am getting memory over-run problems when the program is opening and
closing so many character files (over 200 32X32-bit full font sets). I am
planning on converting this in the not-too-distant future to one enormo
bitmap file (as Jiri has so brilliantly outlined earlier to me) but for now
I have limp along with the multi sets of files. I only open one of them at
a time, but does the routine also flush (dump and reset; garbage-collect;
reclaim, whatever) out the old font set. And if it doesn't, how can I
manually do this myself? Once I build the single 45,000+ font set, it of
course will not need to be re-loaded once it is called, but does anyone out
there know any detail about whether I can control this problem for now?
If I have missed something here, like for example, a command in the font.e
includes, I apologize, but I can't seem to find one.
Norm
2. Re: OCR and fonts....Jiri or anyone else?
Message text written by Norm:
>I am getting memory over-run problems when the program is opening and
closing so many character files (over 200 32X32-bit full font sets). I a=
m
planning on converting this in the not-too-distant future to one enormo
bitmap file (as Jiri has so brilliantly outlined earlier to me) but for n=
ow
I have limp along with the multi sets of files. I only open one of them =
at
a time, but does the routine also flush (dump and reset; garbage-collect;=
reclaim, whatever) out the old font set. And if it doesn't, how can I
manually do this myself?<
Jiri hasn't provided a way to delete fonts, but here is a patch that will=
work:
-- start code
global procedure purge_fonts()
select_font(1)
fonts =3D {fonts[1]}
widths =3D {widths[1]}
heights =3D {heights[1]}
bheights =3D {bheights[1]}
names =3D {names[1]}
params =3D {params[1]}
end procedure -- purge_fonts
-- end code
Paste this into font.e (version 4.40) after the select_font() routine. =
This procedure will zap all loaded fonts except the default Rom font. Ca=
ll
purge_fonts() just before loading each new font file.
Also, referring to your earlier post on OCR - I am quite interested heari=
ng
more on the topic, but I don't know if I can contribute anything useful t=
o
the discussion.
Colin Taylor
3. Re: OCR and fonts....Jiri or anyone else?
I don't know anything about Chinese characters and maybe I don't
understand what you are attempting to do, but
If you have a black and white bitmap that is 32 bits x 32 bits
each bit can be ON ( BLACK ) or OFF ( WHITE )
then you only need 128 bytes to store that bitmap.
When you need to use it you can convert or translate it to any
form that you need like a euphoria font character, etc.
You might even be able to look at a Chinese character and disassemble
it into its primary line strokes and just store those strokes.
Then you could overlay the correct strokes over a 32 x 32 bitmap
to form a Chinese character.
Lots of Ideas but probably no help Bernie
4. Re: OCR and fonts....Jiri or anyone else?
45000 x 32 x 32 x 4 bytes per integer in Euphoria would
require: 184,320,000 bytes (plus some overhead)
I think you should somehow pack the data,
storing 0 or 1 in a bit, not 4 bytes, or come up with a
scheme where the 45000 characters don't have to all be
in memory simultaneously.
Don't rely too much on "virtual memory" - it only works
up to a point, and tends to slow things down a lot.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
5. Re: OCR and fonts....Jiri or anyone else?
Why not use any of the font-engines ? I am under the assumption they store fonts
pretty efficient.
Or you could use any of the sprite engines that come with some graphics engines.
I am actually talking about RLE-encoding. It will shorten the amount of memory a
lot.
My old GFX (but don't use it though), a lib by Peter Blue, Neil, and I believe
some other libraries as well support RLE-encoded
sprites.
With RLE-encoded sprites, I've seen two schemes:
-- the asm-scheme, graphical data is packed as length and color code.
( most memory efficient mehtod )
-- the sequence-scheme, graphical data is packed as data and memory location
( very fast with Eu, the data can be outputted at the location using
poke )
But even the last sequence scheme should decrease your memory use.
Interestingly, these methods, in most libraries I've named here are used to
speed up the drawing rather than to decrease memory
usage.
You could off course write your own library. It should not be too much hassle
depending on what you want to do with it.
Ralf
