I really don't know *why* this is happening, truly!
Lets you create your own TTF fonts out of pixel font images! · By
There is a bug in my path generator algorithm that happens when you have a hole inside a shape inside a hole inside a shape (oh mouthful), which the holes inside circled 6/8/9 happen to be. I can’t remember if it forgets to insert a path or traces it in the wrong direction (CW/CCW) but either way the font renderer is not amused.
If these are the only such glyphs in the font, you could make a hole in the outer outline and then move the vertices in FontForge when you’re done with the font. Or put the circle in another glyph and then merge them using FontForge (possibly through a script if you update the font often).
Or, if you like a challenge, you can find try fixing the algorithm (source code’s here).
Thank You™ for replying!
I ended up going back into the glyphs and changing a single pixel on the outer edge of them, following your advice - now that I knew the issue, I could fix it!
and it works now!
it's basically unnoticeable, so I ain't bothered! tank ye!
I'll send this post to one of my friends who's more knowledgeable in code than I am to see if they're interested in fixing it,
Closing Thought™s: you have made something wonderful! bUH-BYE~!
Ok. I recreated the six from this thread as you said and made a research. What I found:
When I read the code it seemed me a bit strange to see bool in one place:
static function buildPoly(poly:Polygon, colStart:Int, rowStart:Int, z:Bool) { var points = poly.points; var dir = 3; // ENWS var col = colStart, row = rowStart, dirStart = dir; inline function add(x:Int, y:Int):Void { points.push(new Point(x, y)); } var w = width, h = height, grid = Contour.grid; add(col, row); var steps = 0; while (steps == 0 || (col != colStart || row != rowStart || dir != dirStart)) { switch (dir) { case 0: { // right (BR corner) if ((col + 1 < w && grid[row][col + 1] > 0) == z) { if ((row + 1 < h && grid[row + 1][col + 1] > 0) == z) { add(col + 1, row + 1); dir = 3; } col += 1; } else { add(col + 1, row + 1); dir = 1; } };
IIUC there is happening the phase of creating the outline... And there you check if some walls in some directions are exist. But in fact we have two different shapes (Do we? I hope I understand) and code should check if there is a wall of exactly the same type but it uses bool so any wall of any shape is considered as wall. Idk I am a fool ¯\_(ツ)_/¯. Anyway I wanted to create my custom similar utility, I even came up with another algo based mentioned above (now I am afraid it won't work)
P.S There won't be normal outline contour for color fonts?
Do you want to say you trace all the glyphs at the same time and then just split them?
It looks pretty easy to do it on the step of marking groups you need to check not if it is also filled but just check one more property of that cell if it is equal. It is the same algo but you will just need to add one additional check inside 4 side floodfill. But yeah maybe in this case you will need layers although I think that the simplest way to implement what I said in my two comments could be done with layers ¯\_(ツ)_/¯. By the way what do you think about the solutions?
(Deferred question) Do they work?
Forgot what I said earlier about possible solution (but read). It seems I understood (I am still not sure that found the problem but). I used the color dots instead of the numbers because it was faster.
First step is to mark all the pixels as transparent or filled
Second step is to extract concrete shapes and give them appropriate numbers
Then do the the second step but for holes. There is a problem. You store the data of all the contours in one matrix (I base this assumption at the image from your article). When you start to mark the holes, you don't trait the pixels of six as part of the hole so you end up with 3 different holes in the circle. When you start to mark the holes you need to do it in a bit another way. You need to understand for which shape this hole belongs. When you create the hole you need to check if the pixel doesn't belong to that shape rather then just checking if the pixel is empty...
In the case if we check if something is not red so the blue,pink,black,green and yellow will be treated as one hole in the case when we check if it isn't filled we have 4 different holes: pink,black,blue and yellow. But yellow makes the hole inside green shape which will be also added to the output file.