I wonder if I write foo_~{smiley}_baz I will get foo_ 
_baz
1 Like
I am not sure. The last time I tried to stand on my head I sprained my neck.
Don’t ask me about the time I tried to tap dance…
Sorry, I forget tap for us is faucet for you.
And where is “us”, @retiredfeline
I often wish each member had a flag, showing the country in which they reside, beside their avatar.
Prime Marketeer and Coal Fondler Land.
Ah Haa,
Another who wears socks and uses computer programmes and drives on the other side of the road.
Hello!
Thanks for the replies. I tried, it works just fine. I also noticed that a problem I was complaining about earlier has also been solved. Now the labels keep their size even when inverted, so that I can quit using the N prefix for all these labels.
1 Like
So if water comes from a tap, does beer in a pub come from a faucet? In that case, faucet dancing sounds more appropriate. See how contrarian tangential thinking can lead us off the deep end?
I support that flag idea.
Btw, in Austria (German spoken) a faucet/tap is a “Hahn” which literally translates to “rooster”. Makes no sense, not even in German.
Hello!
Indeed, it draws a pipe. Which is a bit strange since I can also enter | directly from the keyboard, even in a label.
By the way, it works even if there is no closing bracket as long as it’s the last part of the string. I don’t know if it’s intended but just in case, I prefer adding the closing bracket.
I spoke to a dev about this and it is an intentional limitation at the moment. There is a shortlist of words that cannot be used.
A tap is also called a “cock” (as in ‘the stopcock to turn off the mains water’ ) in English - which might be the root of this. Beer comes from a different type of tap - a spigot.
Translated from Finnish https://www.sgr.fi/sust/sust259/sust259_taavitsainen.pdf : “Old-fashioned firearm hahn shape resembles a head of a rooster”. (Some faucets/taps have apprently resembled that hahn.)
(EDIT: actually, reading forward, a rooster shape was used as a decoration in barrel taps.)
Hmm, how is this related to inverted signals?
1 Like
Aha, interesting.
Hmm, how is this related to inverted signals?
Not at all, completely off-topic. There was a discussion about faucets/taps and user nationality flags some 20 hrs ago which I read this morning and I decided to throw my 2 cents in as well…
Mantra: he who is dead earnest is dead already 
Hi,
quoted from the bug report :
The list of strings impacted includes dblquote, quote, lt, gt, backslash, slash, bar, colon, space, dollar, tab, return, brace
It may be better to prefix these special names with a special character, (for example, a character normally not allowed in a signal name).
In the C language style, we could use a leading ‘\’ , a literal ‘\’ being written as ‘\\’:
{dblquote] becomes {\dblquote}.
which would produce, respectively :
dblquote and "
Reminds me of LaTex syntax…
Now, all these “special” characters (backslash, dblquote, etc…) being pure ASCII, I can’t see the necessity for this special “{xyz}” syntax.
One exception (IMHO) is the badly named “return”; which probably means “new line”.
Correct me if I’m wrong, but I expect all national language keyboards / OS combination, compatible with some form of Unicode, will provide these characters.
It’s a pity yet another set of special names was defined for this. The XML character entitiy syntax could have been adopted and that would cover the entire Unicode set. Named entities like © = © and Ω = Ω could be used.
Yes, XML / HTML coding looks to me as a good idea.
Except that (if I’m right…), names in Kicad are supposed to be ASCII only, for portability. But maybe it’s only in the libraries ?..
Using the XML encoding would probably requires rewriting the parser code.
(But, AFAIK, there is already an XML oriented lib included in Kicad).
NOTE : Using a C style notation for the “really” special characters as \n, \t, and keeping the printable characters, like ‘|’ or ‘:’ as-is may be simpler, both for the developers and the end user.
Also, drawing the Unicode characters onscreen, or plotting, may not be currently supported, as I believe it uses a graphics line oriented character drawing routine and a custom font.
Lack of fonts is a display issue. You want the input representation to be future-proof. If a character can’t be displayed, then display something like a block there and you’ve lost nothing anyway. For parsing all you have to do is pass the string to an XML entity decoder and you get back the Unicode string.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.