4 replies to this topic

[DoctorDaveT]

Hi, Everyone,

While we won't know for sure until eS10.1 is released, I'm expecting graphics support in .dctx & .cmtx like what was introduced in the .topx/.refx files when 10.0 was released. So - what is that going to do with file size issues?

Dictionaries in particular already eat up RAM. Take ISBE as an example. It's already 13Mb. What will happen if graphics get added?

Now, I'm not really concerned about what Rick is going to release. I'm quite certain he understands the need for very low resolution pictures in already large .dctx files. But I am concerned about third party resources.

Building a good module takes a lot more than the "pump & dump" techniques of copying and pasting from the internet, and then simply pasting it into a module shell. We've all seen ugly modules. Now - imagine these ugly modules with a hundred pictures pasted into them. Ugh.

I hope third party builders will recognize the need to keep image sizes small. It would be great if eSword itself could somehow compress info and still be usable (like some other software packages can do). Not sure if that's doable, though. But I do know that third party builders can shrink their image sizes if they'll put a little more effort into their builds. Now we'll just see what happens.

[Josh Bond]

Hi, Everyone,

While we won't know for sure until eS10.1 is released, I'm expecting graphics support in .dctx & .cmtx like what was introduced in the .topx/.refx files when 10.0 was released. So - what is that going to do with file size issues?

Dictionaries in particular already eat up RAM. Take ISBE as an example. It's already 13Mb. What will happen if graphics get added?

Now, I'm not really concerned about what Rick is going to release. I'm quite certain he understands the need for very low resolution pictures in already large .dctx files. But I am concerned about third party resources.

Building a good module takes a lot more than the "pump & dump" techniques of copying and pasting from the internet, and then simply pasting it into a module shell. We've all seen ugly modules. Now - imagine these ugly modules with a hundred pictures pasted into them. Ugh.

I hope third party builders will recognize the need to keep image sizes small. It would be great if eSword itself could somehow compress info and still be usable (like some other software packages can do). Not sure if that's doable, though. But I do know that third party builders can shrink their image sizes if they'll put a little more effort into their builds. Now we'll just see what happens.

Rick's official modules are compressed so, you're right, his modules will be small.

But user created modules will likely be bloated. Unlike Topics (which support text and image compression), Dictionaries and Commentaries will not have compression (last I heard). Even when someone is prudent with file sizes (uses a reasonable resolution, and physical dimensions), file sizes can add up fast! It's almost deceptive how quickly image sizes can add up! I've released some topic modules as refx because the image sizes added up faster than I thought and the refx format compresses both the images and text nicely.

[mikecindi]

Is it possible to use sqlite or other utility to compress the various modules?

[Josh Bond]

Is it possible to use sqlite or other utility to compress the various modules?

Not for use with e-Sword. e-Sword does support compression in the REFX format, though.

You can compact a database--that just deletes space between or inside deleted or modified records. It's good if you've been editing a module. But it does not compress the data.

[jonathon]

Dictionaries in particular already eat up RAM.

I'm not that concerned about dictionary size.

I am concerned about commentary size. I've several hard copy Study Bibles that have more than 2,000 maps and images in the footnotes of the Bible. This is in addition to the four-colour maps in an appendix.

My recommendation would be to limit maps/graphics in dictionary and commentary resources to:
* 2 bit GIF images (assuming e-Sword can read GIF images) ( 2 bit images are better known as black and white images, with no shades of grey, nor of gray.)
* maxsize is 500 pixels by 500 pixels;
* No more than one map/image per pericope;
* 4 Colour maps go into a separate Map/Graphic resource;
* Resources larger than 500 * 400 go into a separate Map/Graphic resource;

jonathon