On 20.10.2010 09:50, nullPointer wrote:
I use the same procedure than embed images, but I don´t understand the great
difference of size. :|
You're storing a ByteArray which stores 256bits per byte as a base64
string, which stores 64bits per byte.
If you also cache it somewhere, you're basically using 5 times the size
of what you import, 4x for the literal base64 string, and 1x for the
cached byteArray itself.
For a smaller image size, you could just use the ByteArray itself, ie:
^#[10 44 56 43 ]
at the cost of potentially larger .changes and Monticello files.
The reason you're storing it as a base64 string in the first place, is
that smalltalks will automatically replace lfs with crs when you store a
method, so if your binary data happens to contain an lf byte, the raw
string for the binary data will not be the same if you copy/paste it
anywhere, modify it by hand and accept the changes, or store it to an MC
package, then load it.
The base64 encoding does not use those trouble characters, and thus the
things described above will work.
On 20.10.2010 09:50, nullPointer wrote:
not is the same compress the value of association to zip, with #zipped method
and for upset the file out of image uncompress the string? I don´t
understand the use of pragmas.
Eliots suggestion of storing metadata for binary data in method tags is
a good one.
Not sure if his example, which seemed to indicate storing a string with
gzipped binary data, avoids the above mentioned issue though.
Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
