X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=o5n5f8CAp1sSFCVT+HKac6hlNn5uPDv92Ab+EUsfvPc=;
	b=gF7AN6C8i8U9NoTIDZQ1BbSaFCo9Ths0+vhlB1yb6BrkuPwS5XJ6/COAZXX8JV6L4W
	jpjDuGE73/Focn0CLdDUOjguoW4FaRBjZyZPcIE6gXsMPpIT7AbHptsNfFTgPpzge65W
	04xopBngCF6u7fa/zQzsxD1i6QKaWT4MEkW7gZSanuTGmf2bjk6QYqTjCf8bPUSekitB
	ULOaN4BCDkJXCr4eLOnW+O1IRw+VeHJjDtZIE8kbw+KdZ6m6eOhkrvOPRDZgJWYmuqgX
	EeGSSl8X5dk/47SyRwYweb+nWj+d9ARUzxX2ra7SsbhZj5mWVz9JRhXUtf4VeUg0N7i2
	eqWw==
MIME-Version:	1.0
X-Received:	by 10.52.230.226 with SMTP id tb2mr470887vdc.74.1410708590713;
	Sun, 14 Sep 2014 08:29:50 -0700 (PDT)
Date:	Mon, 15 Sep 2014 00:59:50 +0930
Message-ID:	<CAHUm0tNe1zgfb02ftk-o0dvaDUUuO0ed2VHgEcbgaqdZkjim0A@mail.gmail.com>
Subject:	[geda-user] A complete set of CJK glyphs rendered as PCB symbols
From:	Erich Heinzle <a1039181 AT gmail DOT com>
To:	geda-user <geda-user AT delorie DOT com>
Reply-To:	geda-user AT delorie DOT com

--089e0111b86e6e61270503083057
Content-Type: text/plain; charset=UTF-8

I have batch processed the gnu unifont bdf

http://unifoundry.com/pub/unifont-7.0.03/font-builds/unifont-7.0.03.bdf.gz

available from

http://unifoundry.com/unifont.html

to produce around 20,000 chinese, japanese and korean (CJK) symbols that
can be used in gEDA PCB.

the uncompressed text file weighs in at around 20MB, but compressed is only
1.5MB

http://users.on.net/~esh/geda/pcb/src/fonts/fireflyR16-CJK-glyphs.pcb.gz

Users requiring a few glyphs can now include them and map them to spare
ascii symbols until there is a way to more easily include unicode symbols,
i.e.

Symbol['6' 1200]
#gEDA PCB compatible symbol with drawn elements depicting uni9ED6
#Symbol['uni9ED6' 1200]
(  etc...
)

The symbols are based on the open 16x16 bitmapped firefly CJK font set and
have had contiguous pixels vertically, horizontally and diagonally
converted into SymbolLine[] strokes, and orphan pixels if any, are rendered
as a dot. A default stroke width of 800 has been used.

The smaller 11x11, 12x12 13x13, 14x14, 15x15 bitmapped CJK glyphs also
could be easily converted if necessary, but they may lack the fidelity of
the 16x16 glyphs which can be scaled anyway within PCB, so I have not
bothered to convert the lower resolution bitmaps at this stage.

I will release the the conversion utility shortly once I finish tidying it
up as GPL2+/-3.

I expected to walk away from the computer for at least a few minutes to
convert the 20,000+ CJK bdf archive but it was done in seconds, meaning
that on the fly importing of single CJK glyph bdf definitions from the
freely downloadable gnu unifont bdf could in theory be done from within PCB
if a suitable menu option were available.

I hope this is useful to anyone desperately in need of some functional CJK
glyphs before gEDA PCB supports either an integrated conversion process
like this or TTF support.

I cannot vouch for the rendering of all of the glyphs, as I do not read
Chinese, haven't had the chance to review them all, and the heuristics may
have joined the occasional diagonally adjacent pixels which should remain
unjoined.

The symbol archive is released under GPL2 or at your option, a later
version, and can be freely distributed.

I would make the observation that this approach to glyph rendering makes
for quite a compact symbol definition. My initial efforts involving
conversion of curved paths produced symbol definitions 3-4 times the
overall size, with implications for final PCB file size. It would be
interesting to see how much bigger or smaller gerbers might end up being if
text is rendered as polygons derived from TTF fonts.

If/when unicode support is implemented, I think it would be a useful
feature if users could retain the ability to use a traditional default_font
style font for the ASCII character code page, and a separate unicode font
for the other code pages, since available CJK containing fonts may not have
ASCII code page fonts ideally suited to rendering with strokes, whereas the
existing gEDA PCB ASCII fonts are pretty optimal, compact and gerber
friendly.

Cheers,

Erich.

--089e0111b86e6e61270503083057
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I have batch processed the gnu unifont bdf <br><=
br><a href=3D"http://unifoundry.com/pub/unifont-7.0.03/font-builds/unifont-=
7.0.03.bdf.gz">http://unifoundry.com/pub/unifont-7.0.03/font-builds/unifont=
-7.0.03.bdf.gz</a><br><br></div>available from<br><br><a href=3D"http://uni=
foundry.com/unifont.html">http://unifoundry.com/unifont.html</a><br><br></d=
iv>to produce around 20,000 chinese, japanese and korean (CJK) symbols that=
 can be used in gEDA PCB.<br><div><div><div><div><br></div><div>the uncompr=
essed text file weighs in at around 20MB, but compressed is only 1.5MB<br><=
br><a href=3D"http://users.on.net/~esh/geda/pcb/src/fonts/fireflyR16-CJK-gl=
yphs.pcb.gz">http://users.on.net/~esh/geda/pcb/src/fonts/fireflyR16-CJK-gly=
phs.pcb.gz</a><br><br></div><div>Users requiring a few glyphs can now inclu=
de them and map them to spare ascii symbols until there is a way to more ea=
sily include unicode symbols, i.e.<br><br>Symbol[&#39;6&#39; 1200]<br>#gEDA=
 PCB compatible symbol with drawn elements depicting uni9ED6<br>#Symbol[&#3=
9;uni9ED6&#39; 1200]<br></div><div>(=C2=A0 etc...<br></div><div>)<br><br></=
div><div>The symbols are based on the open 16x16 bitmapped firefly CJK font=
 set and have had contiguous pixels vertically, horizontally and diagonally=
 converted into SymbolLine[] strokes, and orphan pixels if any, are rendere=
d as a dot. A default stroke width of 800 has been used.<br><br></div><div>=
The smaller 11x11, 12x12 13x13, 14x14, 15x15 bitmapped CJK glyphs also coul=
d be easily converted if necessary, but they may lack the fidelity of the 1=
6x16 glyphs which can be scaled anyway within PCB, so I have not bothered t=
o convert the lower resolution bitmaps at this stage. <br><br></div><div>I =
will release the the conversion utility shortly once I finish tidying it up=
 as GPL2+/-3.<br><br></div><div>I expected to walk away from the computer f=
or at least a few minutes to convert the 20,000+ CJK bdf archive but it was=
 done in seconds, meaning that on the fly importing of single CJK glyph bdf=
 definitions from the freely downloadable gnu unifont bdf could in theory b=
e done from within PCB if a suitable menu option were available.<br><br></d=
iv><div>I hope this is useful to anyone desperately in need of some functio=
nal CJK glyphs before gEDA PCB supports either an integrated conversion pro=
cess like this or TTF support.<br><br></div><div>I cannot vouch for the ren=
dering of all of the glyphs, as I do not read Chinese, haven&#39;t had the =
chance to review them all, and the heuristics may have joined the occasiona=
l diagonally adjacent pixels which should remain unjoined.<br><br></div><di=
v>The symbol archive is released under GPL2 or at your option, a later vers=
ion, and can be freely distributed.<br><br></div><div>I would make the obse=
rvation that this approach to glyph rendering makes for quite a compact sym=
bol definition. My initial efforts involving conversion of curved paths pro=
duced symbol definitions 3-4 times the overall size, with implications for =
final PCB file size. It would be interesting to see how much bigger or smal=
ler gerbers might end up being if text is rendered as polygons derived from=
 TTF fonts.<br><br></div><div>If/when unicode support is implemented, I thi=
nk it would be a useful feature if users could retain the ability to use a =
traditional default_font style font for the ASCII character code page, and =
a separate unicode font for the other code pages, since available CJK conta=
ining fonts may not have ASCII code page fonts ideally suited to rendering =
with strokes, whereas the existing gEDA PCB ASCII fonts are pretty optimal,=
 compact and gerber friendly.<br></div><div><br></div><div>Cheers,<br><br>E=
rich.<br></div></div></div></div></div>

--089e0111b86e6e61270503083057--

- Raw text -