Font preferences not available anymore, internal font changed

[Agent24]

Somewhere between version 2009-02-16 and version 2010-05-05 the "Font Preferences" options all disappeared, also the internal font used for all text has changed.

Would be really nice to get the option to change the font, especially that used for Text drawn on the PCB itself.

I have uploaded screenshots showing the difference in the font and the removed menu items.

[Agent24 (tda7000)]

Couldn't see any way to add the screenshots when originally posting...

[Lorenzo Marcantonio (l-marcantonio)]

On Fri, 29 Oct 2010, Agent24 wrote:

> Somewhere between version 2009-02-16 and version 2010-05-05 the "Font
> Preferences" options all disappeared, also the internal font used for
> all text has changed.
>
> Would be really nice to get the option to change the font, especially
> that used for Text drawn on the PCB itself.

The GUI font should be that selected in the current theme (I think). The
PCB font is a special vector font (since it must be plotted on gerbers)
and ATM can't be changed without recompiling (and, anyway, you have to
*draw* a new one, before!).

The new vector font also support many accented letters because the old
one was ASCII only. I use in-house a font converted from the ISO autocad
one instead, for example.

There was some talk about truetype rasterizing (I even done a proof of
concept with mixed results) but I think it fell in the 'low priority
wishlist' bucket.

--
Lorenzo Marcantonio
Logos Srl

[Brian Bidulock (bidulock)]

I don't find the NewStroke font acceptable for fabrication outputs. It might be usable for EESCHEMA. Here's what I intended on doing:

Display and plotting of circular arc segments in character as well as straight line segments.

Support for multiple built-in fonts and loadable single-stroke fonts.

Support for direct loading of QCad CXF fonts, including, therefore, single-stroke representations of true-type fonts (outlines) created using the ttf2cxf tool. This would include searching the current directory for CXF fonts so that custom loadable fonts can be kept with the project files.

A provision for the user to change the maximum aspect ratio for a given font.

Modification to default font parameter dialog in PCBNEW and EESCHEMA to include font selection. I won't go to the extent of providing a font selection on each and every piece of text.

For backward compatibility, four built-in fonts will be provided: (1) The original KiCad modified Hershey's font. This will be the default (as it was before) for text in PCBNEW. (2) The QCad "unicode" font. This will be the default for EESCHEMA. (3) The NewStroke font. This is simply for those that became attached to it during its brief debut. (4) The QCad "iso" font. This is for Lorenzo.

An option for for simply using the QCad/AutoCAD "standard" font when exporting to DXF.

I think that I will do this on a separate branch and I don't know when I will get to it really. Are there any other requirements that one can think of?

[Lorenzo Marcantonio (l-marcantonio)]

On Fri, 29 Oct 2010, Brian Bidulock wrote:

> Display and plotting of circular arc segments in character as well as
> straight line segments.

Can't do bad, not really required; during the conversion from shp to
hershey a conversion to 16pt/circle (like that used for zone filling)
yields very good results.

> Support for multiple built-in fonts and loadable single-stroke fonts.

That's a big undertaking, however a choice for a 'system' font is doable
without problem.

> Support for direct loading of QCad CXF fonts, including, therefore,
> single-stroke representations of true-type fonts (outlines) created
> using the ttf2cxf tool. This would include searching the current
> directory for CXF fonts so that custom loadable fonts can be kept with
> the project files.

CXF fonts are ok (most are already hershey's anyway:D).
A converter/loader from CXF would be actually very similar to that
I already use for shp fonts (a lot simpler, I think). Never worked on it
simply because there are not many CXF around...

Using truetypes as outlines is actually a *very* bad idea, for several
reasons:
1) hinting would be wrong (but anyway they would be loaded without
hinting)
2) the glyphs would be hollow
3) The outline would be actually half outside of the glyph outline

These issues, with the typical silk resolution (0,2mm, but ink spreads
way more) makes such kind of characters absolutely awful in a fabricated
board (I've seen them, some CAD out there use the outline and a raster
fill to draw text, we're talking about unreadable blobs).

A much better way to do them is to pick a raster resolution (I found
0,1mm a good value) and scan convert the glyph *at the target size* i.e.
a 2mm character would be plotted with 20 scanlines; this gives very good
results on both silk and copper text (with an adequate font, obviously),
and it seems the algorithm used by Altium (with a magnifier you can see
the scanlines on the copper text).

The main issue is the awful quantity of vectors generated. No issue for
plotting (usually) but on screen is unacceptable (and good luck trying
to draw a 'native' truetype character on screen exactly aligned with the
result on plot, if you want to bypass the vector engine).

> A provision for the user to change the maximum aspect ratio for a given
> font.

Why that? Changing the aspect ratio is actually a bad idea in most
cases, if the user change it,it's because he need a specific effect (in
my experience labeling test points:D). That's one of the reasons because
I use the ISO font, it has a narrow aspect ratio (I like more the
character shapes of the new font, but it's too wide for my likings - it
was designed for compability with the old 'square' font).

