[sword-devel] Too many milestones can cook your buffer?

[Greg Hellings]

One could always switch to a zVerse4 driver instead of zVerse if they wish
to have larger block sizes. zVerse is limited to a 65,535 byte cap per
block, as it uses a 16 bit size value for the offset in the data file.
zText4 uses a 32-bit value, and can correspondingly capture a 4 Gigabyte
minus one block size. Most of our mpdule types have this split option
available.

That would probably be a better solution than modifying block setting. As
mentioned, Chapter is the "best" block to use because that is what most
apps use as a unit of display. But if the release script hard codes Book,
then the other solution is to change the driver in use.

--Greg


On Mon, May 5, 2025, 11:45 AM David Haslam <dfhdfh at protonmail.com> wrote:

> So if an OSIS file were so unusual as to cause the module to give
> decompression buffer issues, as things stand at present, you would not have
> a route to fix things?
>
> Not even if the submitted .conf file has BlockType=CHAPTER specified as
> the way to prevent this issue ?
>
> David
>
> On Mon, May 5, 2025 at 17:39, domcox <dominique at corbex.org
> <On+Mon,+May+5,+2025+at+17:39,+domcox+%3C%3Ca+href=>> wrote:
>
> David Haslam <dfhdfh at protonmail.com> writes:
>
> > How does Dom’s module release script determine the right
> > BlockType for a module?
>
> BlockType is set with only one value: BlockType=book.
>
> see:
> https://www.crosswire.org/svn/sword-tools/trunk/modules/conf/confmaker.py
> (line=431)
>
> --
> Dom
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20250505/ddea6a26/attachment.htm>