What I meant was, have you tried opening my file on the Mac and copying the data labels to other schematics?
Please post an LTSpice file you created using the Mac version, no formatted data labels or anything, so others can test it using the Windows version.
Have you tried running the Windows LTSpice under WINE?
Yes - I did open your file. It renders a proper schematic, and runs perfectly in
LTspice-Mac. Then I copied the data label formatting spec ("round...") from your file, and pasted it into an .asc file
created by
LTspice-Mac. I used (initially) Mac's built-in text editor (
TextEdit) to make these changes. Once the edits were made, I re-opened the .asc file in
LTspice-Mac to check the result. The result was chaos. By that I mean
LTspice-Mac did not render the schematic correctly, and the simulation failed.
I sat back, and wondered... WTF??
Since then I've learned a couple of things. I hope to post a more thorough analysis once I've got it all sorted, but here's what I have now:
1. LTspice-Windows generates .asc files using
charset=us-ascii encoding; this, according to running the Mac's CLI `
file -I` command on your .asc file
2. LTspice-Mac generates .asc files using
UTF-16 Little-Endian encoding; this according to a trial-and-error process with different formats in the
BBedit app on MacOS. In a fine example of Apple's attention to detail, the `
file -I` command for an .asc file generated by
LTspice-Mac reports its file encoding as
charset=binary.
3. Apple's built-in text editor (
TextEdit), renders
UTF-16 LE in the same way it renders
us-ascii ; there seems to be no way to tell the difference in this app. In other words, .asc files imported from Windows (like yours) look identical to
LTspice-Mac generated .asc files when viewed in
TextEdit. Only when I viewed these files in a competent text editor (
BBedit) did I see the difference: the NUL character is inserted after each ASCII character. Perhaps the LTspice-Mac maintainer(s) are not even aware of this?
4. It seems that what caused the issue is that the text I copied from your
us-ascii .asc file, and then pasted into my
UTF-16 LE .asc file is pasted
literally - a bit like "mixing apples and oranges" I suppose. I wind up with a hybrid file containing both
UTF-16 LE and
us-ascii characters in the same file.
For now, my only solution is
manual intervention using
BBedit to convert
UTF-16 LE .asc files generated by LTspice-Mac to
us-ascii. This isn't ideal of course as it will be tedious & error-prone. Open to any suggestions!
Wrt Mac-Windows compatibility in LTspice, this is how it looks to me at present:
1.
LTspice-Mac will happily process and run .asc files with
us-ascii encoding generated by LTspice-Windows.
2. If any changes are made to a
us-ascii .asc file using the
LTspice-Mac GUI, the
us-ascii .asc file is changed to
UTF-16 LE2. I've attached an .asc file generated by my LTspice-Mac for anyone who cares to test it. I don't know if the transport & storage of the file will change it, so I've also attached a compressed version.
Finally I've submitted a "report" to AD via their tech support form-mail, but I'll guess this will be lost in their bureaucratic maze. I have noticed that the Windows version of LTspice has an option under the
Help, About menu to email a bug report. Unfortunately, that option is not available in
LTspice-Mac.
Maybe one of you Windows users could forward this as a bug report??I'm surprised the maintainers have not discovered this. LTspice is not open-sourced, so there's not much to be done on our side except to wait for the maintainers to discover the issue & repair it. Or, perhaps they are aware of it, and consider it a feature instead of a bug? Any other suggestions??