You have anti-aliasing disabled on the left and enabled on the right That will definitely reduce the clarity of your original image. Was that a mistake?
I have no objection to the schematic font, personally. Many times, though, I have wanted to use other fonts on PCB silkscreen text.
2 Likes
@Seth_h You’re correct, my left image did not use antialiasing because the 2x supersampling in nightly will blur everything which makes things even worse for me. Note how in the middle image, the schematic lines are now 2px wide and 50% transparent, as opposed to being 1px and 100% opaque.
From left to right, the images show
- Accelerated + No Antialiasing
- Accelerated + Nightly Supersampling 2x
- Accelerated + My modified supersampling 2x
So yes, I was comparing “Stroke font with no antialiasing” against “Vector font with modified supersampling”, because I had decided that the no AA stroke font image was the most readable result.
@marekr I presume MR = GitLab Merge Request. I’ll try to setup an account and figure out how.
@DavidR The branch by @rockola that @craftyjon linked to can do that.
@paulvdh I’m tagging you here because I believe the antialiasing issue that I stumbled upon might be what you meant. In my case, the nighly 2x supersampling filter appeared to smear solid 1px lines into 2px transparent lines.
@fred4u It’s a commissioned TTF font family which I personally use for everything code, terminal, and documentation. I like it because it is very readable, yet compact. On the technical side, I used a modified version of msdf-atlasgen to convert the font into images of signed distance fields, which are then used for rendering. If I understand things correctly, the MSDF image is completely unencumbered by the font license (as would be using the font in a graphical design), so redistributing that one should be fine. Also, the people who made the font for my company said that they can acquire a “SIL Open Font License” license for it, should I need it. So the font is hardcoded for now, but using it for a release shouldn’t create any problems.
3 Likes
tl;dr Go to the kicad source repo, “Fork” it to your account. Push a branch with the patch to your repo. The web ui will then display Create Merge Request, alternatively you can go to merge requests on the kicad main repo and create a merge request which will let you select your forked repo’s branch
Thank you, I will be waiting to see this change in nightly!
I am in fact working on eeschema now as pcbnew is more or less solved. There are a number of issues that are eeschema-specific, global/hierarchical/local labels as just one example. Will update the merge request with new code once I have figured out how to solve a few issues.
3 Likes
Use File–>Plot and select pdf. It will look very nice and is searchable.
2 Likes
“a number” is somewhat of an understatement, btw.
I updated the merge request yesterday. Hoping to get it to a stage where it can be merged by the time V7 development is started.
3 Likes
In case anyone else is interested, here’s the version that I’m using now:
- It uses the AA fix that I submitted as a merge request
- I’ve added one patch to improve clarity of the OpenGL bitmap font shader
- I patched
SCH_PAINTER::strokeTextto always callm_gal->BitmapTextinstead. I am aware that that’s a very heavy-handed way of converting all text from the stroke font to a proportional font. - I’ve patched
app_settings,color_settings,common_settingsto introduce a new color scheme -
DS_DATA_MODEL::LoadDrawingSheetwill now fall back topagelayout_default.kicad_wksinstead of an internal hardcoded page layout.
One thing that I do like about Altium but which I have not been able to replicate with KiCAD yet is that in Altium, it would display all components in blue, but all GND and power connectors in red. I feel like that makes things quicker and easier to read if you can see the power nets with one glance.
Apart from that, here’s two screenshots, one from Altium and one from KiCAD.
As you can see, the importer from @pointhi is working very well for this schematic 
As for the font, I went with a fully customized TTF made in FontLab 7 in the end. The other font had issues with the dot in the 0 looking too much like an 8 and also it didn’t cooperate well with AA and/or the MSDF offset that I use for adjusting line thickness. Also, I like how this font has a hint of handwritten asymmetry in it, which in my opinion makes it easier to distinguish between a/e or c/o.
But in general, I’d say this is “good enough” so that:
- I can nicely read the text
and - I can share my screen with an Altium user and they won’t feel too confused
In case anyone less technical is interested, I have commit cd0cbda3c62ccf8ae0c00f88a30f8eda3a07015f as a Windows x64 installer made by kicad-win-builder here: kicad-r22526.cd0cbda3c6-x86_64.exe
2 Likes
Why do this instead of just making a color theme and distributing it as a json file like on https://github.com/pointhi/kicad-color-schemes ?
1 Like
BTW @mangelozzi I only noticed now that apparently the Altium to KiCAD importer is turning “Ω” into “O”, so that’s where the odd 10KO notation was coming from.
@craftyjon because I plan to also further patch the schematic rendering logic to introduce a separate color for power nets. And since my dev build has a different search path than the main installer, hardcoding things seemed like the easiest way forward. That, BTW, is also why I changed the fallback for DS_DATA_MODEL::LoadDrawingSheet .
This fork is me trying to get things ready so that I can use KiCAD productively. I’m aware that I will need to rewrite/squash commits and/or change how things work for this to be merge-able. But I thought I’ll share it anyway, if only to enable less technical KiCAD users to form an opinion on schematic presentation.
You are of course free to do whatever you’d like with your own fork. But, if you would like to work with us to get some of your changes merged into KiCad, it would be best if you could separate out the different things you are trying to do and discuss them with the team.
We already have logic for rendering certain nets or netclasses in a certain color, so I’m not sure what patching you plan to do. Either way, you do not need to create a new built-in color theme in order to accomplish that: your Altium-style theme can be created as a JSON file and then users who want to use it can do so without using your custom build. We prefer to let things like color themes be handled in a community repository such as the one started by Thomas rather than adding a lot of built-in themes based on everyone’s differing preferences.
And since my dev build has a different search path than the main installer, hardcoding things seemed like the easiest way forward
Your dev build would not have a different search path for settings (including color themes) than the official builds unless you changed that intentionally. But even if you did, I don’t see why that stops you from developing your Altium-style theme as a JSON file.
That, BTW, is also why I changed the fallback for
DS_DATA_MODEL::LoadDrawingSheet.
Please check out https://gitlab.com/kicad/code/kicad/-/issues/5868 and https://gitlab.com/kicad/code/kicad/-/issues/2376, if you are interested in helping resolve these issues related to the drawing sheets, we’d welcome the help but please coordinate on those issues and note that any solution we accept into KiCad would have to handle existing (legacy) designs properly.
5 Likes
Oh, I now realize that by “power nets” here you probably meant “power symbols” and I understand now.
What I would recommend is that you create an issue on GitLab requesting this feature (i.e. separate symbol body color for power symbols compared to regular symbols). You can mention on this issue that you plan on implementing it. The implementation will involve adding a new color setting, but I think you can do that in parallel with developing your Altium-style theme (i.e. your new theme can include the new setting, but the new setting will just be ignored by versions of KiCad that don’t have it).
@craftyjon I agree with all of your points for a regular open source contribution. But in my opinion, the correct path forward will not be my fork, but to merge @rockola 's changes which enable better font support for the core rendering and Pcbnew and he’s recently also been working on Eeschema.
My fork here has two temporary reasons for existing:
- To show non-technical people how things could look, because I need to convince others that they are willing to look at my KiCAD schematics without complaining.
- To server as a band-aid for me to get stuff done until the v6 feature freeze is over and I can download an official nightly build with rockola’s merge request 613 inside.
Accordingly, I do not expect this fork to make it into master anyway, which makes the code quality kind of moot. My hope is that this will allow me to avoid or at least delay purchasing a $10k Altium license.
As for the the power symbol colors, I agree with you and yes, I’ll try to submit a proper merge request.
2 Likes
@fxtentacle I’ll have to take a close look at your patch when I have time, right now I’m very busy doing things I get paid for. My merge request does not render anything as bitmaps but this would definitely be the way to go for on-screen display/schematic printout. What my code does is triangulate all outline font items, then render the triangles. This is the way to get outline fonts onto Gerbers (unless someone has better ideas?) which was my original goal. There are a huge number of issues (like UI) to solve that are unrelated to actual rendering, which is why I haven’t yet looked into (e.g.) how OpenGL renders fonts (since I already had the triangles).
The issues that I see with my bitmap font approach are that it requires OpenGL and that you kind of need antialiasing to make it look okay. Also, I’m seeing random 1px off rounding errors because the KiCAD value range is too large for the float precision in my GPU. Next up, caching bitmap fonts doesn’t really work well because you’ll need different parameters for the pixel shader for each size. By going with a pixel shader, it is very difficult to predict the final rendering size because the scale of MSDF offsets are more or less arbitrary. Plus you’ll get artifacts if the line width gets too thin or too wide.
And most importantly, there is no clear way towards printing bitmap fonts and/or exporting them as PDF.
The best approach in my opinion is to convert the font into polygons, because that is resolution-independent, can be fully cached, and is easy to print correctly. And I believe that’s precisely what OUTLINE_FONT::GetTextAsPolygon does 
Seeing that low-resolution bitmap glyphs do not activate and that GDI/ClearType hinting is not applied, I’m pretty sure this is also what the Altium schematic viewer does. At the very least, they appear to not render directly using the Windows APIs or through FreeType, but there seems to be some sort of shape caching in between which is not aware of the final rendering resolution. Or else, there’d be hinting, which I can’t seem to see.
Added some more patches:
- fix for UTF8 in Altium importer (will send a separate MR)
- ability to select alternative POWER or PASSIVE color sets for components by adding an optional
ki_alt_clrfield to the component (will send a separate MR) - patched Altium importer to automatically add
ki_alt_clr. I’m using the messy heuristic that components with designators starting with R, C or L will be marked as color set PASSIVE (this one I won’t send patch because it’s specific to my use case)
With that, a freshly imported Altium schematic now looks similar enough that people might confuse the two 
And most importantly, like this the KiCAD schematics are very easy to read for me They have not only a proper font, but also the color coding that I’m used to.
5 Likes