Unicode characters on Qspice Schematics

On Windows systems there is a registry entry that will enable the use of hexadecimal input for unicode characters. It allows you to hold down the Alt key, enter + and two to four hex digits. In QSPICE it works for 2 hex digits e.g.Alt+B0 for the degree symbol or Alt+A7 for the section symbol. When I try Alt+3A9 for the capital Omega (Ohms), I get the copyright symbol which is curiously enough 0xA9, so the upper byte of the unicode character got masked off. Would it be a problem to allow 16-bit characters in Qspice?

IMHO - this may not be a bug, it would just be nice to have.

In other, past, work, I used UNICODE for CAD so I could render all Asian languages, but it turned out they didn’t really care. In fact, UNICODE was generally poorly received. For example, Helmut really didn’t like it all all.

So I wanted to stick to ASCII, or at least eight bit clean ASCII. I used Windows-1252(Windows-1252 - Wikipedia) which did everything I needed:

  1. Lower case Greek Mu for micro
  2. Enough extra letters for all the foreseeable new SPICE devices I would likely write.
  3. Allowed western European languages to look normal with the extended vowels as they do expect.
  4. Simplifies writing new parsers for manipulating netlists, CAD, and waveform header files by 3rd parties.

–Mike

Mike,

That is an entirely reasonable position to take. That is why I said I was not certain it was a bug. If Alt+3A9 had come back with something besides the copyright symbol ©, then I would have been less sure. I love being on the bleeding edge, this is some candy store.

BRUCE108

It looks like only (plus the ISO-8859-1 subset of Unicode) of Windows-1252 are displayed and printed, ƒ ˆ Š Œ Ž ˜ š œ ž Ÿ are somehow missing. Any chance for support of (en dash 0x96) since it’s the same width as + (plus 0x2b) and (minus U+2212) in Tahoma and looks better than - (hyphen 0x2d) or shifted _ (underscore 0x5f) for pin labels? Maybe some would also want QSPICE™

1 Like

Many high bit set characters have special meanings and/or used in the name mangling used by the netlist compiler. I sort of like your idea of the dash. But I might want to reserve it. Honestly, for symbols, yes, in the video I used text ‘+’ and ‘-’ to indicate pins, but I would normally never do that. Rectangles scale much better.

Below I’ve show the letter that work as of now, though the superscript integers have special meaning. Guillemets, vinculum, and Pilcrow are reserved for internal use only. Eventually I should make it impossible for a user to type those in, because all they would do is make the file potentially unintelligible to QSPICE.

The circled are reserved, the red box shows legal characters to use in a string.
In a nutshell, the letters used in Western European languages are supported. In prior art, I supported every character of every language, but that was not well received(the file where no longer ASCII, but binary).

–Mike

How does the Associated Pin hack for + and used in symbol OpAmp work (and what if I also wanted some nice-looking V+ and V−)?

If you hardwire a pin to a net in the Symbol Properties pane, then the pin is not visible and neither are the graphical elements set their Associated Pin attribute set to that pin order.

Still seems to be the case with *.pfg (apparently archaic UTF-16, without BOM).

They are hidden by circles, though, while text and other objects are not:

«rect (0,10) (110,-10) 0 0 0 0x1000000 0x3ff0000 -1 0 -1»
«ellipse (-150,150) (150,-150) 0 0 0 0x1000000 0x400ffff -1 -1»
«text (-19,0) 1 11 0 0x0 -1 -1 "V"»

Solid circles are drawn after(on top of) solid rectangles because it is anticipated that solid circles will be used to draw connection dots or inverted logic bubbles, both of which are small. Changing the order isn’t supported. You’ll have to specify that the circle isn’t filled.

Too bad it cannot differentiate between background and foreground colors…

You can specify fill as foreground, background, custom, solid(default for that object type) or none. You’ll want to use none.

–Mike

I think I understand that (other apps like KiCad use a different drawing [or rather z-] order depending on whether a specified color is a background/solid-fill color or a foreground color).

QSPICE draws solid objects first, but solid rectangles before solid circles.

Right, tessellating filled rectangles could be a work-around:

1 Like