Actually, to keep it from looking like gibberish on somebody else's computer, they either need to have the Propeller font installed or have the Propeller font embedded in the file...
Actually, to keep it from looking like gibberish on somebody else's computer, they either need to have the Propeller font installed or have the Propeller font embedded in the file...
True. Not all fonts support all Unicode characters: that would be a burdensome requirement. Unless I speak Korean, for example, I don't expect the fonts I have installed to support it. But any Spin user should have the Parallax font installed, as a matter of course.
That's odd. The code in the code box of the opening post is gibberish for me in FireFox or Chrome on Debian. In Chrome it's almost nice except there is space between each line that breaks up the vertical lines into dashed lines.
I'm not sure how special the chars may be but certainly you need the right font to make it work.
I love my UTF8 source code, it means I can use π, τ, ψ, θ and the rest in variable and function names.
"Unicode Art" is no better than the "ASCII Art" before it or perhaps even worse as we can't presume mono-spaced fonts any more. Problem is this internationalization stuff does not work everywhere and when it does work the wrong font will still mess things up.
Looks good. We just can't assume that font is available everywhere. Paste it into a document and we can't assume it does not get messed up by word wrapping, inter-line spacing or whatever formatting.
My only real objection to only putting the schematic as part of the Spin file is that it doesn't engender adoption of the Propeller by first-timers. They may be curious and download the source files, but be turned away because in order to make sense of it they need to also get a special editor, or at least a font.
Those already using a Propeller are well served by the integrated drawings, but there's a world of people out there who have never experienced it.
I'd humbly suggest that if you're going to post code with a schematic that there's also a PNG or JPG image of the schematic included in the source package. And then at the top of the source, before the pictogram, simply indicate that "In order to see this schematic diagram you need ..." etc.
If we wish to see the Propeller (and PropII) in use with more users let's look to ways to reduce the barrier to entry. Merely as a point of reference, all Arduino source files can be opened with WordPad (Notepad in some instances), and whenever they need to include a schematic diagram they do so with a standard graphics file image.
That's odd. The code in the code box of the opening post is gibberish for me in FireFox or Chrome on Debian. In Chrome it's almost nice except there is space between each line that breaks up the vertical lines into dashed lines.
and here, it varies again... it 'sort of renders ok', but when I look closely, I see the Pin large C's ( , have failed, as have the resistors, vertical Caps and GND symbols.
- with more subtle fallouts like this, novice users might think that is as good as it gets ....
Here, I'll stick with a simple combination of AACircuit (link above) and PNGs : - that gives a 100% readable sketch when needed in source code, and if it gets more complex, or I have run Spice on it, then I can add a PNG image file.
"Sort of renders ok" is what happens when the Parallax.ttf font has not been installed on the user's system. The browser then reverts to a default monospaced font that includes the box- and line-drawing glyphs, but not the circuit symbols.
Exactly. So what we have is a non-portable document in the Spin source code. A kind of anti-PDF.
I think that is a good point about newcommers to the Prop and Spin. Perhaps out of curiostity they fetch down an object from OBEX. When they open it up they see a pile of gibberish and immediately move on.
It's no more non-portable than a document written in Greek or Russian would be on a system that didn't have Cyrillic fonts installed. Including (or providing access to) the Parallax font is what makes it portable. Frankly, I just don't see the problem.
The problem is it does not work in many places without extra effort on the part of whoever want's to view it.
The problem is it may not allways be possible for the user to fix the problem, like on on my phone or tab.
The problem is it is totally non-standard, do correct me if I am wrong but what are the unicode code points for resistors and capacitors and transistors and diodes etc. This is not at all like Greek or Russian where their characters are well defined.
The problem is that even with the correct font there is no certainty that formatting or line spacing won't mess it up.
The problem is that a PNG or SVG or many other formats would be much better and portable.
The problem is...
...hey, perhaps we are done with this little topic.
Do continue to do this if you like. If the pros out way the cons for you that's all good.
The Propeller Tool + Parallax font is good at what it does: namely it provides a simple way to embed schematic graphics within a user's source code for documentation purposes. If a PNG, GIF, or SVG file could be embedded instead, that might be even better. But then, Parallax would have to provide the means for composing such an image, since most folks don't have a schematic CAD program. Moreover, program files would have to be written in HTML or some other markup language that supports embedded graphics. In any event, there will always be compromise. The one Parallax chose is light-weight and really not half-bad.
.... since most folks don't have a schematic CAD program.
LTSpice is free, and not that large, so there is no reason not to have a Schematic Entry pgm - at least not on windows, which is what most new users will have .... (& I'm sure Linux has something half usable too.)
I can't disagree that people need to make an effort to avail themselves of the no-cost resources available. However, the schematics produced by LTSpice (and Eagle) are atrocious. There are better free programs out there and plenty of threads in the Parallax forum that link to them.
For HTML based (let's say an online repo browser) you can use either PFR dynamic fonts, or CSS tags to specify TTF dynamic fonts. With dynamic fonts you don't rely on the client computer to have your font installed. By removing the font requirement and using dynamic fonts, you greatly lower the bar for deploying content so it looks how you want it to.
For encapsulation of such files, PDF works well, just open the SPIN file in OpenOffice/LibreOffice, tell it that it's Unicode, then save as PDF and you have a portable document.
Don't get me wrong, I even quite like having little circuits in the source, when it works. I'm just pointing out the issues and why in general it does not work.
The Prop Tool + Parallax font is great. Except I can't use it on my platforms of choice. When I'm not developing, perhaps just looking over some code it's
annoying to have all that broken stuff in the source when using my editor of choice or even just a web page. As such it does not work for providing documentation.
As part of the source it trips up things like git and diff so it does not help with the software engineering process.
I don't think embedding PNG, or SVG or any other format in the source is a good idea either. Embed the documentation and diagrams etc in the project not
the source files. Parallax need not produce yet another CAD program to do this there are many free and open source options.
@jmg,
I love LTSpice, it is one of my all time favorite programs, simple to use and works very well. Especially nice is that it works perfectly under Wine on
Linux. However it is not the answer here what with being closed source and non-standard. Phil is right, LT Spice schematics are not so good anyway.
@pedward,
I'm sure there are methods of getting the font to work in browsers and PDFs etc however that does not fix the general problem of not working in my editor of
choice on my platform of choice etc etc.
I guess after all that the onus is on me to suggest something better than "unicode art" in source files. Err..well..I'm still looking...
Meanwhile I discovered I was wrong ASCII art is alive and well in Unicode as standardized symbols. http://en.wikipedia.org/wiki/Box-drawing_character
Note: That page warns that render due to using "special characters".
The problem I have with some Spin code is when it's in UTF-16. That means forget about keeping it under a decent source version control system, generating diffs/patches etc. UTF-8 is fine with VC these days, but the first thing I have to do with files in UTF-16 is to convert them. Losing diagrams is a small price to pay if the alternative is to give up version control and the standard software development methods I use everywhere else. Anyway most of those UTF-16 characters are just used for creating lines surrounding comments, so they are wasted anyway.
UTF-8, UTF-16, UTF-32 are all encodings of Unicode. Any of then can be converted to any other without loss. Those diagrams should still work when converted to UTF-8.
It would be very helpful if the Prop tool worked in UTF-8 as that is the standard for the web and Linix/Uinx etc (probably Mac). UTF-16 is only used by Windows and Java.
Version control, diff and patch etc are pretty much alien concepts in the Spin world so no one has given a thought to how inconvenient Spin files are to work with yet.
UTF-8, UTF-16, UTF-32 are all encodings of Unicode. Any of then can be converted to any other without loss. Those diagrams should still work when converted to UTF-8. ....
Yes, they work fine converted from UTF-16 to UTF-8. UTF-16 is not easily cross-platform compatible.
Comments
True. Not all fonts support all Unicode characters: that would be a burdensome requirement. Unless I speak Korean, for example, I don't expect the fonts I have installed to support it. But any Spin user should have the Parallax font installed, as a matter of course.
-Phil
That's odd. The code in the code box of the opening post is gibberish for me in FireFox or Chrome on Debian. In Chrome it's almost nice except there is space between each line that breaks up the vertical lines into dashed lines.
I'm not sure how special the chars may be but certainly you need the right font to make it work.
I love my UTF8 source code, it means I can use π, τ, ψ, θ and the rest in variable and function names.
"Unicode Art" is no better than the "ASCII Art" before it or perhaps even worse as we can't presume mono-spaced fonts any more. Problem is this internationalization stuff does not work everywhere and when it does work the wrong font will still mess things up.
-Phil
Well, anyway, it's there for those who want it.
Those already using a Propeller are well served by the integrated drawings, but there's a world of people out there who have never experienced it.
I'd humbly suggest that if you're going to post code with a schematic that there's also a PNG or JPG image of the schematic included in the source package. And then at the top of the source, before the pictogram, simply indicate that "In order to see this schematic diagram you need ..." etc.
If we wish to see the Propeller (and PropII) in use with more users let's look to ways to reduce the barrier to entry. Merely as a point of reference, all Arduino source files can be opened with WordPad (Notepad in some instances), and whenever they need to include a schematic diagram they do so with a standard graphics file image.
and here, it varies again... it 'sort of renders ok', but when I look closely, I see the Pin large C's ( , have failed, as have the resistors, vertical Caps and GND symbols.
- with more subtle fallouts like this, novice users might think that is as good as it gets ....
Here, I'll stick with a simple combination of AACircuit (link above) and PNGs : - that gives a 100% readable sketch when needed in source code, and if it gets more complex, or I have run Spice on it, then I can add a PNG image file.
-Phil
I think that is a good point about newcommers to the Prop and Spin. Perhaps out of curiostity they fetch down an object from OBEX. When they open it up they see a pile of gibberish and immediately move on.
-Phil
The problem is it may not allways be possible for the user to fix the problem, like on on my phone or tab.
The problem is it is totally non-standard, do correct me if I am wrong but what are the unicode code points for resistors and capacitors and transistors and diodes etc. This is not at all like Greek or Russian where their characters are well defined.
The problem is that even with the correct font there is no certainty that formatting or line spacing won't mess it up.
The problem is that a PNG or SVG or many other formats would be much better and portable.
The problem is...
...hey, perhaps we are done with this little topic.
Do continue to do this if you like. If the pros out way the cons for you that's all good.
-Phil
LTSpice is free, and not that large, so there is no reason not to have a Schematic Entry pgm - at least not on windows, which is what most new users will have .... (& I'm sure Linux has something half usable too.)
-Phil
For HTML based (let's say an online repo browser) you can use either PFR dynamic fonts, or CSS tags to specify TTF dynamic fonts. With dynamic fonts you don't rely on the client computer to have your font installed. By removing the font requirement and using dynamic fonts, you greatly lower the bar for deploying content so it looks how you want it to.
For encapsulation of such files, PDF works well, just open the SPIN file in OpenOffice/LibreOffice, tell it that it's Unicode, then save as PDF and you have a portable document.
I think for pdf, you'd also have to specifically tell it to embed all fonts to avoid problems...
The Prop Tool + Parallax font is great. Except I can't use it on my platforms of choice. When I'm not developing, perhaps just looking over some code it's
annoying to have all that broken stuff in the source when using my editor of choice or even just a web page. As such it does not work for providing documentation.
As part of the source it trips up things like git and diff so it does not help with the software engineering process.
I don't think embedding PNG, or SVG or any other format in the source is a good idea either. Embed the documentation and diagrams etc in the project not
the source files. Parallax need not produce yet another CAD program to do this there are many free and open source options.
@jmg,
I love LTSpice, it is one of my all time favorite programs, simple to use and works very well. Especially nice is that it works perfectly under Wine on
Linux. However it is not the answer here what with being closed source and non-standard. Phil is right, LT Spice schematics are not so good anyway.
@pedward,
I'm sure there are methods of getting the font to work in browsers and PDFs etc however that does not fix the general problem of not working in my editor of
choice on my platform of choice etc etc.
I guess after all that the onus is on me to suggest something better than "unicode art" in source files. Err..well..I'm still looking...
Meanwhile I discovered I was wrong ASCII art is alive and well in Unicode as standardized symbols. http://en.wikipedia.org/wiki/Box-drawing_character
Note: That page warns that render due to using "special characters".
Standard Unicode schematic follows:
0────────┬───────────
VCC │
R1 1K
│
├───────0 OUT
│
C1 0.1uF
GND │
0────────┴───────────
0────────┬─────────── VCC │ R1 1K │ ├───────0 OUT │ C1 0.1uF GND │ 0────────┴───────────-Tor
UTF-8, UTF-16, UTF-32 are all encodings of Unicode. Any of then can be converted to any other without loss. Those diagrams should still work when converted to UTF-8.
It would be very helpful if the Prop tool worked in UTF-8 as that is the standard for the web and Linix/Uinx etc (probably Mac). UTF-16 is only used by Windows and Java.
Version control, diff and patch etc are pretty much alien concepts in the Spin world so no one has given a thought to how inconvenient Spin files are to work with yet.
Yes, they work fine converted from UTF-16 to UTF-8. UTF-16 is not easily cross-platform compatible.