*.gmz is G’MIC’s native file format for storing data. One can output any gmic command to it.
This implementation will not support fonts as a typeface engine would, besides what David introduced, unless someone codes it into G’MIC. Who knows, G’MIC development moves at a breakneck pace, so font support could mature over time.
Here’s the complete story. In addition to what I said, this is the output:
C:\Users\User\Desktop\gmic>gmic font2gmz impact.ttf,500 o font500.gmz
[gmic]./ Start G'MIC interpreter (v.3.3.1).
[gmic]./ Convert font 'impact.ttf' to G'MIC format, with font size 500 and font qualifier ''.Qt: Untested Windows version 6.2 detected!
[gmic] *** Error in ./+font2gmz/ *** Unknown filename 'C:\Users\User\AppData\Local\Temp\gmic_font2gmz_impact.png'.
The HTML file is in here - gmic_font2gmz_impact.zip (1.8 KB)
Then, it seems to create a 0KB file onto the same folder I was in. The name is UsersUserAppDataLocalTempgmic_font2gmz_impact.png.
The characters are stacked nicely into grid, which is why I think it takes snapshots:
… and the orange image is then decomposed into the individual characters. And all I would suggest is to use convert to create the individual characters directly.
I think It can be done somehow with ImageMagick.
Maybe I’ll try to use that (one day 
).
We have a ImageMagick dude here.
@snibgo I hope you see the snibgo symbol spotlight on the cloud in the dark.
As the following works…
sp
cmd="convert -background transparent -fill blue '-font' test.ttf -pointsize 200 'label:A' '_overlay.png'"
exec 0,$cmd
i _overlay.png to_rgba
imagealpha[0] [1],0.5~,0.5~ keep[0]
d
Then the cmd can likely be used to create the individual fonts…
This makes me wish ImageMagick and G’MIC to be merged. My only issue is to having to import png. Something as nice as optimized text rendering with good output would be awesome.
But, that is a really, really high order and a dream one at that.
Well, I’m doing some tests, but it seems there are some issues with “exotic” characters : When the font does not contain one specific character (as ⊕), then IM renders a black image, whereas cutycapt renders it with a default font (which is more convenient in my case).
It’s annoying, because this means that for each character, we have to test if the render is empty or not, then switch back to a default font glyph if it’s the case.
That is basically the same behaviour that you get with Word when a character does not exist in a charset (then you get a square). I sometimes find this better than getting a default font as it is easier to spot in a document. I would just use the black character and not switch. People should check if the charset they want to use can actually has all characters they need.
Maybe it’s better for Word (personnally I’m definitely not fan of this behavior, but I’m used to it with Microsoft), but for G’MIC, this is not convenient. If someone wants to draw a text on an image, he certainly never wants to have black squares or empty characters because some of the symbols do not exist in the font he chose.
The fault lies with the font, not the user!
When rendering an HTML page with a decent browser, the characters that do not exist in a font are still rendered, even with a “default” aspect. That seems way better to me.
Fonts support different character sets, such as Latin or Latin Extended - and the user should check for that. I would be terribly unhappy if I found that a font not supporting an accented e (é) has replaced it with the non-accented version. Having that said, you are right, it is a matter if taste. So if I still wanted it with black squares, how does the font.gmz file has to look like?
Yes, and I think the use case here is different for a “standard web page”.
A few improvements today:
I’ve been able to store the “default” fonts with a height of 512px, which means that now command, font doesn’t upscale with a specified height<512 (which is already quite big). You need to remove your gmic_fonts.gmz file from your G’MIC resources folder, so that the new one can be downloaded. The new gmic_fonts.gmz file is not even larger than the previous one (that was limited to 128px height max).
The font upscaling algorithm has been a bit improved, so even with height>512 , you shouldn’t get something completely blurry.
foo :
sp colorful,1024
to. "AaBb",0.5~,0.5~,${"font \"Cheese Burger\",800"},4,1,255
renders this:
convert from ImageMagick, but with no success. It’s not really easy to specify UTF-16 input (as it is for a HTML page). Maybe using headless firefox or chrome could solve this issue. I’m giving up for now.On ImageMagick: I do not recommend using a convert command for any purpose unless you really have to, eg a legacy system that cannot be upgraded. convert is the old ImageMagick v6. For some years now, v7 has been available. The v7 syntax is (slightly) more logical, and more powerful, and has better error checking. Use magick instead of convert. And don’t use magick convert as that uses v7 software with v6 syntax, for backwards compatibility.
I don’t know much about rasterizing text (“typesetting”). I do know that it is complex. Rasterizing a font well at different sizes isn’t a simple resizing. Deciding on the correct gap (or overlap) between two letters within a word is non-trivial. If font choice is automated (because not all glyphs are available in all fonts), choosing good fallbacks so font changes are not obvious is difficult. Arabic has different rules. And so on.
ImageMagick delegates the hard work to libraries such as freetype.
I haven’t encountered CutyCapt. When I (rarely) want to rasterize web pages, I use wkhtmltoimage.
Yes, that’s the clear message one needs to print and display on a wall.
What I did these last days for G’MIC is just improving a little bit the capabilities for basic text rendering. It’s definitely a hack, it’s not well done, it’s definitely not correct from a typographic point of view. It’s just a bit better than before, so it’s worth keeping it!
No way.
Imagemagick has been around since the 90s, and I have the utmost respect for this project. It also means that their code base is far more stable and tested than G’MIC’s. The only thing I can hope for is that G’MIC will continue to exist in 10 or 20 years’ time. IM is a model to follow.
I started G’MIC because IM didn’t suit my needs for doing algorithm prototyping.
Have you $ gmic update ?
Yes, same results.
Have you deleted your file %APPDATA%/gmic/gmic_fonts.gmz then ?
Yes. gmic update does not seem to import it though. so, i had to use font to import it.
