-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
Just suppose for a moment that we move all the gdk function calls to
gschem.
For normal images, libgeda will have to store the filename path in the
struct, (as it's doing now) and gschem will load the image, instead of
finding it already loaded by libgeda (as it's now).
For embedded images support, libgeda will need to load the image data
into memory, and gschem should handle the conversion from ascii to a
GdkPixBuf struct. No problem here if we do it this way.
Now think about printing images. Right now, printing to PS and PNG is
done by libgeda. If all gdk function calls are in gschem, libgeda will
not be able to handle the images (it won't be linked against gdk neither
gdk-pixbuf), so only gschem will be able to print.
Moreover, the print support will be splitted between libgeda (for all
non-picture related objects) and gschem (for picture related objects).
I don't think this is a good idea.
I do not thing, that printing should be handled in libged at all. IMHO it is more related to the editor (gschem), It makes every application dealing with geda schematics not oly dependand on libgdk but also on libz and libpng.
73, Mario
- -- Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCIJpmMM6fsqBHnOARAgf+AKCbwjPCyFR05H8/5Wf9MuR76zLyAwCfWFc7 iLIk5IHfvekicQzPlwTg2v4= =hKc2 -----END PGP SIGNATURE-----
