I labeled some nets with strings which include UTF-8 characters outside the established ASCII set. The UTF-8 characters showed up fine in pcb_new, but in the IPC-D-356 netlist they showed up as question marks. Isn’t KiCAD supposed to be UTF-8 compliant?
I am running KiCAD 4.0.7 on Ubuntu 16.04.3LTS.
UTF-8 is Unicode.
There have been related reports before eg https://bugs.launchpad.net/kicad/+bug/1667686
which was incomplete as the poster never came back with essential details like version and OS
Indeed, these two bugs may be related. I am not sure, though. So, I will file a new bug report and mention the potential relationship to the other bug.
EDIT: I tried to file the bug, but the bug tracker automatically refers me to a page dealing especially with Ubuntu bugs.
launchpad is originally for ubuntu software. But kicad does use it for all its operating systems.
Thank you for the clarification, Rene_Poschl. I was confused because I am running Ubuntu. Anyway, I did file the bug and also referenced the bug mentioned by davidsrsb in my description.
Does IPC-D-356 support UTF8? If it is an ASCII-only format then you really can’t expect any consistency in how the tools handle UTF8.
Is this commit connected, it looks like a filter to restrict to standard 7 bit ascii?
@davidsrsb, @cbernard: Yes, that piece of code seems to be related and actually forces any unicode charactersinto a question mark, if I understand the C++ code correctly. I am not sure, though, that unicode characters should be prohibited from the IPC-D-356 output.
For everybody monitoring this thread, I have filed a bug report and Jean-Pierre Charras, responded that this is explicitly the intended behavior. More details at the bug thread: https://bugs.launchpad.net/kicad/+bug/1755020.
For Western alphabet users, this constraint on net names is not the end of the world. I can see why you might want to use accented characters in the text boxes for peoples names etc.
More of an issue in Asia with different alphabets
This is one of those issues that make me scratch my head in puzzlement. Windows supports UTF8 fine, and has done for decades. It would be hard to find a text editor that does not support UTF8. I think that argument is bogus. I don’t know about IPC-D-356 etc, I don’t have access to the specs.
If it was my code I would let the user decide with a save option, and/or be adaptive when saving the file - if there are non-ascii characters save with UTF8 encoding, else save in 7 bit ASCII
Of course it would be bad to always save files as UTF8 and potentially screw up everyone using ancient CAM software, but always saving in UTF8 is an obviously bad implementation so I don’t why any programmer would assume that is the proposal.
Right, and to the first solution add an option for “replace with character”.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.