New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide how to implement fonts in footprints and boards #165

Closed
ubruhin opened this Issue Jun 9, 2017 · 25 comments

Comments

Projects
None yet
6 participants
@ubruhin
Member

ubruhin commented Jun 9, 2017

One big problem is still to draw texts in boards in a way which also makes Gerber export possible. So the text needs to be convertible into simple polygons.

I think the text should not be converted into polygons just for the Gerber export, but even for displaying the text in the board editor. This way we can guarantee that the Gerber output is exactly the same as what is displayed in the board editor (WYSIWYG).

But which system/library should we use for converting text into simple polygons (a series of straight lines and arcs)? Most important would be to have a simple vector font (like many EDA tools), but it would be absolutely awesome if any TrueType font could be used (like Altium)!

From Gerber specifications:

4.17 Text in the Image
Gerber has no native font support – this adds too much complication in relation to the modest
text requirements in PCB fabrication data. Text must be represented as pure image data, best
as regions (contours), see 4.12. Painting the text area is anathema!
Font definitions often contain splines and Gerber does has linear and circular segments but no
splines. The splines must therefore be approximated to either linear or circular segments.
Circular is more precise with less objects than linear, but mathematically more complicated.

See also #153 which is about fonts in schematics. Maybe we could find a solution which is fine for schematics (where "pretty" fonts are needed) and boards (where Gerber export is needed).

@ubruhin ubruhin added the high prio label Jun 9, 2017

@ubruhin ubruhin added this to the 0.1 milestone Jun 9, 2017

@szg0000

This comment has been minimized.

szg0000 commented Jun 9, 2017

Let's use the fonts of the operating system. Let the user decide about the used fonts in schematic and gerber files.

@dbrgn

This comment has been minimized.

Contributor

dbrgn commented Jun 9, 2017

Let the user decide about the used fonts in schematic and gerber files.

It's not that easy. Gerber does not support bézier curves or splines, so TTF/OTF fonts cannot be directly represented in these formats.

@szg0000

This comment has been minimized.

szg0000 commented Jun 12, 2017

Think of the future of the Gerber format. If the future of the Gerber points to support TTF/OTF fonts, it can be accepted in LibrePCB. Can we involve somebody from gerber development side?

@rnestler

This comment has been minimized.

Member

rnestler commented Jun 14, 2017

Think of the future of the Gerber format. If the future of the Gerber points to support TTF/OTF fonts, it can be accepted in LibrePCB. Can we involve somebody from gerber development side?

Even if a newer Gerber standard would add support for TTF/OTF fonts (which I don't belive), I can't imagine manufactures to pick it up in a reasonable time. So we would generate Gerber data which one can't manufacture and thus is completely useless.

@rnestler

This comment has been minimized.

Member

rnestler commented Jun 14, 2017

But why is this issue so important? A first release doesn't need font support, does it?

@ubruhin

This comment has been minimized.

Member

ubruhin commented Jun 14, 2017

A first release doesn't need font support, does it?

A first release does require font support, otherwise it won't be able to place any text on boards (actually it would be possible to place texts, but they won't appear in Gerber output which is unacceptable in my opinion).

Although it is not required to support TTF/OTF fonts. Simple vector fonts would be fine for the first release. But the same problem exists: How to implement vector fonts?

@dbrgn

This comment has been minimized.

Contributor

dbrgn commented Jun 14, 2017

I disagree. Fonts are high priority, but not necessary for a first preview release. Footprints are more important :)

@ubruhin

This comment has been minimized.

Member

ubruhin commented Jun 14, 2017

Footprints are more important :)

And footprints have texts on the silkscreen layer ;) Footprints completely without text are a pain because in a board there are no designators, for example you don't see whether a resistor in the board is R1 or R2.

@k4rel

This comment has been minimized.

k4rel commented Jun 15, 2017

I do no think there is anything in the pipeline concerning fonts in gerber. Using TTF is not a good idea for the production process of copper layers or silk layers. This is why you see vector fonts most of the time. It contains enough space between lines to produce.
However there will always be people who insist on TTFs and are not too worried about the data getting 'optimized' for production. These are the texts that need to be contourized.
Vector Texts are only a bunch of draws, so it is not too complicated to implement. Most of the texts will belong to the components. You can add an attribute to them, so they can easily be recognized later on. Also upon gerber output these attributes can be exported (using the .C attribute). Afterwards the PCB producer can then easily recognize the components and therefore also the texts....

@rnestler

This comment has been minimized.

Member

rnestler commented Jun 15, 2017

