[geda-user] Chinese glyph rendering in pcb as symbols

[Erich Heinzle]

After playing with paths over existing glyphs and deciding this was
impractical for generating a set of glyphs for geda PCB, I explored
available open unicode chinese fonts and discovered the Firefly ttf font
which includes embedded 12x12~16x16 bitmap fonts for rendering at smaller
sizes, and ttf at larger sizes.

The Taiwanese OSS writer, Firefly, completed and released this font set in
2005.

http://wiki.laptop.org/go/Traditional_Chinese

http://www.study-area.org/apt/firefly-font/fireflysung-1.3.0.tar.gz


I have written a conversion utility that takes the 16x16 bitmap and turns
it into paths contained within a symbol for use on a PCB layout. This
theoretically makes some 16976 traditional and simplified chinese glyphs
available for use by PCB users, which seems like a good start.

I have attached an example of four unicode glyphs, first rendered as a dot
matrix "bitmap", and then rendered as strokes. The strokes are more
efficient in terms of symbol size, and scale much better i.e. with "s" or
"shift"+"s"

I have mapped them to some latin letters to make viewing easier.

Those interested can compare the rendered glyphs to those on an online
glyph browser

http://www.cojak.org/index.php?function=code_lookup&term=68FB

So, two main options that come to mind are to either:

1) generate a set of 16976 glyphs for use by users and have them as
standalone symbol files in a directory, or

2) let PCB convert them on the fly from the "bdf" archive using the
conversion code

What is then needed for ease of use is a dialogue box or similar for a user
to insert a glyph, in a fashion not unlike inserting text, but letting the
user insert the unicode designation of the needed glyph, i.e. "68FB"

I now need to clean up and refine the automated conversion code.

Cheers,

Erich.

[DJ Delorie]

I think keeping everything as a stroked font makes much more sense,
since pcb doesn't support bitmap fonts anyway.

The tricky part is supporting more than just 255 unique glyphs at one time.

[Bert Timmerman]

Post by DJ Delorie
I think keeping everything as a stroked font makes much more sense,
since pcb doesn't support bitmap fonts anyway.
The tricky part is supporting more than just 255 unique glyphs at one time.

Hi Erich,

I can see the potential of including the ability to make these symbols
available to the thousands, maybe even tens of thousands, of potential
Chinese users.

It could open up a whole new user base providing we can get pull down
menus and other text in the GUI translated as well.

The tricky part is how to implement them symbols into pcb, and agree
with DJ point above as not to get additional dependencies for users, for
users it should just work without a hassle.

If the current version of pcb is only capable of addressing 255
characters than that is the first hurdle to take.

Being able to address 2^16 characters (65k) may be enough ?

One thing I can foresee is that pcb files with Chinese fonts will become
larger.


Maybe it's time to start up a bug report in Launchpad so this idea won't
be forgotten in a couple of weeks ?

I will try to find spare cycles to look into how characters are
addressed in pcb and see what mechanism would be required.

Don't expect that this will be soonish as I have a busy schedule.

Kind regards,

Bert Timmerman.

[DJ Delorie]

Post by Bert Timmerman
If the current version of pcb is only capable of addressing 255
characters than that is the first hurdle to take.

The 255 is not official, either. Officially we support 127
characters, plain ASCII, because our file format is plain ASCII.

Post by Bert Timmerman
Being able to address 2^16 characters (65k) may be enough ?

UTF-8 is the way to go. It's backwards-compatible with ASCII. IMHO,
at this point it's foolish to contemplate anything else.

Post by Bert Timmerman
One thing I can foresee is that pcb files with Chinese fonts will
become larger.

We'd need a way to refer to an external font somehow, but then we have
the problem of PCB files no longer being idempotent.

Embedding large fonts might only be practical if we switch to a binary
format that can embed the compressed font as-is, but we'd need a way
to convert to-from text format, or use a container like zip, to work
with existing tools that want a plain text file.

[Bernd Walter]

Post by DJ Delorie

Post by Bert Timmerman
If the current version of pcb is only capable of addressing 255
characters than that is the first hurdle to take.

The 255 is not official, either. Officially we support 127
characters, plain ASCII, because our file format is plain ASCII.

Post by Bert Timmerman
Being able to address 2^16 characters (65k) may be enough ?

UTF-8 is the way to go. It's backwards-compatible with ASCII. IMHO,
at this point it's foolish to contemplate anything else.

Post by Bert Timmerman
One thing I can foresee is that pcb files with Chinese fonts will
become larger.

We'd need a way to refer to an external font somehow, but then we have
the problem of PCB files no longer being idempotent.
Embedding large fonts might only be practical if we switch to a binary
format that can embed the compressed font as-is, but we'd need a way
to convert to-from text format, or use a container like zip, to work
with existing tools that want a plain text file.

I edit a whole lot manually in my PCB files and I use subversion to
many changes.
If we really have to embed binary data, then I would very much prefer
any kind of hex or mime encoding, so that it's still possible to edit
the non binary parts.

[DJ Delorie]

Post by Bernd Walter
If we really have to embed binary data, then I would very much
prefer any kind of hex or mime encoding, so that it's still possible
to edit the non binary parts.

I really would rather avoid hex/mime as an embedding mechanism. Yech!

[Bernd Walter]

Post by DJ Delorie

Post by Bernd Walter
If we really have to embed binary data, then I would very much
prefer any kind of hex or mime encoding, so that it's still possible
to edit the non binary parts.

I really would rather avoid hex/mime as an embedding mechanism. Yech!

I'm not a big fan of it either, but I'm a big fan of the current ASCII
board data.

[Jason White]

Post by DJ Delorie
UTF-8 is the way to go. It's backwards-compatible with ASCII. IMHO,
at this point it's foolish to contemplate anything else.

Post by Bert Timmerman
One thing I can foresee is that pcb files with Chinese fonts will
become larger.

We'd need a way to refer to an external font somehow, but then we have
the problem of PCB files no longer being idempotent.
Embedding large fonts might only be practical if we switch to a binary
format that can embed the compressed font as-is, but we'd need a way
to convert to-from text format, or use a container like zip, to work
with existing tools that want a plain text file.

I think zip would certainly be the most flexible path, that way you
can keep the human readable layout files and include whatever fonts or
images are required without inserting huge ASCII-encoded binary blobs
all over the place.

The tools and scripts would still work, all you'd have to do is feed them
the text file from the zip.

This also could (if one was so inclined) provide a means of isolating
the various components of a design, footprints, symbols, etc. from
the particular system or environment so that they travel with the file.

Element definitions could be moved to an internal folder in the zip
called "elements". This might also facilitate the creation of self
contained libraries. Which would be a boon to users I'd think.

[Bernd Walter]

Post by Jason White

Post by DJ Delorie
UTF-8 is the way to go. It's backwards-compatible with ASCII. IMHO,
at this point it's foolish to contemplate anything else.

Post by Bert Timmerman
One thing I can foresee is that pcb files with Chinese fonts will
become larger.

We'd need a way to refer to an external font somehow, but then we have
the problem of PCB files no longer being idempotent.
Embedding large fonts might only be practical if we switch to a binary
format that can embed the compressed font as-is, but we'd need a way
to convert to-from text format, or use a container like zip, to work
with existing tools that want a plain text file.

I think zip would certainly be the most flexible path, that way you
can keep the human readable layout files and include whatever fonts or
images are required without inserting huge ASCII-encoded binary blobs
all over the place.
The tools and scripts would still work, all you'd have to do is feed them
the text file from the zip.

I consider this impractical if you regulary switch between text editor
and PCB.
And it completely breaks revision control systems without having a
specific ZIP plugin.

Post by Jason White
This also could (if one was so inclined) provide a means of isolating
the various components of a design, footprints, symbols, etc. from
the particular system or environment so that they travel with the file.
Element definitions could be moved to an internal folder in the zip
called "elements". This might also facilitate the creation of self
contained libraries. Which would be a boon to users I'd think.
--
Jason White

[Jason White]

Post by Bernd Walter

Post by Jason White
I think zip would certainly be the most flexible path, that way you
can keep the human readable layout files and include whatever fonts or
images are required without inserting huge ASCII-encoded binary blobs
all over the place.
The tools and scripts would still work, all you'd have to do is feed them
the text file from the zip.

I consider this impractical if you regulary switch between text editor
and PCB.
And it completely breaks revision control systems without having a
specific ZIP plugin.

I'm curious if that is a very common use case among gEDA users?
I certainly spend a lot more time in the tool than the text editor.

I somewhat curious about your work flow. Do/can you branch and merge
PCB designs like source code? Are you using some external scripts to
generate features in your boards?

What about treating directories as files like the Netbeans IDE does
with its projects? Then optionally compressing them into a zip.
That would make it play nice with just about any version control
program while still allowing portable designs.

[Bernd Walter]

Post by Jason White

Post by Bernd Walter

Post by Jason White
I think zip would certainly be the most flexible path, that way you
can keep the human readable layout files and include whatever fonts or
images are required without inserting huge ASCII-encoded binary blobs
all over the place.
The tools and scripts would still work, all you'd have to do is feed them
the text file from the zip.

I consider this impractical if you regulary switch between text editor
and PCB.
And it completely breaks revision control systems without having a
specific ZIP plugin.

I'm curious if that is a very common use case among gEDA users?

No idea.
But the file format is very well documented and much easier to get than
some of the UI features.
Counting number of elements?
Start PCB, export the bom, then count, or just:
[485]devel> grep '^Element' pcb | wc -l
560
This is also quite handy without the wc to get an overview about the
Element flags used - sometimes some unintended sneaked it.
Same for Via, Pins, Pads, ...
Sometimes the count is required to get an idea about manufactoring costs.

Post by Jason White
I certainly spend a lot more time in the tool than the text editor.

Depend on which point in design I am.
I also spend most time in PCB for doing the layout itself.
However there are some points I prefer doing outside.
In many cases I don't knwo how to do it in PCB, or if it's possible at all.
Some examples:
Switch DRC setting for another board manufactorer, or optional higher
density feature set.
Just copy the DRC line is easy compared to go through all values by hand.
I do this a lot, as well as checking drawing properties.
Sometimes you switch if DRC clearance
There are a few I ocassionally change inside PCB, such as polygone clearance
or unique devicenames (for panelizing).
I do some automatic checks on wether those are in my default state.
I do all my footprint designs in text editor with PCB running at the
same time to visually inspect result (recent PCB versions detect newer file
dates and ask for reload).
The reason to do so is using exact locations and sizes is much easier in
the ASCII format than on screen, even became easier since PCB started
accepting mm values.
You can see if there are any changes at all before check in a new version.
Sounds simple, but in fact it has some strange dependencies.
For some time the crosshair position was saved, therefor it alwazs had
changes, then it started randomly reordering components.
There are many other things I do, such as mass updating flags and so on.
Now (20140316) it randomly switches some values from mm to mil and back:
[484]devel> svn diff
Index: pcb
===================================================================
--- pcb (revision 6621)
+++ pcb (working copy)
@@ -5845,7 +5845,7 @@

)

-Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 206.8805mm 37.7820mm 20.00mil 60.00mil 2 100 ""]
+Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 8144.90mil 37.7820mm 20.00mil 60.00mil 2 100 ""]
(
Pad[207.36mil 3.7498mm 241.34mil 3.7498mm 11.02mil 30.00mil 14.02mil "1" "1" "square,edge2"]
Pad[207.36mil 127.95mil 241.34mil 127.95mil 11.02mil 30.00mil 14.02mil "2" "2" "square,edge2"]
@@ -7185,7 +7185,7 @@

)

-Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 206.8805mm 89.2170mm 20.00mil 60.00mil 2 100 ""]
+Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 8144.90mil 89.2170mm 20.00mil 60.00mil 2 100 ""]
(
Pad[207.36mil 3.7498mm 241.34mil 3.7498mm 11.02mil 30.00mil 14.02mil "1" "1" "square,edge2"]
Pad[207.36mil 127.95mil 241.34mil 127.95mil 11.02mil 30.00mil 14.02mil "2" "2" "square,edge2"]

Post by Jason White
I somewhat curious about your work flow. Do/can you branch and merge
PCB designs like source code? Are you using some external scripts to
generate features in your boards?

I do branches, but merging almost always has to be done manually.
Very often i start project by reusing an existing layout, because a
new project just differs in some peripheral area.
Some of the unrequired part is wiped out by editor, some by PCB.
Sometimes the diffs help to distribute changes in common parts,
but it still is a lot of work.
The switch from pure mil values to mil values made it harder, but
I consider this a one time switch.

One of the most uncommon branch I do is for pogo pin adapters.
I branch the PCB file, remove all vias and wiring.
Then I add pseudo vias where I want pogo pins, where I have tooling holes,
at which positions the board has bare surface and can be pushed down
on the pogo needles, ...
Then I save, remove temporarily all components and export the drill
file, which is for the "vias" only, since I removed the components.
This is all done in PCB, but whenever my design changes I can easily
update the Elements in the pogo branch and handle the changes.
This can be done within PCB as well, but if done outside I can see
what changes there are and if I (for whatever reason) I missed something.
And I don't have to grab the mouse for that.

Post by Jason White
What about treating directories as files like the Netbeans IDE does
with its projects? Then optionally compressing them into a zip.
That would make it play nice with just about any version control
program while still allowing portable designs.

[DJ Delorie]

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).

[Evan Foss]

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

Post by DJ Delorie

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).

[Erich Heinzle]

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.

Post by Evan Foss
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

Post by DJ Delorie

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/

[DJ Delorie]

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.

Post by Erich Heinzle
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 :-)

[Erich Heinzle]

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.

Post by DJ Delorie
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.

Post by Erich Heinzle
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 :-)

[DJ Delorie]

Post by Erich Heinzle
The firefly bitmaps embedded within the chinese .ttf can be obtained as

The origin of this font isn't a stroked font? That's what we really
want for PCB, not a bitmap font.

[DJ Delorie]

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.

No reason why pcb couldn't present a glyph as a polygon instead of a
set of lines. Then it could draw any outline font "perfectly".

But to do a bitmap font, we'd need to convert each pixel into a
separate polygon (square).

The gerbers for either solution would be huge, though. Simple stroked
fonts (like pcb's default) are pretty gerber-friendly.

[Erich Heinzle]

Post by DJ Delorie
But to do a bitmap font, we'd need to convert each pixel into a
separate polygon (square).
The gerbers for either solution would be huge, though. Simple stroked
fonts (like pcb's default) are pretty gerber-friendly.

My parsing code turns contiguous vertical, diagonal and horizontal pixels
in the 16x16 bitmap stored in a bdf format into pcb strokes. That is how
the example I attached yesterday was done.

The example attachment also showed a "dot matrix" version of the glyphs for
comparison, if the bitmap is done without conversion into strokes.
Converting bitmap pixels to strokes as I have done is more evolved than dot
matrix, and less evolved than outline fonts, but it scales without losing
legibility and relies on gerber friendly strokes only.

Polygons would enable perfect rendering of outline fonts, but would be less
compact, and the symbol rendering code then has to be extended to support
polygons as well.

It seems the gnu project have released the unifont, which includes the
chinese characters, as a bdf.tar.gz file at

http://unifoundry.com/unifont.html

which, with the right parsing code, could generate stroked pcb symbols for
any of the unifont bitmaps.

Anyway, perhaps a native chinese speaker/reader/user is needed to opine on
the utility of bitmapped fonts or the need for more elegant outline fonts.

Cheers,

Erich.

[Erich Heinzle]

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.

[Peter Clifton]

Post by DJ Delorie
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.

Post by Erich Heinzle
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 :-)

Actually, I've seen zip files with non-compressed content...

The zip header lies at the end of the file, so at the very least - one
could append binary data and a zip structure at the end of the
conventional PCB file.

I think (but haven't checked), that it would be possible to force
non-compressed content as part of the actual zip file, so perhaps that
might be a way to strike a balance between revision control capable, and
adding structuring content into the file.

I'm not sure whether the zip header uses absolute offsets into the file
(if so, that would hamper direct editing of the file), but it might be
worth looking into.

[Ed Simmons]

Post by Jason White

Post by Bernd Walter

Post by Jason White
The tools and scripts would still work, all you'd have to do is feed them
the text file from the zip.

I consider this impractical if you regulary switch between text editor
and PCB.
And it completely breaks revision control systems without having a
specific ZIP plugin.

I'm curious if that is a very common use case among gEDA users?

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...

Just my 2p (I'm in England...;-) )

Ed

[mskala-iYp5QZLjffFsCj9YYT8S7fd9D2ou9A/]

Post by Jason White

Post by Bernd Walter
I consider this impractical if you regulary switch between text editor
and PCB.
And it completely breaks revision control systems without having a
specific ZIP plugin.

I'm curious if that is a very common use case among gEDA users?
I certainly spend a lot more time in the tool than the text editor.

I use revision control on PCB files and a non-text format would probably
be a dealbreaker for me. ZIP is *not* an adequate substitute; a directory
would be marginally usable. But UTF-8 text would be just fine.

I don't think embedding gigantic binary fonts is a good idea. Store the
name of the font, store the text in UTF-8, ship some standard fonts, and
if someone wants to use a non-standard font, then they are responsible for
seeing that it is installed on the systems where they will use the files.
That's what word processors do, and it works.

[Bert Timmerman]

Post by DJ Delorie

Post by Bert Timmerman
If the current version of pcb is only capable of addressing 255
characters than that is the first hurdle to take.

The 255 is not official, either. Officially we support 127
characters, plain ASCII, because our file format is plain ASCII.

Post by Bert Timmerman
Being able to address 2^16 characters (65k) may be enough ?

UTF-8 is the way to go. It's backwards-compatible with ASCII. IMHO,
at this point it's foolish to contemplate anything else.

Post by Bert Timmerman
One thing I can foresee is that pcb files with Chinese fonts will
become larger.

We'd need a way to refer to an external font somehow, but then we have
the problem of PCB files no longer being idempotent.
Embedding large fonts might only be practical if we switch to a binary
format that can embed the compressed font as-is, but we'd need a way
to convert to-from text format, or use a container like zip, to work
with existing tools that want a plain text file.

Hmm,

IMHO, it's better to embed the font in the pcb file and avoid the
"symversion" pitfall as in gschem et al.

Good for archiving/reclaiming *complete* projects as well.

Kind regards,

Bert Timmerman.

[Rupert Swarbrick]

Post by Bert Timmerman

Post by DJ Delorie

Post by Bert Timmerman
If the current version of pcb is only capable of addressing 255
characters than that is the first hurdle to take.

The 255 is not official, either. Officially we support 127
characters, plain ASCII, because our file format is plain ASCII.

Post by Bert Timmerman
Being able to address 2^16 characters (65k) may be enough ?

UTF-8 is the way to go. It's backwards-compatible with ASCII. IMHO,
at this point it's foolish to contemplate anything else.

Post by Bert Timmerman
One thing I can foresee is that pcb files with Chinese fonts will
become larger.

We'd need a way to refer to an external font somehow, but then we have
the problem of PCB files no longer being idempotent.
Embedding large fonts might only be practical if we switch to a binary
format that can embed the compressed font as-is, but we'd need a way
to convert to-from text format, or use a container like zip, to work
with existing tools that want a plain text file.

Hmm,
IMHO, it's better to embed the font in the pcb file and avoid the
"symversion" pitfall as in gschem et al.

Alternatively, allow the name of the font to be a path. Then if I just
want to use a system font, I give the name of the font. If I want to
bundle the font along with my PCB project (and geda schematic and
everything else I've been working on), I can specify it as something
like

./my-font.ttf

No binary blobs in the PCB file, sensible version control and no
significant change to the file format.


Rupert