Now,Schematic and PCB’ Text cannot write Chinese.Now I’m putting the Chinese Text picture.
No support is currently planned. For technical and historical reasons, KiCad uses its own font made of simple line segments. The easiest way forward for KiCad to support CJK text would be for someone to draw those characters into KiCad’s stroke font, either manually or with a conversion script. I do not think there is much interest in doing this among the current developers. In the future, I’d like to see support for standard fonts as well, but I think that is a long way off.
If anyone reading this has the skills and patience necessary to do it, a CJK addition to KiCad’s font would likely be welcome.
This issue has come up a number of times in the past. If there are good quality free variable width stroke fonts available for CJK we could possibly do this and deprecate kicad’s own font definitions in favor of standard formats for stroked fonts. Another option (if anyone has time) is to write a library which would take the rasterized output of a font library and convert to a set of polygons representing an outline - this at least eliminates the need for users to do various conversions. However, we would need to handle kicad’s constant width stroked fonts differently from polygon/outline fonts otherwise the kicad font rendering will suffer bloating. We’ll need help from Chinese users to identify candidates for a good free font (and same goes for users of other non-Latin scripts).
Schematic text, especially the Title Block text, has less constraints than PCB text, which has to be rendered and converted to Gerber
Thank you for your answer.
A while back I fooled around with the gnu unifont .bdf 16x16 bitmapped font, and converted the complete set of CJK glyphs to symbols which can be used in gEDA PCB with a bit of tedious substitution.
A little bit of scripting is all that stands between a Unicode search of the glyph tarball archive I made
and output of a suitably scaled KiCad footprint (module) with the CJK glyph rendered as silk lines.
Given it’s bitmapped provenance, it won’t be as pretty as a converted ttf glyph, but it is probably the simplest option available currently, other than the graphic to silkscreen conversion you are currently using. It is also well suited to gerber output as it consists entirely of stroked elements, rather than outlines or polygons.
P.S. Here’s an example glyph from the tarball:
#the horizontal elements
SymbolLine[5000 1800 11400 1800 800]
SymbolLine[4200 3400 12200 3400 800]
SymbolLine[1800 4200 2600 4200 800]
SymbolLine[6600 5000 11400 5000 800]
SymbolLine[6600 6600 11400 6600 800]
SymbolLine[10600 9000 11400 9000 800]
SymbolLine[5800 12200 10600 12200 800]
#the vertical elements
SymbolLine[2600 3400 2600 9000 800]
SymbolLine[2600 10600 2600 11400 800]
SymbolLine[3400 1800 3400 2600 800]
SymbolLine[5000 3400 5000 7400 800]
SymbolLine[5000 9800 5000 11400 800]
SymbolLine[6600 1000 6600 9000 800]
SymbolLine[9000 1000 9000 8200 800]
SymbolLine[9800 10600 9800 12200 800]
SymbolLine[11400 3400 11400 9000 800]
SymbolLine[12200 11400 12200 12200 800]
#diagonal elements, strokes going downwards and leftwards
SymbolLine[4200 1000 3400 1800 800]
SymbolLine[3400 2600 1000 5000 800]
SymbolLine[5000 7400 4200 8200 800]
SymbolLine[2600 11400 1800 12200 800]
#diagonal elements, strokes going downwards and rightwards
SymbolLine[5000 11400 5800 12200 800]
SymbolLine[6600 9000 8200 10600 800]
SymbolLine[3400 2600 4200 3400 800]
SymbolLine[11400 10600 12200 11400 800]
SymbolLine[4200 1000 5000 1800 800]
) #end symbol ‘uni618A’
KiCad currently uses a vector font called NewStroke, provided by http://vovanium.ru/sledy/newstroke/en. Since KiCad previously used a Hershey font, a similar encoding is used. Coordinate pairs are packed into two ASCII characters, with coordinates in the approx +/-50. You can see the Kicad file here https://github.com/KiCad/kicad-source-mirror/blob/master/common/newstroke_font.cpp
const char* const newstroke_font =
/* // BASIC LATIN (0020-007F) /
“JZ”, / U+20 SPACE */
“H]LM[M RRDL_ RYVJV RS_YD”,
“F^J[ZF RMFOGPIOKMLKKJIKGMF RYZZXYVWUUVTXUZW[YZ”,
So I think if the new font data can be encoded in “Hershey” format, it could be merged with the current font data quite easily. I suspect there may be more to it, but having the data in a Kicad friendly format seems like a good start.
I was planning to write some generic glyph->Hershey code soon to allow Hershey font export from fonts created and edited in the gEDA PCB fork, pcb-rnd, i.e. for use with eggbots and the like; I can put the CJK glyphs->Hershey format job on the list of things to try.
It’ll end up being a pretty big blob of CJK glyph data, even in Hershey format.
For fun I created a sample of component symbols based on your data:
The height is approx 50 mil, some western text shown for comparison. It seems fairly readable, I would have to leave it to language experts to properly judge that. I wasn’t sure of the scaling of the data so that may have messed up the rendering.
I think that scalability would have to be considered, whether the data is in text or binary. Text makes an easier way to compile in of course. I think I would at least split the Hershey data into manageable blocks. The Hershey data could be packed more, but the source files might get bigger. Using null-terminated strings has some advantages, so if you could avoid use NULL character there are 255 values to play with.
CJK_font.lib (86.1 KB)
Nice work on the rendering there!
In general, gEDA PCB’s file format uses centimils, i.e. 1mil/100, when surrounded by square brackets, and mils, when the values are surrounded by rounded brackets.
So, with the squared brackets, the above dimensions are in centimils, and the width, for example, quoted as 800 for each SymbolLine stroke, is 8mil, which is a reasonable minimum stroke width for silkscreen text on a PCB.
There are various versions of Hershey “NIST style” vector font description, such as that used by the eggbot
and I see the more ASCII “NIST based” approach used by http://vovanium.ru/sledy/newstroke/en
Is there a good write up or description of the format used in https://github.com/KiCad/kicad-source-mirror/blob/master/common/newstroke_font.cpp ?
I’m having trouble discerning an explicit L (line) or M (move) instruction in the example you provide in keeping with the original NIST format. Is each pair of coordinates a discrete line assuming no connection to the previous pair of coordinates, or are polylines implied at all times and terminated with a space, with the next stroke within the glyph starting with “R”?
Also, the newstroke format seems to use a larger range of ASCII values than the original NIST format.
Is there an ASCII value that is the notional “Centre” x=0 coordinate in the newstroke format? Similarly, is there an ASCII value that is the notional “Centre” y=0 or y = glyph baseline coordinate in the newstroke format?
Is the width of the space character “JZ” equal to Z-J = 20 units on the x-axis?
On closer inspection, you’ll see that the CJK font data I converted basically represents a 16x16 grid of pixels on an 800 centimil grid, with an x offset and y offset of +1000 centimils respectively for kerning and to allow for glyph descent below the text baseline, so if the newstroke format can accommodate 16 coordinate values in the Y direction, and 16 coordinate values in the X direction, the conversion to a representation in newstroke format can be lossless.
It would probably be sensible to produce chunks of Hershey font data in suitably sized unicode code-blocks, to simplify searching and/or caching.
I want to add chinese to new_stroke font, and Japanese font has new stroke font,
is there any idea, thanks.
I didn’t feel the bitmap to stroke conversion provides good enough quality, so I didn’t pursue that.
Therefore what is needed is good quality stroke data for Chinese characters, or someone willing to create the data. It could be created using the KiCad symbol editor, then it would be easy to convert to Hershey data to include in KiCad.
How did you get that lib file to load, since it uses floating point coordinates?
Do you have another version with integer coordinates?
okay, got it to load under 4.x and saved it, which converted the coordinates to integer.
I noticed it truncated rather than rounded.
The thread is old and the old answers are still valid. You gave a wrong answer, so you didn’t understand the problem, did you?
In the future opentype fonts may be supported in schematics, but pcb layout is a different story.
For CJK fonts, please refer to Adobe-font.
Prefer to be able to use TTF/OTF fonts to display CJK characters