Here are the 47000+ characters in the Noto-sans-cjk-jp-regular font. This comes from an OpenType Collection (*.otc) file along with 35 other fonts and variations.
A zoom in to the upper left reveals that some glyphs are still not quite right. Still investigating some of these. I’ve already found some glyph calculation errors, there must be a few more.
I finally got Noto-sans-cjk-jp-regular font printing with no errors. This was a whirlwind of (my own) bugs to find. A few things I had to get through include outlines are not all CW or CWW (as the font specification suggests), instead they were mixed. wn_PnPoly() algorithm to determine winding REQUIRES a clockwise winding to return the correct answer. SHAPE_POLY_SET.Fracture(1) needed to be done once instead of multiple times (after adding each hole doesn’t work). I finally put together a brute force determination of which outlines were supposed to be polygons and which were supposed to be holes. It probably will randomly fail if there are overlapping outlines (it depends on exactly which point is chosen for the in/out determination). I was using wn_PnPoly() for comparing which outlines were inside others, but I had to extend it to comparing all outlines with each other, then I can count the number of embedded polygons and alternately choose polygon, hole, polygon, etc. This can be optimized, but I’ll save that for another day. Most fonts are specified as non-zero winding, but there are some, apparently, that are even/odd winding. I’m probably conflating the two types of windings, as I have read in one place that for non-overlapping contours/outlines that it should result in the same answer. Either way, my current algorithm seems to be working for this font. I’ll try the other fonts in my list as time permits. And it takes about 6-7 minutes to print all 47000+ characters of this font using my Python code. Maybe I can reduce that, but I’m not sure.
I’m not sure if people like the super-frequent updates on progress, or the large image files. Hopefully this isn’t too much posting…
Here’s a snippet of 80 fonts printed in full. I’m seeing a consistent error with the overlapping circles glyph but other than that, it looks pretty clean. I’m also seeing that some fonts don’t have unicode tables, particularly the “symbols” fonts (or I’m not interpreting the unicode tables correctly). I’ll have to come up with an algorithm (at some point) for overlapping contours, but the current algorithm looks to be working well for most glyphs in the Noto fonts and a few others (osifont, times new roman).
Its good to see the updates, some of us have wanted other fonts for a long time now,
Is this being merged to the nightlies? or will that happen when your happy with the few edge cases
This is all python code. It will be published with KiCommand python plugin. But I know using KiCommand is a hurdle for some people (KiCommand is a stack-based command line for KiCAD in development since 2017). I’m trying to separate out the font code so it could theoretically be separated out into its own plugin. Ideally someone (maybe me) will create a dedicated GUI for font placement. Whether I do all of that part or someone else does is still to be seen. The Python font code will be first available on the KiCommand github. I’d be happy to summarize the code structure if anyone is interested (or you can just wait for the code).
Work continues on fonts. Because it is difficult to add Python packages to KiCAD python (at least on Windows), I’ve created a separate Python3 program that converts font files (ttf, otf) and font collection files (ttc, otc) into a format suitable for the KiCAD font system I’ve created. The font format is simply a pickle file (created with the pickle Python package) of the font class I’ve written. The font class carries glyphs, glyph names, unicode conversion table, and spacing parameters. Glpyhs are stored as SVG contours and converted to polygons right before placing on the board. Right now I’m focused on left to right fonts only, but others could be supported in the future. Creating this program bypasses the need for me to provide fonts and all of the licensing issues that that entails. With this program, you supply your own TrueType or OpenType font files (or font collection files). This means you could use any fonts you wish.
The fontimport.py is a Python 3.7 file and requires the fontTools Python package to be installed on your system. If you think this will be a barrier for you, please let me know.
On my system, I execute the following on the command line to get help from fontimport.py:
python fontimport.py -h
Here is the current help text for the fontimport.py file:
usage: fontimport.py [-h] [--version] [--output OUTPUT] [--input INPUT]
[--recursive] [--exec]
optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--output OUTPUT output directory
--input INPUT input directory or file
--recursive search find files recursively when --input is a directory
--exec without this option, just list environment and files, but do not write to the output. Actually writing to the output requires this option.
The font system is integrated into KiCommand. If you are interested in adding a variety of fonts to your project (or just a font different that KiCAD default font), you may want to have a peek at KiCommand in preparation. It’s currently working on KiCAD 5.1.6-release. There’s a README file on github and a tutorial and a discussion thread on this forum. It’s been designed on Windows and is tested well there. I’ve seen it used on MacOS, but I don’t know if Linux is working. KiCAD on Windows uses Python 2.7, but I think the other OSes are using Python 3. If you have a chance to test KiCommand on MacOS or Linux, please let me know in the Discussion thread or github issues about any problems you discover. If it works without problems, please let me know in the Discussion thread.
There will be new KiCommand commands to place font characters on the board. Here is a sampling of commands in their current state:
The default font size is 10 points, where a point is 1/72 of an inch (this is the industry definition of a point, in fontspeak). The “font size” is an indication of the size of the “em height” which is roughly the height of the “m” character. So by default, characters print out at 0.14" or 3.5mm. You can scale with the S parameter like this:
You can embed control characters like newline (\n) or unicode characters with \uXXXX notation where the XXXX is the hexadecimal unicode code point. The wxWidget input to KiCommand should also be able to handle direct unicode input, but I haven’t tried that yet.
There are also ways to specify the accuracy of the bezier approximation by specifying a number of “steps”.
Here is the lowercase “b” with 2, 3, 4, and 5 bezier steps:
I’ve had no real problems specifying up to 30 steps, but the increase accuracy doesn’t seem worth the significantly larger number of polygon points. Steps of 5 seem sufficient, and maybe up to 10 might be good for super smooth curves. Because I’m not sure of the best number of steps, it can be changed by users.
It would be great to have a GUI to add board text in any chosen font, I just haven’t had the time to build one, and KiCommand seemed like a good way to verify basic functionality and get the fonts tested by a variety of users and systems.
Let me know if you have a specific font you want me to test, and I will, if it is freely available.
Please post comments or questions here.
Edit: clarified that polygons are used on the board, and fixed command-line argument “–exec”
KiCommand preliminary font support has been published to github.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