You can add an attribute to them, so they can easily be recognized later on. Also upon gerber output these attributes can be exported (using the .C attribute). Afterwards the PCB producer can then easily recognize the components and therefore also the texts....

Could you elaborate a bit on this? What exactly could get exported into the Gerber files? And how can the PCB producer use this information?

@k4rel

This comment has been minimized.

k4rel commented Jun 15, 2017

The component library information from LibrePCB can find its way also into gerber. It means the pcb manufacturer then will know what elements are belonging to a BGA for example. In production, BGAs are handled differently then other components on the PCB. Especially the masks. The annular ring for a BGA is tighter then the one for a resistor. Without this info the producer must guess and handles all these masks openings manually, wasting a lot of time. When exporting the information about the type of components, the producer can just automate his optimisation of the board. For the text on the silk it would mean you can immediately know to what component this text (bunch of draws) is belonging. It makes it easier to move the text around. This is now also done manually. Just in case you wonder: yes, there will be always modifications to your design, as not all manufacturers have the same capabilities...

For a text consisting of draws (vector text) they can be blocked and flashed (see 5.6.12 of the gerber spec). The gerber output can use the attribute value '.Flashtext' to mark it. The '.C' attribute defines to which component it belongs...

@szg0000

This comment has been minimized.

szg0000 commented Jun 15, 2017

You can take a look to the fresh developed Gerber Draft Specification. As you can see in the footnotes:

Having a question or remark about the spec? Please contact us at gerberATucamco.com.
Comments on this proposal is very welcome, it is still early days.

@dbrgn

This comment has been minimized.

Contributor

dbrgn commented Jun 15, 2017

Probably sounds like a good first step. Supporting TTF/OTF eventually would be nice, but not a priority.

@k4rel

This comment has been minimized.

k4rel commented Jun 16, 2017

You can take a look to the fresh developed Gerber Draft Specification. As you can see in the footnotes:

The attributes I mentioned earlier are already part of the final spec. Still, the spec will be extended in the future containing more design related data.

btw, I see in the KiCad discussion:

KiCad currently uses a vector font called NewStroke, provided by http://vovanium.ru/sledy/newstroke/en3. Since KiCad previously used a Hershey font.....

Why would they have changed the font?

@ubruhin

This comment has been minimized.

Member

ubruhin commented Aug 5, 2017

Why would they have changed the font?

There is a document which contains information about that topic, see chapter 7.12 on page 142.

This document also mentions the CXF fonts of QCad which look very interesting as they support arcs in addition to straight lines!

See also:

@ubruhin

This comment has been minimized.

Member

ubruhin commented Sep 30, 2017

We are now developing our own stroke font (inspired by LibreCADs LFF font). As the font should be independent from LibrePCB, it has its own repository: https://github.com/fontobene/fontobene

So now at least we know which font format we will use for LibrePCB 😃

@ubruhin

This comment has been minimized.

Member

ubruhin commented Apr 3, 2018

As the FontoBene specifications are more or less complete (only a few things are still missing), I started to integrate them into LibrePCB. Here a preview:

demo brushless controller lpp - librepcb board editor_002

I will open a pull request for this improvement soon (to provide some details), but there are still some open points.

One thing is how the stroke width should be handled. Basically a stroke text consists just of a bunch of strokes which are drawn with a (user specific) width. This is very simple to implement and probably many CADs do it this way (including KiCad and LibreCAD). For example in KiCad it looks like this:

auswahl_009

  • 1st line: Text with 1% stroke width
  • 2nd line: Text with same height but 20% stroke width
  • 3rd line: Both text objects overlapped (for easier comparison)

But interestingly, EAGLE does it another way:

auswahl_008

So it seems that EAGLE automatically subtracts the stroke width from the text height, so the bounding box of the text always stays the same, even if the stroke width has changed. This may be a little bit confusing for the user (because the text looks smaller when increasing the stroke width). But the advantage is that the character spacing now can be scaled with the stroke width (thicker lines --> more character spacing) to avoid overlapped characters even with thick lines. When having thin lines, character spacing can be kept small and thus the text is more compact.

When comparing the 1% stroke width texts from KiCad and EAGLE, you can see that the text in EAGLE looks more compact (actually it's less compact, but that's because of the wider font). KiCad has larger character spacing to keep space for thicker lines.

So now the question is: What should LibrePCB do? :)

Advantages for KiCad variant:

  • Very simple to implement and understand
  • Font size does not (seem to) change when changing the stroke width

Advantages for the EAGLE variant:

  • More compact because character space is scaled with stroke width
  • Text bounding box stays the same, even when changing stroke width (is this an advantage?)

