Mail Archives: geda-user/2014/09/05/23:46:02
--001a11368e805d6d4805025d6b72
Content-Type: text/plain; charset=UTF-8
if the usual "Symbol" code can be extended to interpret both traditional
Symbol['a' 1200] (...) definitions, and usage where a unicode is quoted,
i.e. Symbol['U+68FA' 1200] (...), the issue is just where to store the
glyphs.
Perhaps for unicode symbols, PCB could look in a "fonts" or "elements" or
"glyphs" subdirectory if the definition is not embedded within the pcb file.
An alternative is perhaps an extended symbol, and again, PCB would know to
look in a "fonts" or "elements" or "glyphs" subdirectory. The ordinary
"Symbol" could then continue to use the default_font without change, i.e.
ExtendedSymbol['uni68FA' 1200]
{
SymbolLine[x1 y1 x2 y2 800]
...
SymbolLine[x1 y1 x2 y2 800]
}
A simple tar.gz or a simple text file (much like a .bdf document) of the
Firefly bitmaps converted into discrete pcb compatible symbols, dropped
into a /fonts or /glyphs subdirectory would be a pretty easy way for people
to add chinese/japanese etc support or new glyphs to their installation.
On the fly conversion of bitmaps may be more error prone than pre-converted
elements.
If the PCB file format becomes binary, it would increase the barriers to
users contributing to the project. Text format helps with troubleshooting a
great deal, and automated production of symbols etc...
Cheers
Erich.
On Sat, Sep 6, 2014 at 8:22 AM, Evan Foss <evanfoss AT gmail DOT com> wrote:
> If you have to break out a text editor then you are ether...
> 1. On the bleeding edge of what the tool can do.
> 2. Breaking the unix common sense of "Don't fight the tool."
> 3. Finding a lot of bugs in the tool.
>
> I do resort to text editing for changing PCB silk screen text and for
> renumbering footprints after I have the drawn dimensions correct. What
> are you doing?
>
> -Evan
>
>
>
> On Fri, Sep 5, 2014 at 5:13 PM, DJ Delorie <dj AT delorie DOT com> wrote:
> >
> >> I and many others use gschem and pcb files in version control of
> >> some sort. The text file format is a huge bonus for us. Any zip type
> >> compression to package a file is a bad move as it breaks version
> >> control. I also love being able to hack at the PCB file in a text
> >> editor...
> >
> > I would assume that a "pcb file" could be just the text file (no
> > binaries attached), or a zip file (for distribution or archiving), or
> > a plain directory that represents the zip file (text files and
> > binaries as separate files).
>
>
>
> --
> Home
> http://evanfoss.googlepages.com/
> Work
> http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
>
--001a11368e805d6d4805025d6b72
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>if the usual "Symbol" code can be exte=
nded to interpret both traditional
Symbol['a' 1200] (...) definitions, and usage where a unicode is q=
uoted, i.e. Symbol['U+68FA' 1200] (...), the issue is just where to=
store the glyphs.<br><div><br></div><div>Perhaps for unicode symbols, PCB =
could look in a "fonts" or "elements" or "glyphs&q=
uot; subdirectory if the definition is not embedded within the pcb file.<br=
></div><div><br></div>An alternative is perhaps an extended symbol, and aga=
in, PCB would know to look in a "fonts" or "elements" o=
r "glyphs" subdirectory. The ordinary "Symbol" could th=
en continue to use the default_font without change, i.e.<br></div><div><br>=
ExtendedSymbol['uni68FA' 1200]<br>{<br></div>=C2=A0=C2=A0 SymbolLin=
e[x1 y1 x2 y2 800]<br>=C2=A0=C2=A0 ...<br>=C2=A0=C2=A0 SymbolLine[x1 y1 x2 =
y2 800]<br>}<br><br></div><div>A simple tar.gz or a simple text file (much =
like a .bdf document) of the Firefly bitmaps converted into discrete pcb co=
mpatible symbols, dropped into a /fonts or /glyphs subdirectory would be a =
pretty easy way for people to add chinese/japanese etc support or new glyph=
s to their installation.<br></div><div><br></div><div>On the fly conversion=
of bitmaps may be more error prone than pre-converted elements.<br></div><=
div><br></div><div>If the PCB file format becomes binary, it would increase=
the barriers to users contributing to the project. Text format helps with =
troubleshooting a great deal, and automated production of symbols etc...<br=
><br></div><div>Cheers<br><br>Erich.<br></div><div><br><br></div><div><br><=
/div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, =
Sep 6, 2014 at 8:22 AM, Evan Foss <span dir=3D"ltr"><<a href=3D"mailto:e=
vanfoss AT gmail DOT com" target=3D"_blank">evanfoss AT gmail DOT com</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">If you have to brea=
k out a text editor then you are ether...<br>
1. On the bleeding edge of what the tool can do.<br>
2. Breaking the unix common sense of "Don't fight the tool."<=
br>
3. Finding a lot of bugs in the tool.<br>
<br>
I do resort to text editing for changing PCB silk screen text and for<br>
renumbering footprints after I have the drawn dimensions correct. What<br>
are you doing?<br>
<br>
-Evan<br>
<div><div><br>
<br>
<br>
On Fri, Sep 5, 2014 at 5:13 PM, DJ Delorie <<a href=3D"mailto:dj AT delorie=
.com" target=3D"_blank">dj AT delorie DOT com</a>> wrote:<br>
><br>
>> I and many others use gschem and pcb files in version control of<b=
r>
>> some sort. The text file format is a huge bonus for us. Any zip ty=
pe<br>
>> compression to package a file is a bad move as it breaks version<b=
r>
>> control. I also love being able to hack at the PCB file in a text<=
br>
>> editor...<br>
><br>
> I would assume that a "pcb file" could be just the text file=
(no<br>
> binaries attached), or a zip file (for distribution or archiving), or<=
br>
> a plain directory that represents the zip file (text files and<br>
> binaries as separate files).<br>
<br>
<br>
<br>
</div></div><span><font color=3D"#888888">--<br>
Home<br>
<a href=3D"http://evanfoss.googlepages.com/" target=3D"_blank">http://evanf=
oss.googlepages.com/</a><br>
Work<br>
<a href=3D"http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/" =
target=3D"_blank">http://forge.abcd.harvard.edu/gf/project/epl_engineering/=
wiki/</a><br>
</font></span></blockquote></div><br></div></div>
--001a11368e805d6d4805025d6b72--
- Raw text -