Mail Archives: geda-user/2014/09/06/00:35:01
--001a1133b890968b4805025e1a1a
Content-Type: text/plain; charset=UTF-8
Fair point re: seamless ability of unicode to allow traditional ascii use
The firefly bitmaps embedded within the chinese .ttf can be obtained as
standalone bdf files
there is a bdf file for each bitmap size 11x11 through to 16x16
the tar.gz of all of them weighs in at 2.7MB
I started with 16x16 as I figured it would be the most readable, and the
stroked symbol can be scaled thereafter in PCB anyway.
PCB may need to be made cleverer when it scales up/down symbols, so that
the linewidths scale more proportionally.
-rw-rw-r-- 1 esh esh 2760898 Aug 30 22:37 ../firefly-bdf-bitmap.tar.gz
-rw-r--r-- 1 esh esh 2379772 Mar 27 2005 fireflyR11.bdf
-rw-r--r-- 1 esh esh 2469844 Mar 27 2005 fireflyR12.bdf
-rw-r--r-- 1 esh esh 2549475 Mar 27 2005 fireflyR13.bdf
-rw-r--r-- 1 esh esh 2638024 Mar 27 2005 fireflyR14.bdf
-rw-r--r-- 1 esh esh 2720938 Mar 27 2005 fireflyR15.bdf
-rw-r--r-- 1 esh esh 2812183 Mar 27 2005 fireflyR16.bdf
The relevant resolution bdf would be sufficient in the user's local pcb
installation if the larger ttf outline glyphs aren't going to be used.
My conversion code simply reads a bdf description extracted from a bdf
file, (the bdf file is a bunch of these statements) such as:
STARTCHAR uni68F9
ENCODING 26873
SWIDTH 1000 0
DWIDTH 16 0
BBX 15 15 0 -1
BITMAP
1020
1024
103E
1020
FDFC
1104
19FC
3504
55FC
5124
9020
97FE
1020
1020
1020
ENDCHAR
and the alpha code can spit out an xbm, a dot matrix pcb symbol, an ASCII
rendition, and a stroked PCB symbol.
On the fly conversion with a large bdf file should be simple enough. I am
not sure how much of a wrapper the ttf format would add.
I haven't got my code searching & extracting a glyph description from the
big bdf file yet, as I have been working on the heuristics. So far it only
processes a single bdf description that it is given and the code needs some
tidying up.
I agree with the already expressed sentiment that it would be really good
to grow the potential user base with glyph support.
Cheers
Erich.
On Sat, Sep 6, 2014 at 1:27 PM, DJ Delorie <dj AT delorie DOT com> wrote:
>
> The whole point of UTF-8 is that we don't need something to tell UTF-8
> strings from ascii strings :-)
>
> Symbol['<ascii character>']
> Symbol['<utf8 character>']
>
> And I don't think storing hundreds, if not thousands, of glyphs in the
> *.pcb file as Symbol[]s, makes any sense at all. We really need to be
> able to read a *.ttf file directly if we're going to support large
> fonts.
>
> > If the PCB file format becomes binary,
>
> I think a zip file is OK, because lots of OSS projects use zip, and
> the internal file is still ascii anyway so you can always extract it.
> Best of both worlds :-)
>
--001a1133b890968b4805025e1a1a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Fair point re: seamless ability of unicode to allow tradit=
ional ascii use<br><br>The firefly bitmaps embedded within the chinese .ttf=
can be obtained as standalone bdf files<br>there is a bdf file for each bi=
tmap size 11x11 through to 16x16<br>the tar.gz of all of them weighs in at =
2.7MB<br>I started with 16x16 as I figured it would be the most readable, a=
nd the stroked symbol can be scaled thereafter in PCB anyway.<br>PCB may ne=
ed to be made cleverer when it scales up/down symbols, so that the linewidt=
hs scale more proportionally.<br><div><br>-rw-rw-r-- 1 esh esh 2760898 Aug =
30 22:37 ../firefly-bdf-bitmap.tar.gz<br>-rw-r--r-- 1 esh esh 2379772 Mar 2=
7=C2=A0 2005 fireflyR11.bdf<br>-rw-r--r-- 1 esh esh 2469844 Mar 27=C2=A0 20=
05 fireflyR12.bdf<br>-rw-r--r-- 1 esh esh 2549475 Mar 27=C2=A0 2005 firefly=
R13.bdf<br>-rw-r--r-- 1 esh esh 2638024 Mar 27=C2=A0 2005 fireflyR14.bdf<br=
>-rw-r--r-- 1 esh esh 2720938 Mar 27=C2=A0 2005 fireflyR15.bdf<br>-rw-r--r-=
- 1 esh esh 2812183 Mar 27=C2=A0 2005 fireflyR16.bdf<br><br></div><div>The =
relevant resolution bdf would be sufficient in the user's local pcb ins=
tallation if the larger ttf outline glyphs aren't going to be used.<br>=
</div><div><br></div><div>My conversion code simply reads a bdf description=
extracted from a bdf file, (the bdf file is a bunch of these statements) s=
uch as:<br><br>STARTCHAR uni68F9<br>ENCODING 26873<br>SWIDTH 1000 0<br>DWID=
TH 16 0<br>BBX 15 15 0 -1<br>BITMAP<br>1020<br>1024<br>103E<br>1020<br>FDFC=
<br>1104<br>19FC<br>3504<br>55FC<br>5124<br>9020<br>97FE<br>1020<br>1020<br=
>1020<br>ENDCHAR<br><br></div><div>and the alpha code can spit out an xbm, =
a dot matrix pcb symbol, an ASCII rendition, and a stroked PCB symbol.<br><=
br></div><div>On the fly conversion with a large bdf file should be simple =
enough. I am not sure how much of a wrapper the ttf format would add.<br></=
div><div><br></div><div>I haven't got my code searching & extractin=
g a glyph description from the big bdf file yet, as I have been working on =
the heuristics. So far it only processes a single bdf description that it i=
s given and the code needs some tidying up.<br><br></div><div>I agree with =
the already expressed sentiment that it would be really good to grow the po=
tential user base with glyph support.<br><br></div><div>Cheers<br><br>Erich=
.<br></div><div><br></div><div class=3D"gmail_extra"><br><br><div class=3D"=
gmail_quote">On Sat, Sep 6, 2014 at 1:27 PM, DJ Delorie <span dir=3D"ltr">&=
lt;<a href=3D"mailto:dj AT delorie DOT com" target=3D"_blank">dj AT delorie DOT com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The whole point of UTF-8 is that we don't need something to tell UTF-8<=
br>
strings from ascii strings :-)<br>
<br>
Symbol['<ascii character>']<br>
Symbol['<utf8 character>']<br>
<br>
And I don't think storing hundreds, if not thousands, of glyphs in the<=
br>
*.pcb file as Symbol[]s, makes any sense at all.=C2=A0 We really need to be=
<br>
able to read a *.ttf file directly if we're going to support large<br>
fonts.<br>
<span class=3D""><br>
> If the PCB file format becomes binary,<br>
<br>
</span>I think a zip file is OK, because lots of OSS projects use zip, and<=
br>
the internal file is still ascii anyway so you can always extract it.<br>
Best of both worlds :-)<br>
</blockquote></div><br></div></div>
--001a1133b890968b4805025e1a1a--
- Raw text -