Any opinions?

@sebgonzo

This comment has been minimized.

sebgonzo commented Apr 3, 2018

I prefer KiCad option since it's simpler. Instead Eagle scaling method better provide an option to increase character and line spacing. By default spacings can be increased by stroke width, but if user wants it should have an option to override it. Also font can be more compact.
I don't see any big advantage in constant bounding box. Bounding box will change anyway when you change displayed text. I always set stroke width to 15-20% and never change it after.

@dbrgn

This comment has been minimized.

Contributor

dbrgn commented Apr 3, 2018

I agree with @sebgonzo.

@ubruhin

This comment has been minimized.

Member

ubruhin commented Apr 5, 2018

Yeah generally I also like simple solutions. But I have to admit that I also like the concept of Eagle, because IMHO it's smarter and automatically leads to more compact texts (which is a big plus on PCBs where space on silkscreen is always rare).

Here a few more illustrations:

Consider this text with a nice looking, compact character spacing:

auswahl_010

When increasing stroke width (e.g. to 30%), it's messed up:

auswahl_013

So we have to increase letter spacing heavily to allow even stroke widths up to 30%:

auswahl_015

But then the letter spacing is too high for thiner strokes:

auswahl_014

So as @sebgonzo already wrote, the user would need to adjust character spacing to correct that:

Instead Eagle scaling method better provide an option to increase character and line spacing.

We could also automatically scale the character spacing according the stroke width, but in my opinion this is pretty annoying because then the text gets longer or shorter every time the stroke width is adjusted.

Eagle solves this very elegant. The user don't need to adjust character spacing by himself, and the text still looks always nice, regardless of the chosen stroke width. So for me this sounds like a very user friendly solution ;)

Btw, another question is if stroke width should be specified by an absolute value (e.g. 0.2mm) or a ratio (e.g. 20%). KiCad uses absolute values, Eagle ratios.

Advantage of absolute values: Manufacturers specify a minimum stroke width for silkscreen (e.g. 0.15mm). When the stroke width is set to an absolute value, you can directly compare/adjust them according the manufacturers specifications. Also when making a small text even smaller, the stroke width still stays the same and thus still satisfy the manufacturers requirements.

Advantage of ratio: When increasing or decreasing text height, the look of the text does not change, it's just scaled proportional. So, Small texts automatically have thin lines, and large texts automatically have thick lines.

@sebgonzo

This comment has been minimized.

sebgonzo commented Apr 5, 2018

We could also automatically scale the character spacing according the stroke width, but in my opinion this is pretty annoying because then the text gets longer or shorter every time the stroke width is adjusted.

I don't think this is a problem, because you're not changing stroke width so often. Normally you select text size and width and use the same settings for all designators. For texts like board name you place it only once.

I think best is to provide two checkboxes so user can disable if he wants:

  • auto character spacing
  • auto character size

Still I'd like to see option to increase character/line spacing.

Btw, another question is if stroke width should be specified by an absolute value (e.g. 0.2mm) or a ratio (e.g. 20%). KiCad uses absolute values, Eagle ratios.

Absolute values because if follows strict PCB manufacturing rules.
But I'd like to see both. User can type 0.2mm for absolute and 20% for ratio.

@ubruhin

This comment has been minimized.

Member

ubruhin commented Apr 6, 2018

OK now I saw that even the Eagle method is not perfect. They subtract the stroke width from the text height to increase letter spacing without changing the bounding box. But this only works perfect if the width-to-height ratio of every glyph is 1:1, which is not true for most glyphs. It works especially bad on very thin letters, like the "i". Maybe that's the reason why "i" and "l" are the only two glyphs in the Eagle font which have serifs, while all other glyphs don't 😉

So if we want to allow arbitrary stroke fonts (including real sans-serif fonts), that's not acceptable anyway...

I don't think this is a problem, because you're not changing stroke width so often.

Yeah, true...

I think best is to provide two checkboxes so user can disable if he wants:

auto character spacing
auto character size

What do you mean with "auto character size"?

@ubruhin

This comment has been minimized.

Member

ubruhin commented Apr 12, 2018

@sebgonzo I guess it is now implemented as you suggested ;) Thanks for sharing your opinion, I think it's now a solid concept of the fonts.

For details see #246.

@sebgonzo

This comment has been minimized.

sebgonzo commented Apr 13, 2018

@ubruhin Yes, exactly like in my dreams ;) Perfect!

@ubruhin ubruhin closed this in #246 Apr 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment