iirc, original overworld constraints had like ~20 free space bytes - which was used to fix the Triforce letters.
00-3F = normal letter
40-7F = letter + mark
80-BF = letter + ws
C0-FE = letter + end string
FF = newline
You could save maybe a few bytes by optimizing some unused code out but it was not good.
Thought about taking a cheap dte way out but adding in new code would eat up enough overhead space to make me stop before bothering trying.
I didn't work on actual script replacement but I don't remember seeing much there to begin with. Especially with the re-translation scripts.
Huffman.. I sorta remember what it is but storing the tree + table could crash the party right now.
Small lightbulb moment.
Let me walk that back a bit - script uses only uppercase letters (26) + misc (ws, period, comma, exclamation, newline, eos). 5 bits per char, or say 6-7 for emergency extended modes.
Overworld, underworld will have different encoding tables - by file design.
Text printing has like ~5-6 frame delay between letters.
Let's say overall 5/8 = 62.5%. So ex. 256 ~=> 409 = +153 gain - 40-50 tree data = +100~
Honestly I don't know anymore - maybe there is some glimmer. But this isn't something I'd want to pick up for awhile (lots of months). Learning time, curve, time spent, chance of fail. Seems like a longer-term project - tools, further hack research, debugging. My own frustrating schedules. Not some fast and easy project to scarf down. :|
Who knows - maybe both techniques will have to be used.
(I guess this is why I try to stay out of translation hacking - dedicated honcho or sous-chef level)
edit: Thanks for pulling out the idea though. Interesting brainstorm.