The C file is small enough to read (over a few minutes.)<p>I got to about line 5 and realized: I’ve never seen quite that technique for embedding a font via an autogenerated header before. I’m more used to Windows resources; this seems to generate a byte array in CMake code. I’m somewhere between horrified and impressed, in that I feel we’ve finally discovered a cross platform binary resource embedding solution.
Here's the build script that uses: <a href="https://github.com/ghostty-org/ghostling/blob/main/bin2header.cmake" rel="nofollow">https://github.com/ghostty-org/ghostling/blob/main/bin2heade...</a><p>I ran it against a 1x1 pixel GIF:<p><pre><code> cmake -DINPUT=pixel.gif -DOUTPUT=pixel.h -DARRAY_NAME=pixel_gif -P bin2header.cmake
</code></pre>
And got this:<p><pre><code> // Auto-generated from /private/tmp/exp/pixel.gif — do not edit.
static const unsigned char pixel_gif[] = {
0x47, 0x49, 0x46, 0x38, 0x39, 0x61, 0x01, 0x00, 0x01, 0x00, 0x80, 0x00,
0x00, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x2c, 0x00, 0x00, 0x00, 0x00,
0x01, 0x00, 0x01, 0x00, 0x00, 0x02, 0x02, 0x44, 0x01, 0x00, 0x3b
};</code></pre>
Interestingly, cmake 4.3 just added a builtin command 'bin2c':<p><a href="https://cmake.org/cmake/help/v4.3/manual/cmake.1.html#cmdoption-cmake-E-arg-bin2c" rel="nofollow">https://cmake.org/cmake/help/v4.3/manual/cmake.1.html#cmdopt...</a><p>...it will probably take a decade or two until Debian-based Linux distros will get cmake 4.3 though ;)
Well, I originally used C23's #embed directive (<a href="https://en.cppreference.com/w/c/preprocessor/embed" rel="nofollow">https://en.cppreference.com/w/c/preprocessor/embed</a>) but GCC in Nixpkgs doesn't support C23 (or I'm holding it wrong) so I dropped back to this. The better long term solution is #embed.
For completeness, there's also the somewhat common way of creating an object file directly from the binary using objcopy. The object file ends up with 3 symbols with names based on the input file. For instance, a binary file level0.map yields: _binary_level0_map_start, _binary_level0_map_end, _binary_level0_map_size.<p>These can be used in the application through external declarations; and you include the object file in the linking step, like any other object file.
Fun fact: XPM bitmaps were designed to be #included unmodified, the files contain C boilerplate: <a href="https://en.wikipedia.org/wiki/X_PixMap" rel="nofollow">https://en.wikipedia.org/wiki/X_PixMap</a>
You can use `xxd` from the vim package to generate these. You'll find out pretty quickly that this is only suitable for small resources: gcc and clang blow up in both time and space on very large literal arrays. If you need to ship more than a few megabytes, find a different technique.<p>I used this technique for awhile, but it was too problematic for my use case. Now, I use <a href="https://github.com/lief-project/LIEF" rel="nofollow">https://github.com/lief-project/LIEF</a> -- among other things, this project can modify Windows PE, macOS Mach-O, and Linux ELF binaries to add resources to them, then offers an API to read them back later. It's a little different for each format, but it's capable of doing all three and I was able to build a cross-platform resource-bundling system that doesn't care how big the resources are.
Yeah xxd is the correct answer. If you don't want to install a dependency and have Lua installed, or if you're just feeling a little bit frisky, you can use my function which is Production Ready™.<p><pre><code> Xxd = function(name, input)
if not name:find'^[_%a][_%w]*$' then error('bad name: '..tostring(name)) end
local ans = {
'const unsigned int '..name..'_len = '..(#input)..';',
'const unsigned char '..name..'[] = {',
}
local t = {}
for i=1,#input do
table.insert(t, ('0x%02x,'):format(input:byte(i)))
if #t == 16 then -- 16 columns per row. arbitrary, change this if you want
table.insert(ans, table.concat(t))
t = {}
end
end
if #t ~= 0 then
table.insert(ans, table.concat(t))
end
table.insert(ans, '};\n')
return table.concat(ans, '\n')
end
</code></pre>
I am distributing it under the terms of the GNU GPL v3. So if you put this in your codebase I will sue you into releasing your entire source. Just kidding it's MIT licensed.<p>Honestly that's a terrible joke. Seriously it's MIT. Here I will put the full license in this comment to illustrate how serious I am:<p>Copyright 2026 rweichler<p>Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:<p>The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.<p>THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Feels like Lua is a more exotic dependency. I used to use xxd but this gets problematic when files grow (and they don't need to grow much at all), objcopy is much faster (which I didn't think would matter much, but it did) and don't have the same issues that accidentally opening the .h file in your editor or code-searching having to traverse that mess.<p>Yes, you'd want to gitignore it and exclude it from search etc. but you still have size issues etc. See <i>gucci-on-fleek</i>'s comment on objcopy above for usage.
My preferred technique (where #embed isn't available) is to use objcopy:<p><pre><code> $ echo 'Hello, world!' > hello-world.txt
$ objcopy --input-target=binary --output-target=elf64-x86-64 \
hello-world.txt hello-world.o
$ cat <<EOF > embed.c
#include <stdint.h>
#include <stdio.h>
#define EMBED(NAME) \
extern const uint8_t _binary_##NAME##_start[]; \
extern const uint8_t _binary_##NAME##_size[];
#define DATA(NAME) _binary_##NAME##_start
#define SIZE(NAME) (size_t)_binary_##NAME##_size
int main() {
EMBED(hello_world_txt);
printf("%.*s", (int)SIZE(hello_world_txt), DATA(hello_world_txt));
}
EOF
$ gcc hello-world.o embed.c -o hello-world
$ ./hello-world
Hello, world!</code></pre>
And as a Windows programmer the use of a method called DrawTextEx surprised me :)<p>A really neat sample. Shows the power of the ghosttty library very well. The author chose well with their other libraries, it’s the kind of demo that lets the code actually demo what to trying to without much else getting in the way. Rather inspirational to wrote my own terminal app now.
I think this has been around for a while:<p><pre><code> $ echo 'test' | xxd -i -n foo
unsigned char foo[] = {
0x74, 0x65, 0x73, 0x74, 0x0a
};
unsigned int foo_len = 5;
</code></pre>
(edit: 30 years)
For cross-compilation ease it makes sense if you don't care about the size explosion.
> I’m somewhere between horrified and impressed, in that I feel we’ve finally discovered a cross platform binary resource embedding solution.<p>Maybe I'm misunderstanding your comment about having "finally discovered" that...<p>For to me embedding binary resources in source files is nothing new at all? It was definitely done in the early JavaScript days for a variety of reasons.<p>Arguably early basic listings that had lots of DATA text lines were already doing that. Maybe not the most portable but we're talking about the 70s and 80s here and definitely binary data in source code.<p>Games for the Atari ST and Amiga, for example, could partially share at least some of their source code and it wasn't uncommon to encode binary inside sources, including... Fonts! Back then fonts were not reused from one game to another.<p>Heck, I've done in Java (and Java is cross platform) in the past: quick visual debug tools for Java GUI apps to toggle a debug mode showing something not dissimilar to a HUD. Pixel-perfect fonts encoded in .java source files.<p>I really don't think it's anything new.<p>P.S: I'm pretty sure it's done like for some fonts in the Linux kernel too.