Skip to content
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

UTF-8 Characters Cause Problems #16

Open
linuxcf opened this issue Aug 21, 2016 · 4 comments
Open

UTF-8 Characters Cause Problems #16

linuxcf opened this issue Aug 21, 2016 · 4 comments
Labels

Comments

@linuxcf
Copy link

linuxcf commented Aug 21, 2016

KiCAD, at least on Linux, is fully UTF-8 compliant. So, in my existing KiCAD schematics I use strings like '4.99Ω' and '0.1μF' as values. Such strings seem to create problems to 'bomsaway.py', which, although it does not crash, just ignores the selection, generating an error message in the terminal, e.g., for a value of '10kΩ' (without the quotes),

KeyError: u'10k\u03a9'
Traceback (most recent call last):
File "bomsaway.py", line 231, in on_fp_list
[x for x in sorted(set(self.type_data[self.fp_list.GetStringSelection()].keys()))])

When the script encounters UTF-8 characters in any field, an error like the above is printed and the particular component is just ignored.

@DavidMenting
Copy link

The error seems to relate to difference in encoding between the value returned from the selection box and the keys of the component list.

1µF is encoded in the internal list as '1\xc2\xb5F', whereas the wxWidgets ListBox returns a UTF-8 encoded string u'1\uxbF'

I've tried finding a solution to this for the past hour or so, but couldn't fix it. Maybe @Jeff-Ciesielski can jump in to help or give pointers.

@Gasman2014
Copy link

This affects me too. Whilst I could parse all my libraries and replace the Ω symbols with Ohm I do quite like the space saving the symbols offer. Not sure how easy a fix this is?

@Jeff-Ciesielski
Copy link
Owner

Jeff-Ciesielski commented Jul 16, 2017

A cursory glance seems to indicate that wxWidgets stores strings as UTF-32 internally. I'll see what I can do about marshaling things back and forth, but this might be fairly non-trivial considering how much strings are used.

@Gasman2014
Copy link

I agree that this seems to be somewhat problematic in Python 2.7 although possibly easier in Python 3. This article seems to sum up an approach to the issues quite well https://www.azavea.com/blog/2014/03/24/solving-unicode-problems-in-python-2-7/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants