[GH-ISSUE #464] Feature suggestion: Add gzip decompression for VLW-files #1391

New Issue

sascha_hemi · 2026-03-20T19:08:01+01:00

sascha_hemi commented

2026-03-20 19:08:01 +01:00

Originally created by @olanwe on GitHub (May 13, 2025).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/464

Originally assigned to: @nlimper on GitHub.

Is your feature request related to a problem? Please describe.
VLW font files are inefficient in terms of storage: they are uncompressed and waste one full byte per monochrome pixel! VLW-files can be significantly compressed, e.g. from 215 KB down to just 16 KB!

Describe the solution you'd like
Uploaded VLW files that have been gzipped before (.vlw.gz) could be automatically decompressed. This will save us a lot of flash-memory!

Additional context
I have already created two functions for testing purposes (see attachment) that will act as wrappers for the spr.loadFont() and spr.unloadFont() calls. They seem to work fine so far. However, I did not create a PR yet, because:

I am neither an ESP32 nor an CPP expert, so I am not sure if the coding is OK (e.g. decompression takes place in memory - not sure if this might eat up too much RAM...?)
Where shall the functions be placed? (I tested them in contentmanager.cpp)

decompress_gzvlw_fonts.txt

Originally created by @olanwe on GitHub (May 13, 2025). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/464 Originally assigned to: @nlimper on GitHub. **Is your feature request related to a problem? Please describe.** VLW font files are inefficient in terms of storage: they are uncompressed and waste one full byte per monochrome pixel! VLW-files can be significantly compressed, e.g. from 215 KB down to just 16 KB! **Describe the solution you'd like** Uploaded VLW files that have been gzipped before (.vlw.gz) could be automatically decompressed. This will save us a **lot** of flash-memory! **Additional context** I have already created two functions for testing purposes (see attachment) that will act as wrappers for the spr.loadFont() and spr.unloadFont() calls. They seem to work fine so far. However, I did not create a PR yet, because: - I am neither an ESP32 nor an CPP expert, so I am not sure if the coding is OK (e.g. decompression takes place in memory - not sure if this might eat up too much RAM...?) - Where shall the functions be placed? (I tested them in contentmanager.cpp) [decompress_gzvlw_fonts.txt](https://github.com/user-attachments/files/20194592/decompress_gzvlw_fonts.txt)

sascha_hemi added the enhancement label 2026-03-20 19:08:01 +01:00

sascha_hemi commented

2026-03-20 19:08:02 +01:00

@nlimper commented on GitHub (May 14, 2025):

That could be a useful addition, thanks. I will integrate it at some point.

@nlimper commented on GitHub (May 14, 2025): That could be a useful addition, thanks. I will integrate it at some point.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#1391