Schematic Text Stroke Width

When using the schematic editor I have trouble clearly seeing the text when zoomed out a little. The text is large enough to see, but the stroke width of the text is so small it fades enough to be hard to read. Of course this is more of a problem with the fainter colors than the dark net labels.

When highly zoomed in it is easy to see that the fonts are stroke fonts with a line width. That can be broadened by making the text bold, but that at least doubles the line width and seems a bit much.

I see a preference setting for a default text size. Will that apply to everything added to the schematic? Changing that setting and adding a capacitor does not change the size of the reference designator.

I found I can change the width of the wires. I believe the default is 6 mils and changing that to 8 mils helped and also makes the delineation from the component lead easier.

I’d say something about the grid dots, but one issue at a time, right?

Is there an easy way to improve the readability of the text on the schematic? I’d like to be able to increase the width of the font stoke by 25% to 50%.

Rick

Hi Rick,

for your 2 posts we need to know which KiCad version you are using and better if you also tell us the operative system.

This is under Windows 10 on a Dell Precision M6800 laptop with 32 GB of RAM. The KiCad version info is
Application: KiCad
Version: (5.1.6)-1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.71.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.66.0
Compiler: GCC 9.2.0 with C++ ABI 1013

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON

I’m a Linux user, and I agree that the texts in Eeschema can be a lot more readable then they are. Here is a screenshot of Eeschema, next to the same text typed in a text editor:
image

If I magnify the screenshot above you can clearly see that the same letter is rendered in a lot of different ways. This is not good for readability.

Then I remembered I had turned off “antialiasing”. Changing aliasing to:
Eeschema / Preferences / Preferences / Common / Graphics (Accelerated): Supersampling (4x) does seem to improve readability of small text a bit, but mostly makes it fuzzy.

If I set the anti aliasign for “Graphics (Accelerated)” to any of the 2 “subpixel antialiasing” options, then KiCad crashes. It shows the message:
image

but after that it does not respond to the “OK” button or the close button. Only way out is to force a terminate via the operating system.

Application: Eeschema
Version: 5.1.6-c6e7f7d~86~ubuntu18.04.1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 5.3.0-53-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
Boost: 1.65.1
OpenCASCADE Community Edition: 6.9.1
Curl: 7.58.0
Compiler: GCC 7.5.0 with C++ ABI 1011

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=ON
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON

Using system fonts and rendering (see https://gitlab.com/kicad/code/kicad/-/wikis/KiCad-Future-Versions-Roadmap#allow-use-of-system-fonts) would solve those problems. At the moment text is graphics, it’s not handled specially, which leads to these inconsistencies in rendering.

Here is what I see when I am zoomed out just some. It appears the strokes are being interpolated to the point of losing clarity. Notice the green wires are very clear. That’s because I bumped their size up from 6 to 8. Even a small increase in width makes a big difference in clarity.

I do notice that there seems to be one zoom level where the text is at its worst. It’s the last one before the grid changes to hiding most of the grid points and only showing the 10x points. When I zoom in one more click of the scroll wheel the text gets a bit better. It would still be more clear if the strokes were widened a little.

KiCad_Text_1

Viewing the attached image in the preview pane it looks a lot more clear than it does in the program. I guess the posting process enlarges it a bit.

Rick

I don’t get such a bad image neither zooming in nor zooming out.

Try also with preferences->display options and play a little with the grid settings: thicknes, spacing and grid colour.

The text is a bit hard to read indeed, although to me it looks like it’s not the text itself, but the grid that makes the text harder to read.

I remember fiddling a bit with the grid settings to improve the overall view. There are a number of settings you can tweak to make the grid less intruding.

  1. I see your grid dots are 4 pixels. I have set them to 1 pixel in Eeschema / Preferences / Preferences / Eeschema / Display Options / Grid Thickness 1.0px I have the minimum grid spacing set to 10px.
  2. I think I also tweaked the grid color to a lighter shade in Eeschema Preferences / Preferences / Eeschema / Colors / Miscellaneous / Grid Current color for me is 132, 132, 132.

The zoom setting with the densest grid points look like:
image

(Overlap with pedro’s post, I started typing this before Pedro submitted).

I think this might be a limitation of your graphics card - are you are using the fallback rendering - with one of the antialiasing settings? Using the ‘Accelerated’ (OpenGL) setting - even at the ‘Supersampling x2’ setting I get very smooth text at whatever zoom level.


Screen Shot 2020-06-02 at 10.21.35

Your screenshots do not look very helpful. When text is that big It’s always very readable. It is with small text that KiCad looses more resolution than it could have.
This text is unreadable:
image

Zooming in on the screenshot you see that I’m being a bit harsh on KiCad, because I give it not much pixels to work with.


Even if an issue was made out of this on Gitlab (Which I don’t recommend) I would not expect any change in KiCad V5. Eeschema is getting a big overhaul for KiCad V6. Tweaking the grid settings is about the best short term workaround. (Or buy a nice and big 4k monitor :slight_smile:

I am not sure this is a problem of text size. I kind of assume that the text for both of you will be the default 50mil size. It might really either be a difference between nightly and stable (if @John_Pateman used nightly to make the screenshot) or differences with regard to graphics settings (I don’t have access to kicad right now. I do however not remember seeing such strange rendering in version 5 even with 5mil text size that i use for the power flag)

5mil or 50mil text size does not matter.
It is just he on screen zoom level combined with mediocre rendering of the on screen pixels that makes text hard to read.
For me it’s one of the little nuisances I had gotten used to and had forgotten or accepted until Rick Gnuarm started this post.

This is on KiCad 5.1.6 on macOS. Here are a variety of screenshots of text of different sizes at different zooms. Standard 50mil grid. Sure, the 0.25mm high text is unreadable when zoomed out but its not pixelated when you zoom in.

Screen Shot 2020-06-02 at 10.58.49

Screen Shot 2020-06-02 at 10.58.58

1 Like

Just to clear (probable) misunderstandings.

The heavily pixelated screenshots I posted are NOT the way the text looks in Eeschema.
They are heavily magnified (in a drawing program) from the screenshots of the small texts.
Main intention of these is tho show that the pixels of the same letters are rendered in different ways. “real” Vector fonts also start to fail when rendered on such small resolutions, which is partially remedied by hinting.

The only real solution to have fonts in such low resolutions rendered readable is to use a bitmapped font which is a technology of yesteryear when computers had very limited RAM and CPU power and monitors had very low resolutions. Edit: Just for clarity. Agree wit eelik. this old technology came with it’s own problems and I would not think it would be very useful in KiCad.

This last screenshot is from 0.127mm text (5mil) next to the normal 1.27mm (50mil) text size of a pin number. It’s all perfectly readable when zoomed in enough, and I have no problem with it whatsoever.

(I think I ramble too much and cause more confusion then clarification here).

Bitmapped fonts are rarely used today, but font rendering is done with dedicated font rendering engines. They have, together with well designed scalable fonts, ways to render them pretty well. One can compare text in different sizes and typefaces for example in some Office. The result may not always be much better than in KiCad.

I was curious - No longer have problems on Mac/OSX.

However, when I first installed KiCad, the default Resolution was set to ‘Low’. After un-checking the Low Resolution box (in Mac’s Info panel for ‘KiCad Pro’) and setting the Aliasing as shown, All Graphics are Excellent…

1 Like

While the grid in my image seems to obfuscate the text that’s not the real issue. It does appear to be one of rendering the text. As I zoom out, the problem seems to happen at the point where instead of the stroke being two pixels wide it is one pixel wide. Or maybe it goes from one pixel to a fraction of a pixel. That’s why making the text bold makes the problem much less apparent and essentially not a problem until the text is so small it’s the copyright statement on the eye test chart.

If the stroke width could be set by the user I would play with a 25% increase or maybe a 50% increase. The bold setting seems a bit too much. Changing it on some of the text shows the @ stokes bleeding together as well as other characters loosing definition.

Once the zoom is far enough out that the characters are too small to read anyway, it’s not important. So this only needs a smallish improvement to be a practical fix.

Rick

I feel a bit responsible for de-railing this thread.

Your post #6 with the screenshot of the heavy pixels and the blue text field is reasonably readable to me. The biggest obfuscation is the heavy grid.
Could it be an issue with your monitor? such as for example Gamma correction or color calibration?
What sort of monitor do you have? Is it a cheap old TN screen, or a high quality, high resolution IPS monitor?

As you probably guessed by now, I do not know a way of changing stroke weight of text, apart from “normal” and “bold”. In your first post you already mentioned a partial workaround. The problem is less severe with dark text, so make your text darker.

Here are more images comparing combinations of zoom and grid.

Zoomed out with heavy grid, 1.6.

Here is the same zoom setting with grid set for 1.0.

Here is the zoom set one click tighter and grid set for 1.0.

It seems to me that the change of one setting on the zoom has a disproportionately large impact on the readability of the text and the grid dots less so. The contribution by the grid dots is not so bad. The trouble is that when zoomed out at all at a setting of 1.0 the grid is effectively invisible.

Monitors are digital now and a pixel is a pixel. My monitor is a 17", 1280x1080 laptop. Not really practical to try to use a 24" laptop. I only wish they made something larger than 17". I see Apple has a 16" laptop. If I could run my software on it I might give it a try, but many programs I use wont run on the Mac.

Rick

Then there is the same view as the first zoomed out image with a light grid and bold text.

Here the text is more readable, but actually a bit too bold. Something between the normal and bold would be ideal. I think the bold text strokes are twice as wide as the regular.

That’s why I mention the idea of a setting for the stroke width.

Rick