> Modification to default font parameter dialog in PCBNEW and EESCHEMA to
> include font selection. I won't go to the extent of providing a font
> selection on each and every piece of text.

I'd like a 'style' subsystem, i.e. for labels, references, values; in
this way you could better merge libraries from different authors: for
example I use as a default text size 50mil, reference and values of
60mil and package name of 30mil. Labels are usually 50mils except labels
only for netcl...

[Wayne Stambaugh (stambaughw)]

On 10/29/2010 4:02 AM, Lorenzo Marcantonio wrote:
> On Fri, 29 Oct 2010, Agent24 wrote:
>
>> Somewhere between version 2009-02-16 and version 2010-05-05 the "Font
>> Preferences" options all disappeared, also the internal font used for
>> all text has changed.
>>
>> Would be really nice to get the option to change the font, especially
>> that used for Text drawn on the PCB itself.
>
> The GUI font should be that selected in the current theme (I think). The
> PCB font is a special vector font (since it must be plotted on gerbers)
> and ATM can't be changed without recompiling (and, anyway, you have to
> *draw* a new one, before!).

Yes, the UI font is the same font as the current theme which is platform
dependent. Looking at the screen shots Kicad appears to be using the same font
as every other windows program which is the correct behavior. This was changed
so that Kicad looks as native as possible on each platform. You should have
this font problem with every other application (which is most of them) that
used the default font. Change the UI font for the current theme.

>
> The new vector font also support many accented letters because the old
> one was ASCII only. I use in-house a font converted from the ISO autocad
> one instead, for example.
>
> There was some talk about truetype rasterizing (I even done a proof of
> concept with mixed results) but I think it fell in the 'low priority
> wishlist' bucket.
>

[Wayne Stambaugh (stambaughw)]

On 10/29/2010 8:10 AM, Lorenzo Marcantonio wrote:
> On Fri, 29 Oct 2010, Brian Bidulock wrote:
>
>> Display and plotting of circular arc segments in character as well as
>> straight line segments.
>
> Can't do bad, not really required; during the conversion from shp to
> hershey a conversion to 16pt/circle (like that used for zone filling)
> yields very good results.
>
>> Support for multiple built-in fonts and loadable single-stroke fonts.
>
> That's a big undertaking, however a choice for a 'system' font is doable
> without problem.

Please do not make the system (UI) font user configurable. This doesn't make
any sense as it already is configurable at the system level. If you have a
problem with the system UI font, you should change it to suite your own
sensibilities. Why would you find the system UI font unacceptable in Kicad but
acceptable in every other application? Has any one filed a bug report with
Microsoft or Apple that all their applications don't have a user configurable
UI font? I removed this code because it was applied inconsistently throughout
Kicad and served no real purpose.

I would like to see EESchema support user configurable fonts in schematics.
There is no need to use stroke fonts when plotting and printing schematics as
they don't suffer from the issues as plotting PCBs to Gerber files. However,
the I don't believe the current schematic file format supports saving font
information. You'll have to wait until the new schematic file format work is
complete before it even makes sense to work on this.

>
>> Support for direct loading of QCad CXF fonts, including, therefore,
>> single-stroke representations of true-type fonts (outlines) created
>> using the ttf2cxf tool. This would include searching the current
>> directory for CXF fonts so that custom loadable fonts can be kept with
>> the project files.
>
> CXF fonts are ok (most are already hershey's anyway:D).
> A converter/loader from CXF would be actually very similar to that
> I already use for shp fonts (a lot simpler, I think). Never worked on it
> simply because there are not many CXF around...
>
> Using truetypes as outlines is actually a *very* bad idea, for several
> reasons:
> 1) hinting would be wrong (but anyway they would be loaded without
> hinting)
> 2) the glyphs would be hollow
> 3) The outline would be actually half outside of the glyph outline
>
> These issues, with the typical silk resolution (0,2mm, but ink spreads
> way more) makes such kind of characters absolutely awful in a fabricated
> board (I've seen them, some CAD out there use the outline and a raster
> fill to draw text, we're talking about unreadable blobs).
>
> A much better way to do them is to pick a raster resolution (I found
> 0,1mm a good value) and scan convert the glyph *at the target size* i.e.
> a 2mm character would be plotted with 20 scanlines; this gives very good
> results on both silk and copper text (with an adequate font, obviously),
> and it seems the algorithm used by Altium (with a magnifier you can see
> the scanlines on the copper text).
>
> The main issue is the awful quantity of vectors generated. No issue for
> plotting (usually) but on screen i...

[Lorenzo Marcantonio (l-marcantonio)]

On Fri, 29 Oct 2010, Wayne Stambaugh wrote:

> I would like to see EESchema support user configurable fonts in schematics.
> There is no need to use stroke fonts when plotting and printing schematics as
> they don't suffer from the issues as plotting PCBs to Gerber files. However,
> the I don't believe the current schematic file format supports saving font
> information. You'll have to wait until the new schematic file format work is
> complete before it even makes sense to work on this.

Partly true. OTOH using truetypes in postscript isn't exactly trivial,
*expecially* using Unicode (remember that ps only uses 8 bit characters
and charmaps). Also you'd have to do type42 enconding and embedding of
the font itself (which is a PITA in itself). And HPGL is vector only
anyway (but I don't know if it's still used these days, maybe it could
be obsoleted that day).

I would solve the problem with pcbnew and then apply the same solution
to eeschema (if only because they share most of the drawing/plotting
code)

--
Lorenzo Marcantonio
Logos Srl

[Brian Bidulock (bidulock)]

Lorenzo,

On Fri, 29 Oct 2010, Lorenzo Marcantonio wrote:

> CXF fonts are ok (most are already hershey's anyway:D).
> A converter/loader from CXF would be actually very similar to that
> I already use for shp fonts (a lot simpler, I think). Never worked on it
> simply because there are not many CXF around...

You have a shp to kicad converter? Is it posted anywhere?

> Using truetypes as outlines is actually a *very* bad idea, for several
> reasons:

I don't really care about it. The ttf2cxf makes a CXF outline file from
the TTF font. If kicad is made to load CXF, TTF outlines come for free.
ttx2cxf uses Freetype and is simple. Making the program generate
reasonable center-lines instead of outline might not be impossible.

> > A provision for the user to change the maximum aspect ratio for a given
> > font.
>
> Why that?

Simply because the program currently imposes a subjective limit.

>
> > Modification to default font parameter dialog in PCBNEW and EESCHEMA to
> > include font selection. I won't go to the extent of providing a font
> > selection on each and every piece of text.
>
> I'd like a 'style' subsystem, i.e. for labels, references, values; in
> this way you could better merge libraries from different authors: for
> example I use as a default text size 50mil, reference and values of
> 60mil and package name of 30mil. Labels are usually 50mils except labels
> only for netclassing which are only 30mil, and so on.

I'll put the default font mechanism in an then you can add a style
subsystem over that. I don't think that it is worth the trouble myself.

> > For backward compatibility, four built-in fonts will be provided: (1)
> > The original KiCad modified Hershey's font. This will be the default
> > (as it was before) for text in PCBNEW. (2) The QCad "unicode" font.
>
> You *actually* like it?:D

Yes. I like it. For two reasons: it is clear and simple.

> > This will be the default for EESCHEMA. (3) The NewStroke font. This is
> > simply for those that became attached to it during its brief debut. (4)
> > The QCad "iso" font. This is for Lorenzo.
>
> I already have mine, thanks:D I also have a full Technical Set
> 1 repertoir done (containing such useful symbols like the AC/DC markings
> and so on).

Is there something stopping you from contributing this to KiCad?

> > An option for for simply using the QCad/AutoCAD "standard" font when
> > exporting to DXF.
>
> Really easy to do, just override the text primitive in the DXF plotter
> class. Didn't do it because results would be... well... questionable

If the images are laid out with the "standard" font, then the results
should be fine.

> I don't get why you would go thru the ttf2cxf utility... with freetype
> is very easy to get the outlines...

I think that off-line conversion is better. There is no need to add
another library dependency for performing a function that is better
performed off-line. ttf2cxf used the Freetype libary to perform its
functions.

> The real issue is that most fonts are *not* suitable for a plotting job,
> it's just that. You can scale a single stroke ISO (not outlined) font down
> to about 1,5mm and keep perfect readability (2mm gi...

[Brian Bidulock (bidulock)]

Wayne,

On Fri, 29 Oct 2010, Wayne Stambaugh wrote:

> Please do not make the system (UI) font user configurable.

I was only talking about plotting fonts, not UI font.

> I would like to see EESchema support user configurable fonts in schematics.
> There is no need to use stroke fonts when plotting and printing schematics as
> they don't suffer from the issues as plotting PCBs to Gerber files. However,
> the I don't believe the current schematic file format supports saving font
> information. You'll have to wait until the new schematic file format work is
> complete before it even makes sense to work on this.

Last I checked you could plot a schematic to a Gerber file.

--brian

[Wayne Stambaugh (stambaughw)]

On 10/29/2010 9:59 AM, Lorenzo Marcantonio wrote:
> On Fri, 29 Oct 2010, Wayne Stambaugh wrote:
>
>> I would like to see EESchema support user configurable fonts in schematics.
>> There is no need to use stroke fonts when plotting and printing schematics as
>> they don't suffer from the issues as plotting PCBs to Gerber files. However,
>> the I don't believe the current schematic file format supports saving font
>> information. You'll have to wait until the new schematic file format work is
>> complete before it even makes sense to work on this.
>
> Partly true. OTOH using truetypes in postscript isn't exactly trivial,
> *expecially* using Unicode (remember that ps only uses 8 bit characters
> and charmaps). Also you'd have to do type42 enconding and embedding of
> the font itself (which is a PITA in itself). And HPGL is vector only
> anyway (but I don't know if it's still used these days, maybe it could
> be obsoleted that day).

I wasn't suggesting that it would be trivial. I know better. Font handling
has never been easy and I don't see that changing any time soon.

>
> I would solve the problem with pcbnew and then apply the same solution
> to eeschema (if only because they share most of the drawing/plotting
> code)

I've looked at the FreeType documentation and it has some very interesting
capabilities. When using vector fonts you can get the line stokes for vector
glyphs. If these line strokes are in the correct drawing unit, it could be
useful. I don't know how accurate or complete it is but it certainly looks
interesting. The only downside is FreeType is a C library and I didn't see a
link to any C++ wrappers.

>

[Wayne Stambaugh (stambaughw)]

On 10/29/2010 10:11 AM, Brian Bidulock wrote:
> Wayne,
>
> On Fri, 29 Oct 2010, Wayne Stambaugh wrote:
>
>> Please do not make the system (UI) font user configurable.
>
> I was only talking about plotting fonts, not UI font.
>
>> I would like to see EESchema support user configurable fonts in schematics.
>> There is no need to use stroke fonts when plotting and printing schematics as
>> they don't suffer from the issues as plotting PCBs to Gerber files. However,
>> the I don't believe the current schematic file format supports saving font
>> information. You'll have to wait until the new schematic file format work is
>> complete before it even makes sense to work on this.
>
> Last I checked you could plot a schematic to a Gerber file.

Nope. I just looked. Although etching a schematic in copper might be an
interesting project, I don't know how useful it would be :)

>
> --brian
>

[Brian Bidulock (bidulock)]

Wayne,

On Fri, 29 Oct 2010, Wayne Stambaugh wrote:

> On 10/29/2010 10:11 AM, Brian Bidulock wrote:
> > Last I checked you could plot a schematic to a Gerber file.
>
> Nope. I just looked. Although etching a schematic in copper might be an
> interesting project, I don't know how useful it would be :)
>

Maybe I was thinking HPGL or DXF.

--brian

[Lorenzo Marcantonio (l-marcantonio)]

On Fri, 29 Oct 2010, Brian Bidulock wrote:

> You have a shp to kicad converter? Is it posted anywhere?

Done it for converting the ISO font. It's not posted because 1) it
somewhat hackish (and not every SHP opcode is handled) and 2) scaling is
hardcoded; I have no issues on publishing it, anyway. It's less than 500
C lines:P

You could modify it to generate CXF, it shouldn't be difficult.

> I don't really care about it. The ttf2cxf makes a CXF outline file from
> the TTF font. If kicad is made to load CXF, TTF outlines come for free.
> ttx2cxf uses Freetype and is simple. Making the program generate
> reasonable center-lines instead of outline might not be impossible.

Really hard, I think...

> Simply because the program currently imposes a subjective limit.

There *is* a limit? or are you talking about the stroke limit?

>>> This will be the default for EESCHEMA. (3) The NewStroke font. This is
>>> simply for those that became attached to it during its brief debut. (4)
>>> The QCad "iso" font. This is for Lorenzo.
>>
>> I already have mine, thanks:D I also have a full Technical Set
>> 1 repertoir done (containing such useful symbols like the AC/DC markings
>> and so on).
>
> Is there something stopping you from contributing this to KiCad?

Only that its metric and aspect ratio are mismatched for kicad hersheys
fonts... I've done it as a companion for the ISO (actually technical
greek is from ISO with some hand tweeking).

I also requisitioned the \ key as an escape code for it (it has an
unicode mapping but it's *really* awkward). It's all handled in the
drawtxt source.

> If the images are laid out with the "standard" font, then the results
> should be fine.

Then just emit a text dxf primitive, it's easy (but *no* unicode, if you
want to be portable).

> I think that off-line conversion is better. There is no need to add
> another library dependency for performing a function that is better
> performed off-line. ttf2cxf used the Freetype libary to perform its
> functions.

OK, my proposal: get kicad loading CXFs so you could load qcad and ttf
converted fonts (if you like them:P). Hersheys are trivial to convert to
CXF and we could modify/enhance the SHP converter to create CXF, too. So
with a single loader/renderer you'd use CXF, SHP, TTF and Hershey fonts.
I'd call it a win/win/win/win situation XD

> Plotting to copper and silk (PCBNEW) is one thing. That is where the
> old modified Hershey's font and the NewStroke font (and maybe your ISO
> font if you will contribute it) come in.

