Any interest in reading in BX format?See original GitHub issue
Hey, I just found out about the BX format that Embrilliance uses. I was wondering if there was any plans for pyembroidery to read in BX files and produce the resulting alphabet as a list of
EmbPatterns. I would be interested on helping with this as I’ve been writing a tool that does a similar “typing out an embroidery font” thing as Embrilliance.
I know @tatarize has expertise in this area, so just wanted to see if there were plans to read BX.
- Created a year ago
- Comments:11 (7 by maintainers)
Top GitHub Comments
I managed to get it to resize thing, it recompile or rebuild the font. It’s legit just a bunch of glyphs with some sort of reasonable geometric manipulations.
The .be working file format is also going to be the same general format as whatever encoding the .bx files are in. So tweaking that stuff might not be too hard.
Doing a little due diligence, from the sales copy and my knowledge of embroidery and various algorithms I’ve got to suppose that BX as a format doesn’t have any embroidery in it. It’s not a group of embroidery files or anything like that. It’s simply the criteria and scale vector parts of the format. So rather than a letter A filled with stitches, you’d get what amounts to pathing that could be rendered into an embroidered A.
So rather than static glyphs with already present fills at different sizes, you get what is basically the skeleton of the A. It would need to load and save the direction of the satin stitches and the outline of the glyphs.
I’ve spent the last few days writing a parser for Hershey fonts specifically SHX files. https://github.com/tatarize/shxparser
In that case what it’s doing is what TTF and OTF do, they namely have a shapes stored in a lookup table the corresponds with graphics. So you type an
O you get an
O in the case of TTF this consists of at least two different paths of bezier curves that render into a raster
O shape. You’re taking lookup character information to make pixels on the screen and since the actual data in the font is a bunch of rasters you get pixels. But, if you make a much large letter, you maintain the shape quite well because vectors are scalable like that.
With SHX, these are line fonts and are getting important for things like lasers and CNC machines. Namely you have a single line. So rather than two different paths in an
O where you have a small circle inside the larger one to make a sort of donut glyph. You would, with SHX and other Hershey font’s just draw a line based circle. In the case of SHX, at least one of files in testing gave instructions for drawing a 360° circular arc (a circle, but with a start and end). The same thing must be true for correctly rendered embroidery fonts, but with some added complexity. What you need in a good font is nice satin stitches giving the directionality of the stitching, and the order in which those stitches go down.
Here’s a quick visual for satin stitching in inkstitch.
The embroidery font, if done correctly, is not going to actually provide any embroidery, what you’ll get instead is a series of glyphs that look like the above. You’d define the outlines, direction lines, center lines, and ordering. You’d then send that through rendering to make the stitches themselves at a particular size. So regardless what size of font you use, you’ll get more stitching that gives you the correct density at those positions. This isn’t a format that contains stitches it’s a format that contains a few different datatypes that can be easily rendered into an embroidery with the right software/algorithm.
There’s not really an easy way to go from a TTF where you get the filled outline to something that will necessarily work. You could with a bit of expertise add in a bit of information to an outline of a glyph to directly show the order the embroidery should go down as well as the direction of those stitches. There were some early embroidery TTF conversion stuff that tried to make fills for true type fonts that weren’t very good. But, with a bit more info for a rendering engine you could explain how you want those fonts filled and save that as part of the font file.
I’d also need a couple examples of BX fonts which I couldn’t manage to find (tatarize at gmail) in the time I spent looking, but mostly it’s out of the range of this particular project since there’s clearly no actual stitches within the BX format. Rather it’ll be a different segments that are marked as outline, direction line, split line, and with a few properties for how it should embroider that font.
There’s also some parts of embroidery fonts that would be even more engine specific. Namely the points for crossing over to the next letter. There are cases within TTF where there’s special kerning adjustments for particular letter combinations. If, for example,
OV are not made to be closer to each other than they actually are, they seem like they are much too far apart. So there’s a table in the font to put particular letter combinations a bit closer or further apart. Likewise in Embroidery you’ll have cases where you want to avoid cutting the thread, and you can have two different ways to render a letter, but sometimes in some situations you’ll be able to cross the gap between letters more unnoticed than in some other cases.
Ed for example would be much better to cross from E to d at the bottom but
ET would be much better to cross to the
T at the top, and admittedly many times you’ll be rendering the text from the center out because of other various issue with pull compensation. But there is certainly a lot for a embroidery font engine to deal with (though in theory you could get pretty good results with a fairly naive system, get a glyph, get some direction lines, render the glyphs in order.
I could certainly take a look at BX as a format, but unless they are basically fake, they aren’t going to have any stitches in them. They could rather have outline, different colors, direction lines, various lines to control the the satin stitch ordering etc. But, you’re basically going to write a satin stitch engine, and store the satin data in a table that has 1:1 with various characters and a bunch of other interesting font tricks. In theory, if you were really good at fonts you could do things like map out Kanji characters which tend to make references to other base elements of the font, to different locations, at different sizes. And so long as your hints about directionality of the satin stitches hold up, it would be able able to render those characters.