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:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=wD29ocb9wWy+jbihT9S+IfxvDSqMfXntpxXmXuCnfJk=;
        b=SJPjba5SH8SNjuP4gborhwuDraOULvCdcIDflAg2asRCMtkREDBRq0xbYrIL7L+9pw
         N+DOumIC3BaQk39jKxuvZ2bj2ss+8ZlNTvGiGVPKNub4ueKurPfGhINdzIXwZ2tSFIwF
         A94Ya+5sa9jdY7XbfB9E0wB0RZ9TF37YSfRIn7xKG2/J/Zn3DU0WYfkbFH7Y8+2k8ECc
         s2LQZgH/xV26bAJcu2iE9PVcELP5OEOGoqfcrg8Et0aGkwszwbIADHkoDD6X4lQx/O0D
         ZrN3411AcCHP01ttJspdyJTJUgZyKREwVyLDN756Q1dFyD/sf7bbvY2P+Tr0tagVJJCx
         4Wlw==
MIME-Version: 1.0
X-Received: by 10.52.26.206 with SMTP id n14mr11908244vdg.0.1409981527314;
 Fri, 05 Sep 2014 22:32:07 -0700 (PDT)
In-Reply-To: <201409060459.s864xXhR015788@envy.delorie.com>
References: <CAHUm0tMk1cQm_DPVt_swzTGDA+FRL-37fUougH_3hNaqwR_LOQ AT mail DOT gmail DOT com>
	<201409051618 DOT s85GIdb8024685 AT envy DOT delorie DOT com>
	<5409F1C2 DOT 3090406 AT xs4all DOT nl>
	<201409051752 DOT s85Hqnr2027362 AT envy DOT delorie DOT com>
	<CAOFvGD5S+Gw_TPiuu3VkT53jvLewZbiP6f2BTaFRhJJP7Ai-1Q AT mail DOT gmail DOT com>
	<20140905184829 DOT GH3196 AT cicely7 DOT cicely DOT de>
	<CAOFvGD5NT=mCa24GEfv2UKGam29-h47Q3NFdcx9Gw=pg3n49=g AT mail DOT gmail DOT com>
	<20140905204312 DOT GJ3196 AT cicely7 DOT cicely DOT de>
	<540A22EF DOT 5030701 AT estechnical DOT co DOT uk>
	<201409052113 DOT s85LDfxf001064 AT envy DOT delorie DOT com>
	<CAM2RGhRGb+Vzq8kH1NX=DrZZP7DMMu8b50LkLtsk6-jxYp-DyA AT mail DOT gmail DOT com>
	<CAHUm0tO5ZAE4FM0HF3TvK0LJVEP5ZHGPz6C_fTEvsLMqjdGquw AT mail DOT gmail DOT com>
	<201409060357 DOT s863vvBL013729 AT envy DOT delorie DOT com>
	<CAHUm0tONW9T4zqoj2Be==A2OMoCr310igPgpVkxnu58st4=RtQ AT mail DOT gmail DOT com>
	<201409060459 DOT s864xXhR015788 AT envy DOT delorie DOT com>
Date: Sat, 6 Sep 2014 15:02:07 +0930
Message-ID: <CAHUm0tND2b+5m0+F2bXNCrA8ZddDLGVx=R5G4r2dSX2dxgreGw@mail.gmail.com>
Subject: Re: [geda-user] Chinese glyph rendering in pcb as symbols
From: Erich Heinzle <a1039181 AT gmail DOT com>
To: geda-user <geda-user AT delorie DOT com>
Content-Type: multipart/alternative; boundary=20cf3079bd4e13559d05025ee849
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

--20cf3079bd4e13559d05025ee849
Content-Type: text/plain; charset=UTF-8

the reason that bitmaps are embedded within chinese truetype fonts for use
in the smaller renditions/point sizes is that it is difficult to scale an
outline font down for use on a display at smaller sizes. Web browsers often
use these bitmap glyph renditions for routine glyph display. The release of
the Firefly bitmaps was noteworthy for chinese FOSS users for this reason.

16x16 equates, IIRC, to about 12 point size on a screen.

converting an outline font reliably to strokes at the small sizes required
for rendering as small text on a PCB might also be difficult.

converting the bitmap to strokes, which is what I have done, was relatively
easy, and I suspect would be more efficient in terms of overall pcb symbol
description size than if converting an outline font.

by taking advantage of the open and available bitmap versions of unicoded
chinese glyphs, complete and functional glyph support is within fairly easy
each of PCB users. Down the track, if someone thinks they can replace the
code with something that will convert an outline font to a pcb symbol and
do a better job, the stroke rendering code could be replaced.

The gnu unifont takes a similar approach of using a bitmap for each unicode
symbol, and their unicode symbol descriptions could be used instead of the
FireFly bdf descriptors, with some minor modification of the parsing code,
i.e. see
http://en.wikipedia.org/wiki/GNU_Unifont

I might have a go at supporting gnu unifont conversion with the utility, as
their hexadecimal string is very similar in format to the bdf symbol
description now that I think about it, and it should allow the not uncommon
but slightly exotic latin symbols to be rendered too, i.e. accents in
greek, umlauts in german, etc...

Cheers,

Erich.

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

<div dir=3D"ltr"><div>the reason that bitmaps are embedded within chinese t=
ruetype fonts for use in the smaller renditions/point sizes is that it is d=
ifficult to scale an outline font down for use on a display at smaller size=
s. Web browsers often use these bitmap glyph renditions for routine glyph d=
isplay. The release of the Firefly bitmaps was noteworthy for chinese FOSS =
users for this reason.<br><br></div><div>16x16 equates, IIRC, to about 12 p=
oint size on a screen.<br></div><div><br></div>converting an outline font r=
eliably to strokes at the small sizes required for rendering as small text =
on a PCB might also be difficult.<br><div><br></div><div>converting the bit=
map to strokes, which is what I have done, was relatively easy, and I suspe=
ct would be more efficient in terms of overall pcb symbol description size =
than if converting an outline font.<br></div><div><br>by taking advantage o=
f the open and available bitmap versions of unicoded chinese glyphs, comple=
te and functional glyph support is within fairly easy each of PCB users. Do=
wn the track, if someone thinks they can replace the code with something th=
at will convert an outline font to a pcb symbol and do a better job, the st=
roke rendering code could be replaced.<br><br></div><div>The gnu unifont ta=
kes a similar approach of using a bitmap for each unicode symbol, and their=
 unicode symbol descriptions could be used instead of the FireFly bdf descr=
iptors, with some minor modification of the parsing code, i.e. see<br><a hr=
ef=3D"http://en.wikipedia.org/wiki/GNU_Unifont">http://en.wikipedia.org/wik=
i/GNU_Unifont</a><br><br></div><div>I might have a go at supporting gnu uni=
font conversion with the utility, as their hexadecimal string is very simil=
ar in format to the bdf symbol description now that I think about it, and i=
t should allow the not uncommon but slightly exotic latin symbols to be ren=
dered too, i.e. accents in greek, umlauts in german, etc...<br><br>Cheers,<=
br><br>Erich.<br></div></div>

--20cf3079bd4e13559d05025ee849--