Hullo! Sorry for the issue-that-isn't-an-issue but I couldn't find a direct contact.

Thanks so much for all the work you put into this project and the format documentation. I just published altium.js, a JavaScript schdoc parser and renderer, and I couldn't have done it without your prior efforts.

As an FYI: the main Altium site now has a web-based online viewer (including schematics). If one digs far enough through the iframe & network calls you'll discover that the schematic content is converted on some backend server and then returned as SVG files.

This might be a useful source of "ground truth" for comparison purposes.

(It appears this functionality results from the Upverter acquisition.)

Feel free to close this issue after you've read it.

It would be cool if users could install this directly using pip from PyPI. I seems like the various modules could be put into a single top level package and then easily reused as a library dependency by other Python libraries/applications.

Hi folks!

First of all thanks for all efforts put into this project!

I have some schematics where accented characters were present in the texts and got some exceptions:

Traceback (most recent call last):
  File "altium.py", line 1615, in <module>
    main()
  File "altium.py", line 420, in main
    render(args.file, renderer.Renderer)
  File "altium.py", line 590, in __init__
    self.handle_children([objects])
  File "altium.py", line 627, in handle_children
    handler(self, owners, obj)
  File "altium.py", line 996, in handle_text_frame
    text=obj["TEXT"].decode("utf-8").replace("~1", "\n"),
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfc in position 5: invalid start byte

The problematic text was the following:

b'1x5 t\xfcskesor~190\xb0, 1,27mm'
Which corresponds to:

1x5 tüskesor\n90°, 1,27mm

I will do some experiments to map all the accented and special characters, but I am under an impression that Altium uses latin1 character encoding rather than plain ASCII.

TL;DR:

• Thanks for your work on python-altium.

• It seems the dependency installation situation can now be much simpler than in the past but to gain this:

  • A patch (linked below) to use olefile would need to be committed.
  • The ReadMe would need to be updated to simply instruct people to install olefile via pip.

Context

Thanks for your work on python-altium.

I encountered an issue during installation/first use that I thought I'd document here in case it was helpful for others.

Fork/version issues with OleFileIO/OleFileIO_PL package dependency

It seems that:

• "OleFileIO library. Version 2.4+ of the Pillow fork" no longer exists and Pillow now uses the upstream olefile package. (See: 1, 2, 3, 4)
• Additionally, "version 0.30 of the OleFileIO_PL fork," also no longer exists and has been renamed to be olefile.

Unfortunately the OleFileIO_PL package still seems to exist separately from olefile but presents itself as olefile when installed.

With Python3 in particular this situation seems to lead to problems when first installing olefile, uninstalling olefile and then attempting to install OleFileIO_PL (in part due to pip hiding an error.).

(Further details here: decalage2/olefile#123.)

Use of renamed olefile dependency

Additionally, python-altium doesn't work out of the box with the now "standard" olefile but from looking at the project forks I noticed @martonmiklos has made a patch for this but hasn't yet created a PR for it:

• martonmiklos@be51f32

I haven't tested the patch yet.

Solution

It seems the dependency installation situation can now be much simpler than in the past but to gain this:

• The patch (linked above) to use olefile would need to be committed.
• The ReadMe would need to be updated to simply instruct people to install olefile via pip.

Edited: Added Pillow-related links. Added link describing install issue.