No problem to contribute it but I'm not sure about the licensing of the
ISO *shapes*...

> But then there is plotting schematics. EESCHEMA plots can use all kinds
> of wild and fancy fonts. There is no restriction on size here (just
> zoom in). Using actual TTF fonts in PS output would be just fine.

Even if you junk HPGL (I'd have nothing against but it's still uses for
inclusion by a lot of people), uploading, CID reencoding and using
a type42 (the PS format for truetypes) is anything but easy... of
course if you do it I'd be very happy to see it.

I found that the metrics needed for such a job are:
- Vertical height
- Ascend/baseline
- Aver...

[Lorenzo Marcantonio (l-marcantonio)]

On Fri, 29 Oct 2010, Brian Bidulock wrote:

> Last I checked you could plot a schematic to a Gerber file.

More than schematic on gerber (lol) it's HPGL which worries me, because
it's a de-facto standard for vector graphic inclusion. And as I said
before ttf in PS is not easy to do correctly.

--
Lorenzo Marcantonio
Logos Srl

[Lorenzo Marcantonio (l-marcantonio)]

On Fri, 29 Oct 2010, Wayne Stambaugh wrote:

> I wasn't suggesting that it would be trivial. I know better. Font handling
> has never been easy and I don't see that changing any time soon.

It's more adobe fault for still imposing a 7-bit clean encoding on
postscript (yep, a printer can happily choke on extended chars, even
using adobe standard encoding).

> I've looked at the FreeType documentation and it has some very interesting
> capabilities. When using vector fonts you can get the line stokes for vector
> glyphs. If these line strokes are in the correct drawing unit, it could be
> useful. I don't know how accurate or complete it is but it certainly looks

Yes, too bad that truetypes are *outline* fonts, not *vector* ones...
you can get (un)hinted outlines from truetype and type1 but ATM I don't
think there is some real vector font format supported (except maybe the
old windows FNT ones).

> interesting. The only downside is FreeType is a C library and I didn't see a
> link to any C++ wrappers.

I don't see any problem on this, it's perfectly useable from C++. You
have to do memory management but it's nothing complex.

--
Lorenzo Marcantonio
Logos Srl

[Lorenzo Marcantonio (l-marcantonio)]

On Fri, 29 Oct 2010, Wayne Stambaugh wrote:

> Nope. I just looked. Although etching a schematic in copper might be an
> interesting project, I don't know how useful it would be :)

I tested the gerber plotter with schematics too, trust me:D:D I wanted
to be sure it was actually generic:P

--
Lorenzo Marcantonio
Logos Srl

[Marius B. Kotsbak (mariusko)]

ApportVersion: 1.23-0ubuntu4
Architecture: i386
DistroRelease: Ubuntu 11.10
NonfreeKernelModules: ksplice_pbmwgiu0_vmlinux_new ksplice_pbmwgiu0 ksplice_ct7sazfs ksplice_krmjnvxg ksplice_hx623fn0 ksplice_4oeja2uc ksplice_41483s1e_vmlinux_new ksplice_41483s1e ksplice_6dc7tpwy_vmlinux_new ksplice_6dc7tpwy ksplice_afp00loi_vmlinux_new ksplice_afp00loi ksplice_teqoo91w_vmlinux_new ksplice_teqoo91w ksplice_qyp5yxfp_vmlinux_new ksplice_qyp5yxfp ksplice_vxo5sfg6_vmlinux_new ksplice_vxo5sfg6 ksplice_xjvtfy6n_vmlinux_new ksplice_xjvtfy6n ksplice_aoyveuuh_vmlinux_new ksplice_aoyveuuh ksplice_uxyxwka2_vmlinux_new ksplice_uxyxwka2 nvidia
Package: kicad 0.0.20110616-1
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=nb_NO.UTF-8
 LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:en
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic-pae 3.0.4
Tags: oneiric
Uname: Linux 3.0.0-12-generic-pae i686
UpgradeStatus: Upgraded to oneiric on 2011-10-14 (88 days ago)
UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin plugdev vboxusers video

[Marius B. Kotsbak (mariusko)]

apport information

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel Santos (daniel-santos)]

Hello guys. I see that this bug is fairly old, but as a person recently introduced to Kicad, I must tell you that the font appearance was an immediate turn-off! I know this sounds bubble-gum, twitter-ish, gen-me shallow, but first appearances really have a profound impact on the *perception* of quality.

It's been a while since I've played with fonts, but I agree that the font should not be compiled in and one should definately NOT have to manually draw a font! In fact, by zooming in on the schematic view and not researching at all, I could tell that the font was custom made from straight lines. So in other words, it's obvious.

It is my uneducated opinion that we *should* be able to use some existing font library to transform vector fonts into the language of gerber without too much problem, although I can't comment on what it would take to make the change in kicad. IMHO, the design should have abstracted the font from the start, although I realize the importance of sometimes "just getting a product done" and accepting costs like hard-coded fonts.

Is anybody still working on this?

[Wayne Stambaugh (stambaughw)]

On 10/11/2013 2:19 PM, Daniel Santos wrote:
> Hello guys. I see that this bug is fairly old, but as a person recently
> introduced to Kicad, I must tell you that the font appearance was an
> immediate turn-off! I know this sounds bubble-gum, twitter-ish, gen-me
> shallow, but first appearances really have a profound impact on the
> *perception* of quality.
>
> It's been a while since I've played with fonts, but I agree that the
> font should not be compiled in and one should definately NOT have to
> manually draw a font! In fact, by zooming in on the schematic view and
> not researching at all, I could tell that the font was custom made from
> straight lines. So in other words, it's obvious.

If you read all of messages in this bug report, I don't think anyone
would disagree with you that the stroke fonts are less than ideal. They
do allow us to guarantee the accuracy of the output.

>
> It is my uneducated opinion that we *should* be able to use some
> existing font library to transform vector fonts into the language of
> gerber without too much problem, although I can't comment on what it
> would take to make the change in kicad. IMHO, the design should have
> abstracted the font from the start, although I realize the importance of
> sometimes "just getting a product done" and accepting costs like hard-
> coded fonts.

I doubt there is anything easy about using "some existing font library"
to transform them into the gerber format unless you don't care about
accuracy or someone else is doing the work ( which I find are always the
easiest tasks to do :) ). If it was easy, someone would have done it by
now. KiCad is getting to the point where there are not many easy tasks
left to do. Most of the wishlist issues are very significant
development efforts that require some financial incentive to motivate
developers to work on them or high quality patches that don't require a
huge amount of lead developer time to commit. While I agree that there
is a difference between rendering fonts in the schematic editor where
the output accuracy isn't as critical as the board font rendering,
Pcbnew and Eeschema share common font rendering code so it's not that
easy to replace.

>
> Is anybody still working on this?
>

I don't think anyone ever worked on this other than take a look at the
effort involved. If you are feeling motivated, by all means give it a
try. We are always looking for motivate developers who are willing to
work with the KiCad development team.

Wayne

[Daniel Santos (daniel-santos)]

> or someone else is doing the work ( which I find are always the
> easiest tasks to do :) ).

Yes, so very true! :)

> If you are feeling motivated, by all means give it a
> try. We are always looking for motivate developers who are willing to
> work with the KiCad development team.

Sadly, I'm famous for getting side-tracked by stuff like this so maybe I can at least investigate it.

[Daniel Santos (daniel-santos)]

From a cursory examination of the Gerber spec (which I've never worked with before). It looks like the appropriate way to render an arbitrary font from it's vector representation is to render each non-contiguous shape of each glyph as a single contour (enable region mode with G36, draw the contour and then end the region mode with G37). Now this is tricky for many reasons.

1. The contour cannot self-intersect, except for coincidental segments, i.e., those who's start and end vertices are identical. This isn't a bad thing alone. The bad part is that non-coincidental intersections can occur due to rounding, creating a bad gerber for one device that is rendering it, but not another. :( Thus, we have to know in advance what this minimal pixel rounding value will be so we don't accidentally generate a bad gerber.
2. We don't get to work with actual polynomials, so everything has to be converted into straight lines and arcs.
3. Dealing with holes in glyphs (as in the letters 'O', 'p' and 'B') is a little bit of a pain because you have to add them as additional layers. If that hole needs to have something inside of it (I can't think of any English or Latin character examples), then 3 layers must be used, etc.

So I would say that the way to perform this conversion is basically to have some type of resolution setting, but not in pixels, just to say how the glyph will be approximated and control the number of gerber instructions. Then an engine to "render" the glyphs into approximations using straight lines and arcs (for the outline) followed by holes (and possibly shapes within those holes, as there are quite likely languages that will need this). All of this while avoiding illegal overlaps in verticies as they may occur after rounding, even rounding as a result of progressive processing on a single contour! (See §4.4.8 of the spec, page 58 for one example of this.)

To make this even more fun, it would seem that there would also be a need to render the font on-screen that way as well, so that we can actually see what we're going to get. I suppose, that that part won't be as difficult as the actual conversion into a gerber-compatible format, although it sounds like it may be a pain. For example, if rendering straight to opengl, you can't draw convex polygons, you have to break them into triangles, etc.

[Lorenzo Marcantonio (l-marcantonio)]

On Sun, Oct 13, 2013 at 04:28:58AM -0000, Daniel Santos wrote:
> >From a cursory examination of the Gerber spec (which I've never worked
> with before). It looks like the appropriate way to render an arbitrary
> font from it's vector representation is to render each non-contiguous
> shape of each glyph as a single contour (enable region mode with G36,
> draw the contour and then end the region mode with G37). Now this is
> tricky for many reasons.

The recommended way to render arbitrary images/fonts in gerber (and
AFAIK the approach used by every CAD supporting truetype fonts in
gerber) is using horizontal rasters. Usually the raster pitch is wide as
the aperture or maybe half of it for better edge quality; also the
raster approach actually follows the mechanics of the silkscreen process
(which *is* done on a raster of wires...)

I did a proof-of-concept demo some year ago (about when we switched from
the 'squared' font) but the idea wasn't pursued for lack of interest
(and display performance reasons, too).

Another reason is that the plotting infrastructure need to implement
text in postscript/PDF too and that is even more tricky than gerber.

--
Lorenzo Marcantonio
Logos Srl

[Dick Hollenbeck (dickelbeck)]

http://timeguy.com/cradek/truetype

Is this anything?
 On Oct 13, 2013 2:25 AM, "Lorenzo Marcantonio" <email address hidden>
wrote:

> On Sun, Oct 13, 2013 at 04:28:58AM -0000, Daniel Santos wrote:
> > >From a cursory examination of the Gerber spec (which I've never worked
> > with before). It looks like the appropriate way to render an arbitrary
> > font from it's vector representation is to render each non-contiguous
> > shape of each glyph as a single contour (enable region mode with G36,
> > draw the contour and then end the region mode with G37). Now this is
> > tricky for many reasons.
>
> The recommended way to render arbitrary images/fonts in gerber (and
> AFAIK the approach used by every CAD supporting truetype fonts in
> gerber) is using horizontal rasters. Usually the raster pitch is wide as
> the aperture or maybe half of it for better edge quality; also the
> raster approach actually follows the mechanics of the silkscreen process
> (which *is* done on a raster of wires...)
>
> I did a proof-of-concept demo some year ago (about when we switched from
> the 'squared' font) but the idea wasn't pursued for lack of interest
> (and display performance reasons, too).
>
> Another reason is that the plotting infrastructure need to implement
> text in postscript/PDF too and that is even more tricky than gerber.
>
> --
> Lorenzo Marcantonio
> Logos Srl
>
> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/668145
>
> Title:
> Font preferences not available anymore, internal font changed
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/668145/+subscriptions
>

[Lorenzo Marcantonio (l-marcantonio)]

On Sun, Oct 13, 2013 at 08:49:40AM -0000, Dick Hollenbeck wrote:
> http://timeguy.com/cradek/truetype
>
> Is this anything?

Extracting the outlines from a TT is not difficult, actually... freetype
can give it to you ready to plot (FT_Outline_Decompose), you only have
to mess a little with quadric/cubic curves. The problem is that the
result at the small sizes used for silks and stuff is... well,
disappointing. That changes of course if you have access to photo-silk
instead of true silkscreening...

Also the cut-in feature for gerber fill seems a little tricky to use.
The problem outlined in pages 50-51 of the specs make me think a lot of
experimentation and care is needed.

I think it could be done (good quality results are not guaranteed,
anyway...). There *is* a reason for the major cad manufacturer to
recommend stroke fonts in place of outline ones.

--
Lorenzo Marcantonio
Logos Srl

[Wayne Stambaugh (stambaughw)]

On 10/13/2013 04:49 AM, Dick Hollenbeck wrote:
> http://timeguy.com/cradek/truetype
>
> Is this anything?
> On Oct 13, 2013 2:25 AM, "Lorenzo Marcantonio" <email address hidden>
> wrote:
>
>> On Sun, Oct 13, 2013 at 04:28:58AM -0000, Daniel Santos wrote:
>>> >From a cursory examination of the Gerber spec (which I've never worked
>>> with before). It looks like the appropriate way to render an arbitrary
>>> font from it's vector representation is to render each non-contiguous
>>> shape of each glyph as a single contour (enable region mode with G36,
>>> draw the contour and then end the region mode with G37). Now this is
>>> tricky for many reasons.

This is the hard part and what I was eluding to in the previous
conversation. I've never used the FreeType library but looking at the
API it looks like it provides a way to convert any font type it supports
to strokes as Lorenzo pointed out. The difficult part is accurately
converting this output into the gerber or any other file format for that
matter. Obviously it can be done. Other applications do it all the
time. However, this will require a lot of testing and visual comparison
which is always fraught errors. Over the years I've seen some very
expensive board layout software do a very poor job of rendering fonts to
gerbers. If we want to provide this for our users, I want make sure we
do it properly. At least the current line drawn fonts are accurate
which IMHO is more important when manufacturing PCBs than inaccurate
fancy TT fonts.

>>
>> The recommended way to render arbitrary images/fonts in gerber (and
>> AFAIK the approach used by every CAD supporting truetype fonts in
>> gerber) is using horizontal rasters. Usually the raster pitch is wide as
>> the aperture or maybe half of it for better edge quality; also the
>> raster approach actually follows the mechanics of the silkscreen process
>> (which *is* done on a raster of wires...)
>>
>> I did a proof-of-concept demo some year ago (about when we switched from
>> the 'squared' font) but the idea wasn't pursued for lack of interest
>> (and display performance reasons, too).

Maybe with the forthcoming OpenGL rendering, the performance issues will
be less of an issue. Of course, this means you would have to modify
both the GAL and the wxDC renderer to support FreeType fonts until all
of the KiCad rendering has been ported over to the OpenGL GAL.

>>
>> Another reason is that the plotting infrastructure need to implement
>> text in postscript/PDF too and that is even more tricky than gerber.

Yes. All of the output formats that KiCad supports would have to be
modified to support the new fonts as well. Now we have a more accurate
view of how large the task really is and there are probably some other
parts of KiCad this will effect (file formats?) that we haven't even
considered. I am all for high quality fonts for KiCad but I am opposed
to a partial implementation for obvious reasons. I am not trying to
discourage anyone and I think it is a great idea. I am only trying to
make sure anyone who takes on this task understands what's involved.

>>
>> --
>> Lorenzo Marcantonio
>> Logos Srl
>>
>> --
>> You received this bug not...

[Daniel Santos (daniel-santos)]

> I am all for high quality fonts for KiCad but I am opposed
> to a partial implementation for obvious reasons.

It may be worthwhile to consider partial implementation as an explicitly and loudly marked "EXPERIMENTAL" feature. Such a feature would typically have the text "(EXPERIMENTAL)" next to it in whatever menu or dialog box where it is enabled and when enabled, a pop-up appears explaining to the user what they are getting into when they enable it.

I'm reccomending this because projects following an iterative delivery model are historically more successful those following the waterfall model (i.e., "everything at once"). Further, since we are open source, these experimental features can be enabled/disabled via the configure/cmake script. :)

[Daniel Santos (daniel-santos)]

Fritzing project also staring at this quandary : https://code.google.com/p/fritzing/issues/detail?id=1568

Also, of possible interest is this dxf2gbr utility: http://www.artwork.com/acad/engine/index.htm

>> From a cursory examination of the Gerber spec (which I've never worked
>> with before). It looks like the appropriate way to render an arbitrary
>> font from it's vector representation is to render each non-contiguous
>> shape of each glyph as a single contour (enable region mode with G36,
>> draw the contour and then end the region mode with G37). Now this is
>> tricky for many reasons.
>
> The recommended way to render arbitrary images/fonts in gerber (and
> AFAIK the approach used by every CAD supporting truetype fonts in
> gerber) is using horizontal rasters. Usually the raster pitch is wide as
> the aperture or maybe half of it for better edge quality; also the
> raster approach actually follows the mechanics of the silkscreen process
> (which *is* done on a raster of wires...)

Hmm, while I'm not certain, we may be talking about the same thing, but from a different standpoint. I don't see any reference in the gerber spec to the word "raster". If you are talking about drawing straight lines with an apeture to to rasterize your own image, I'm wondering if this falls into the catagory of "stroke painting" which unamco is claiming to be "harmful" (see the PDF named "Gerber File Format: Painting Considered Harmful" on the page http://www.ucamco.com/downloads.aspx).

However, it was my understanding that a modern photoplotter would take your contour regions and rasterize them to produce the final output, leaving you to just draw what you need in as simple of terms as possible and let the plotter rasterize it. Please correct me if I'm misunderstanding something here.

[Lorenzo Marcantonio (l-marcantonio)]

On Sun, Oct 13, 2013 at 06:04:46PM -0000, Daniel Santos wrote:
> Hmm, while I'm not certain, we may be talking about the same thing, but
> from a different standpoint. I don't see any reference in the gerber
> spec to the word "raster". If you are talking about drawing straight
> lines with an apeture to to rasterize your own image, I'm wondering if
> this falls into the catagory of "stroke painting" which unamco is
> claiming to be "harmful" (see the PDF named "Gerber File Format:
> Painting Considered Harmful" on the page
> http://www.ucamco.com/downloads.aspx).

Yes, that is however referred to copper pours. It is indeed a deprecated
way to fill zones (however pcbnew still supports it), mainly because
it's difficult to handle with CAM processors, to check netlists and
fabrication rules. However text is (hopefully) far from copper areas or
on the silkscreen so it doesn't suffer from these drawbacks.

The main problem with area fills with fonts it the model used to
represent outlines and suboutlines (i.e. internal cutouts); the font
model uses the common 'postscript' model:

- Outlines are described with lines, quadric and cubic curves, depending
  on the font: truetype uses quadrics, Type1/CFF uses cubics; lines are
  represented as the obvious degeneration of said curves; orientation of
  the (sub)outlines is consistent and mandatory (I don't remember the
  details);

- Sub-outlines are handled closing the current outline and opening a new
  one. Inner area is described (IIRC) using the winding rule (need to
  check for details on this and on self intersecting outlines).

If you ever used Corel Draw/Adobe Illustrator/Inkscape that's the usual
graphic model for handling outlines.

Gerber instead uses a way different (and simpler) model for outlines:

- Outlines are described with lines and circular arcs (as different
  primitives), orientation is not defined nor required;

- There are no suboutlines, internal cutouts have to be represented with
  a zero-width isthmus cutting thru the filled area to the cutout. Page
  49 better explains that.

The most similar thing I can think of are autocad polylines and shapes.
In fact SHP/SHX fonts are described exactly as polylines and I actually
have a working converter from SHP to the Hershey encoding used by kicad
(my ISO branch uses an hand-tuned version of the ISOCP font).

The first difference is easily handled approximating the curves with lines
(fun fact: the bezier curves used by fonts can't actually exactly
describe circular arcs, which are the only gerber supported curves).
However the difference on suboutlines need to be resolved with
a numerically stable way to find a good point to cut the filled area:
think about the eye in the R glyph: you need to find a non
self-intersecting line connecting the perimeter with the eye (the
@ glyph is left as an exercise:D). The stability condition is needed
because the entry line and the exit line must be exactly overlapped to
avoid artifacts (remember: they can't self intersect so they must be the
same!). I'm not saying it can't be done but needs considerable
computational geometry experience (which I don't have...i.e. I haven't
a good idea on how to d...