Hallo zusammen,
hier mal eine Frage zu einem an verschiedenen Stellen andiskutierten
Thema:
HINTERGRUND
vor vielen Jahren waren Schaltungsdarstellungen in ASCII eine feine
Sache, da man sie mit einfachen Bordmitteln (z.B. Texteditor) erstellen
und selbst in reinen Text-Foren (ohne Binär-Upload) zur Diskussion
platzieren konnte. Heute ist das Feld geprägt von einer Reihe
ausgereifter Schaltungseditoren (Protel, EasyEDA, KiCad, ...), die
allerdings i.d.R. keine ASCII-Darstellung ausgeben, aber in der Regel
mit etwas Aufwand der Austausch von Schaltungsdarstellungen möglich
wäre.
WUNSCH
Ich würde gern ASCII-Schaltungsdarstellungen automatisch aus bestehenden
Quellen generieren können, um sie dann z.B. zur Diskussion in Foren
platzieren zu können, oder, und das wäre mir noch wichtiger, auch zur
Kommentierung von zugehörigem SourceCode direkt innerhalb der
Code-Dateien zu verwenden. So hat man auf einen Blick alle relevanten
Details versionierungsfähig zusammen. Also, ich möchte nicht
Schaltungsteile nachträglich händisch in ASCII nachbilden, sondern
direkt aus der bestehenden Quelle (und damit potenziell fehlerfrei) in
eine ASCII-Darstellung übertragen.
FRAGE
Kennt jemand ein Tool, mit dem aus einer bestehenden
Schaltungsdarstellung, vorliegend z.B. in
- einer Datei im XML-Format aus EasyEDA, KiCad, ...
- einem Grafikformat wie PNG, BMP, JPG, ...
eine ASCII-Darstellung erzeugt werden kann? Wie z.B. diese hier aus dem
Beitrag zu Schaltungseditoren
(https://www.mikrocontroller.net/articles/Schaltplaneditoren#AACircuit):
Während die Umwandlung aus einem XML-Format technisch zunächst einfacher
scheint, ist eine grafische Umwandlung aus einer Abbildung heraus
wahrscheinlich komplizierter, wenn sie so ein minimales ASCII-Abbild
(siehe oben) ergeben soll.
Kennt jemand entsprechende Tools, die eine echte Umwandlung einer
bestehenden Quelle in eine reine ASCII-Darstellung ermöglichen?
Bei Verwendung von AACircuit hat man zwar durch die Verfügbarkeit
vordefinierter und vordefinierbarer Symbol-Elemente eine gewisse
Eingabehilfe, muss die Schaltung allerdings trotzdem händisch erstellen.
>einem Grafikformat wie PNG, BMP, JPG, ...
Hä?
Du hast einen Schaltplan schön gezeichnet als Grafik vorliegen und
willst daraus eine Augenkrebs-1984-FidoNet-ASCII Grafik erzeugen, weil
man dann besser diskutieren kann?
nein, weil ich den Schaltungsteil gern in den Sourcecode einfügen
möchte.
WasSollnDet schrieb:>>einem Grafikformat wie PNG, BMP, JPG, ...>> Hä?>> Du hast einen Schaltplan schön gezeichnet als Grafik vorliegen und> willst daraus eine Augenkrebs-1984-FidoNet-ASCII Grafik erzeugen, weil> man dann besser diskutieren kann?
WasSollnDet schrieb:>>einem Grafikformat wie PNG, BMP, JPG, ...>> Hä?>> Du hast einen Schaltplan schön gezeichnet als Grafik vorliegen und> willst daraus eine Augenkrebs-1984-FidoNet-ASCII Grafik erzeugen, weil> man dann besser diskutieren kann?
Verstanden hast du nichts, oder?
Peter K. schrieb:> ...zur Kommentierung von zugehörigem SourceCode direkt innerhalb der> Code-Dateien zu verwenden. So hat man auf einen Blick alle relevanten> Details versionierungsfähig zusammen.> ...> direkt aus der bestehenden Quelle (und damit potenziell fehlerfrei)
Erstmal hat man das Problem "garkein Kommentar ist besser als ein
veralteter/falscher", wie mit jedem Kommentar. Hardware und Software
entwickeln sich doch noch unabhängiger von einander als library und
main. Und dann muss man sich sowas anhören:
WasSollnDet schrieb:> Augenkrebs-1984-FidoNet-ASCII GrafikDas wäre doch mal eine Aufgabe für eine IDE. Also den
Original-Schaltplan oder wenigstens eine Grafik davon ins Projekt
einzubinden. Vielleicht sollte es überhaupt nur ein Projekt geben und
nicht Hardware und Software getrennt?
Bauform B. schrieb:> Das wäre doch mal eine Aufgabe für eine IDE. Also den> Original-Schaltplan oder wenigstens eine Grafik davon ins Projekt> einzubinden.
Für diesen Zweck genügt auch ein URL zu der betreffenden Datei,
vorzugsweise natürlich im Versionskontroll- oder
Dokumentenmanagementsystem. Ich verwende meist UltraEdit bzw. UEStudio.
Dort werden auch in C-Quelltexten Links, die mit http: o.ä. beginnen,
als solche erkannt; durch Rechtsklick kann ich dem Link folgen.
Wenn man einem Verweis direkt ins VCS/DMS nicht folgen kann, geht es
ggf. auch noch über die entsprechende Funktionalität in einem
Ticketsytem oder Wiki. Ich setze z.B. Trac ein, welches auch den Blick
ins VCS (z.B. Subversion oder Git) ermöglicht. Dann sieht solch ein URL
wie folgt aus:
http://meintracserver/environmentname/changeset/1234/projects/pfad> Vielleicht sollte es überhaupt nur ein Projekt geben und> nicht Hardware und Software getrennt?
Die Lebenszyklen von Hardware- und Softwareprojekten sehen deutlich
unterschiedlich aus. Ich verwende zwar auch ein gemeinsames
Wurzelverzeichnis, in dem sich z.B. die Unterverzeichnisse hw, sw, fw,
fpga, doc befinden, aber Freigabestände landen ins separaten
Verzeichnisstrukturen, da ja ggf. auch noch spezifische Fertigungsdaten
hinzukommen.
Danke erstmal für eure Kommentare soweit.
Die ASCII-Abbildungen innerhalb des SourceCode aktuell zu halten, ist
kein Problem. Dazu können, wie schon angedeutet, gängige
"Präprozessoren" während des Versionierungsvorgangs oder verfügbare
CI/CD-Methoden verwendet werden. Wichtig wäre hier, dass halt ein
Konvertierungs-Tooling existiert, das eben XML lesen und in
ASCII-Diagrammform umsetzen kann. Sowas würde in den Prozessablauf
eingebunden werden können und an entsprechend verlinkter / markierter
Stelle im Code Text-Passagen ersetzen.
PS: Was ich in Mikrocontroller-Foren immer interessant finde ist, dass
Antwort-Beiträge gern das "WARUM" hinterfragen, anstelle eine Hilfe für
das "WIE" zu geben. Aber vielleicht gehört das einfach zur
Lösungsfindung dazu. Also, gern weiter so ;-) .
Peter K. schrieb:> PS: Was ich in Mikrocontroller-Foren immer interessant finde ist, dass> Antwort-Beiträge gern das "WARUM" hinterfragen, anstelle eine Hilfe für> das "WIE" zu geben. Aber vielleicht gehört das einfach zur> Lösungsfindung dazu. Also, gern weiter so ;-) .
Das "Warum?" ist meistens essentiell wichtig. Gewöhnlich schlagen hier
Leute auf, die eine vermeintliche Lösung für ein Problem haben, dabei
stecken geblieben sind und dann Fragen, wie ihre Lösung geht.
Jetzt kann aber der Lösungsansatz völlig falsch/ungeeignet sein. Dann
ist es natürlich Klug das eigentliche Problem zu schildern. Da kann man
deutlich mehr helfen.
Grüße
Peter K. schrieb:> Danke erstmal für eure Kommentare soweit.>> PS: Was ich in Mikrocontroller-Foren immer interessant finde ist, dass> Antwort-Beiträge gern das "WARUM" hinterfragen, anstelle eine Hilfe für> das "WIE" zu geben. Aber vielleicht gehört das einfach zur> Lösungsfindung dazu. Also, gern weiter so ;-) .
Ja, so ist das. Ein Ingenieur muß die Anforderungen verstehen. Dann gibt
es oft viel bessere Lösungen. Die kann man aber nur vorschlagen, wenn
man "warum" fragt...
Vor allem, wenn es nur um das WIE geht, dann kann die Antwort oft seit:
gar nicht. Weil niemand eine Lösung kennt oder hat.
Beispiel: jemand will die Quadratur des Kreises. Da weiß niemand wie das
mit Bleistift und Zirkel geht und kann es auch nicht wissen, wie
Ferdinand von Lindemann bewiesen hat. D.h. niemand wird eine Antwort
geben können.
Wenn dann jemand nach dem WARUM fragt und die Antwort ist, man will eine
Waage bauen wo links ein Quadrat und rechts ein Kreisscheibe hängt aber
sie soll ausbalanciert sein, dann gibt es Lösungen (z.B. mit einem
versteckten Gewicht austarieren)...
D.h. oft gibt es rund um die geradlinige Lösung viele besser
Lösungswege. Und die können nur genannt werden wenn das Ziel
(Anforderungen) bekannt ist. Daher ist es keine Eigenheit des Forums
dass immer gleich WARUM gefragt wird, sondern liegt daran dass man so
viel mehr Antworten geben kann.
Aber fairerweise stand die Antwort auf WARUM schon in der
Ursprungsfrage:
> um sie dann z.B. zur Diskussion in Foren platzieren zu können
Hier muß ich genau so eine "mach es doch anders"-Antwort geben: moderne
Foren können alle Bilder einbinden. E-Mails kann man mit Bild-Anhängen
versenden. Mir ist auch kein weit verbreitetes reines ASCII-Forum
bekannt das es heute noch gibt. D.h. einfach einen Screenshot von EAGLE,
KiCAD oder Gerber machen und einbinden.
Das beantwortet auch indirekt die Frage warum es wahrscheinlich kein
solches Konvertierungstool gibt und die Suche danach vertane Zeit sein
dürfte: niemand sonst vermißt diese Funktion.
Ich kenne aber auch die andere Seite. Als Fragender weiß man z.B. 10
Lösungsansätze aber der elfte wäre ideal. Nur weiß man nicht WIE man den
umsetzen soll bzw. welche Komponenten es dafür gibt. Es fehlt einem
eigentlich nur der Name einer Software, der Typ eines Bauteils.
In diesem Fall ist es ziemliche Zeitverschwendung das Forum mit dem
WARUM zu belästigen und erst mal das Für- und Wider des Problems sowie 7
der 10 schon bekannten und verworfenen Ideen diskutieren zu lassen. Denn
das kennt man selbst schon in- und auswendig und braucht es nicht
nochmal in der Öffentlichkeit ausgebreitet.
Dir ist aber schon klar, dass dieses Format (ASCII) denkbar ungeeignet
für eine Technische Zeichnung ist? Man hat das mal so verwendet, ja.
Aber nur, weils nicht anders ging. Seit Speicherplatz und vor allem
Übertragungsraten quasi keine Begrenzung mehr darstellen nimmt man dafür
Bilder. Idealerweise png oder gif. In Zeiten, als 1MB RAM schon
Königsklasse und der Zugang zum BTX mittels 14k Modem war, sah das
freilich anders aus. Da waren die 50Byte einer ASCII Grafik natürlich
deutlich besser als 250kB für ein Bild.
Das größte Problem am Ascii ist seine Lesbarkeit. Das wird auf
unterschiedlichen Systemen mit unterschiedlichen Leseprogrammen schnell
deutlich. Denn es kommt andauernd vor, dass Leerzeichen unterschiedliche
Breite haben, deshalb nimmt man ja normalerweise Tab Stops um definierte
Spaltenanfänge zu bekommen (Beispielsweise beim Code schreiben oder
schreibst du Unterfunktionen mit Leerzeichen eingerückt?). D.h. was auf
deiner Maschine heute gut aussieht kann auf einer anderen Maschine
morgen total zerlegt sein. Dann wird aus einem so möglicherweise schon
schlecht lesbaren Schaltplan ein komplett unleserliches irgendwas.
Nostalgie hat durchaus Charme, hier würde ich um Himmels Willen aber
drauf verzichten. Ja, man kann freilich auch einen als Bild
dargestellten Schaltplan so verhunzen, dass er komplett Unlesbar wird.
Das wird dann in ASCII aber nur noch schlimmer. Nochzumal man
mittlerweile Schaltungen hat, die durchaus komplexer sind und sich über
mehrere Seiten hinziehen, das macht die Sache nur noch unleserlicher.
Christian B. schrieb:> Dir ist aber schon klar, dass dieses Format (ASCII) denkbar ungeeignet> für eine Technische Zeichnung ist?
Armer Spinner. Was du nicht kennst oder magst, taugt halt nichts.
> Man hat das mal so verwendet, ja.> Aber nur, weils nicht anders ging.
'Man' verwendet das auch heute noch, vor allem wenn es sinnvoll und
praktikabel ist. ASCII kann mitten in den Text einer Textdatei wie es
eine Quelltextdatei darstellt, kann man einfach mit copy&paste kopieren
und zusammenstellen, und nicht ohne Grund sagt ein Bild oft mehr als
tausend Worte.
Ich habe in Quelltextdatein beispielsweise Schaltpläne für
Programmierschaltungen
für Verdrahtung beim Anschluss von Displays und zum Aussehen von
Datenformaten bei serieller Übertragung direkt aufgenommen.
> Das größte Problem am Ascii ist seine Lesbarkeit. Das wird auf> unterschiedlichen Systemen mit unterschiedlichen Leseprogrammen
Nun, Grundvoraussetzung für ASCII Art ist ein dicktengleicher monospaced
Font wie Courier. Wer dazu zu blöd ist, nun, den bestrafen die Hunde.
Leider ist in diesem Forum z.B. aus Dummheit der monospaced Font im
Eingabefeld nur auf PC, nicht aber auf mobilen Endgeräten genutzt.
Aber für den Wunsch des TO einen beliebigen Schaltplan aus einem
Schemazeichenprogramm in einen (kompakten) ASCII Schaltplan umzuwandeln,
habe ich auch keine Lösung. Zumal die meisten "Schaltpläne" heute ja nur
noch aus hingeklatschen Bauteilen bestehen, die Verbindungen soll man
sich als Leser schon passend denken. Mir sind schon die AACircuit
Diagramme zu gross. Ich zeichne per Hand. Dauert auch nicht länger als
einen entsprechend langen Text zu schreiben.
Peter K. schrieb:> (Protel
Lang, lang ist's her, etwa 15 Jahre.
Ich halte garnichts davon Dokumentationen so zu mischen. Verweis auf die
Schaltplanseite, fertig.
Ich mag auch keine Nurtext Doku. Zustandsdiagramme möchte ich z.B. in
gut lesbar. Nix ASCII Art.
Ich schreib in den Schaltplan auch nicht rein welcher Variablenname im
Sourcecode das Signal abbildet.
viel Erfolg
hauspapa
MaWin schrieb:> Ich habe in Quelltextdatein beispielsweise Schaltpläne für> Programmierschaltungen
So etwas als übersichtlich und gut lesbar zu bezeichnen setzt eine
Deformation des Gehirns voraus, die erst durch jahrelangen Gebrauch
entsteht.
Vielleicht könntest du uns deine Version eines Controllers im
TQFP100-Gehäuse als Demo zur Verfügung stellen? Nicht jeder arbeitet
heute nur mit Primitivstschaltungen aus ein paar Transistoren.
Georg
hauspapa schrieb:> Ich halte ...> Ich mag ... möchte ich ...> Ich schreib ...
Ja du. Der TO möchte das aber anders. Und er fragt nach Möglickeiten,
sowas zu automatisieren, und nicht nach Meinungen.
So eine Universalität wie sie sich der TE wünscht, kann doch gar nicht
sauber funktionieren?! Allein KiCAD bringt schon Zig verschiedene
Symbole für Transistoren mit. Wie soll so ein ASCII-Generator das
umsetzen, dass es am Schluss noch lesbar ist? Alle bspw.
Bipolar-NPN-Transistoren erkennen und dann auf ein hinterlegtes Symbol
umsetzen? Was ist, wenn ein Symbol falsch erkannt wird? Das benötigt
dann wieder Nacharbeit und vor allem Sorgfalt, was sich der TE bei der
automatischen Umwandlung ja gerade ersparen will.
Dazu kommt noch, in den paar Fällen, wo ein ASCII-Schaltplan überhaupt
sinnvoll sein kann, geht es nur um kleine Ausschnitte:
Prinzipschaltbilder oder Anschlussbelegungen. Dh. es ist wieder eine
Abstraktion drin, die ein Programm nicht einfach aus einem fertigen
Schaltplan entnehmen kann.
Was ich mir noch vorstellen könnte ist eine Art ASCII-Paint, wo man
Linien, ein paar Standardbauelemente und Text einfügen kann und das wird
dann asciifiziert.
Aber Bedarf hätte ich für sowas auch nicht.
Georg schrieb:> Vielleicht könntest du uns deine Version eines Controllers im> TQFP100-Gehäuse als Demo zur Verfügung stellen?
Welche geistige Beschränktheit liegt bei dir vor, dass du den Satz
MaWin schrieb:> wenn es sinnvoll und praktikabel ist
nicht verstehen konntest ?
Achso, du wolltest nur provozieren. Das ist dir nicht gelungen, du hast
nur allen gezeigt, dass dir Verstand fehlt.
Wenn die Zeilenlänge der ASCII-Darstellung egal ist:
Suche nach "ASCII Art Generator". Da gibt es auch etliche Online-Tools.
Mit diesen kannst du praktisch jedes Bild in eine ASCII-Darstellung
überführen, und wenn du dem Tool eine ausreichende Anzahl von Zeichen
pro Zeile gönnst, ist auch die Qualität in Ordnung. Solche Grafiken
können aber i.Allg. nicht zusammen mit normalem Text in einer
einheitlichen Schriftgröße dargestellt werden.
Wenn die Zeilenlänge begrenzt ist (bei der Einbindung als Kommentar in
Quellcode sollte sie nicht größer als ca. 130 sein):
Du erwartest Ergebnisse wie in deinem umd MaWins Beispiel. Diese
Beispiele haben aber nur deswegen eine akzeptable Zeilenlänge, weil die
Schaltungen sehr einfach sind und der Autor sie speziell für die
ASCII-Darstellung optimiert hat. So hat er bspw. die Bauteile sehr dicht
gepackt und teilweise statt der Symbole nur den Bauteilwert angegeben.
So sieht aber kein Originalschaltplan aus, weswegen die Konvertierung
jede Menge (vor allem natürliche) Intelligenz erfordert.
Ein generelles Problem bei der Einbindung solcher Grafiken in Quellcode
sehe ich bei der Versionsverwaltung. Ich möchte mich nicht durch die
Diffs zweier Dateiversionen wühlen, die sich nur darin unterscheiden,
dass in einem eingefügten ASCII-Schaltplan ein paar Bauteile verschoben
worden sind ;-)
Wenn du unbedingt Schaltpläne im Quellcode sehen möchtest, dann nimm
einen Editor (wie bspw. Emacs) der echte Bilder (PNG, JPEG ...) durch
die Angabe einer URL innerhalb des Texts anzeigen kann.
Hallo zusammen,
viele Dank schon einmal für die angeregte Diskussion :-)
Yalu X. schrieb:> Wenn die Zeilenlänge der ASCII-Darstellung egal> ist... "ASCII Art Generator". Da gibt es auch> etliche Online-Tools.
Schon mal dran gedacht, ja, das geht in die erwähnte Richtung
"Konversion aus Grafikdatei". Hat aber den Nachteil, dass man eben keine
"minimalen" Repräsentationen der Bauteile erhält, sondern eher mit sehr
kleiner Schriftgröße oder entfernter Ansicht arbeiten müsste. Ungeeignet
für die Abbildung im SourceCode.
Yalu X. schrieb:
> Du erwartest Ergebnisse wie in deinem umd MaWins Beispiel. Diese> Beispiele haben aber nur deswegen eine akzeptable Zeilenlänge, weil die> Schaltungen sehr einfach sind und der Autor sie speziell für die> ASCII-Darstellung optimiert hat...
Da gibt es (auch in AACircuit) gute Möglichkeiten, minimale Bibliotheken
zu verwalten. Die lokale Komplexität muss dabei eigentlich nicht so
extrem sein.
Zumal ich ja immer nur den jenigen Schaltungsteil identifizieren und im
SourceCode darstellen möchte, auf den im darunter angesiedelten
SourceCode-Block bezug genommen wird. Die Komplexität hält sich
tatsächlich in Grenzen.
Yalu X. schrieb:
> Ein generelles Problem bei der Einbindung solcher Grafiken in Quellcode> sehe ich bei der Versionsverwaltung...
Auch hier gibt es bereits sehr übersichtliche Lösungen zum Diffen.
SourceTree ist nur ein Beispiel, wenn man das Diffen nicht unbedingt
direkt über das CLI machen möchte. Bei SourceTree werden
block-orientierte Änderungen sehr übersichtlich angezeigt, so dass man
den Fokus gut auf dem eigentlichen Quellcode und seinen
zeilenorientierten Kommentaren halten kann.
Vielen Dank.
Nette Umgangstöne hier ...
Und nein, es ist keine gute Idee, Schaltpläne im Sourcecode
zu dokumentieren. Sourcecode kommt optimalerweise ohne
jeglichen Kommentar aus (weil er selbstdokumentierend ist).
merciless
Dirk K. schrieb:> Sourcecode kommt optimalerweise ohne> jeglichen Kommentar aus
Das ist wohl das uralte Programmierer-Mantra: Niemals darf jemand ausser
mir meinen Code verstehen, dann ist mein Arbeitsplatz gesichert...
Georg
Georg schrieb:> Dirk K. schrieb:>> Sourcecode kommt optimalerweise ohne>> jeglichen Kommentar aus>> Das ist wohl das uralte Programmierer-Mantra: Niemals darf jemand ausser> mir meinen Code verstehen, dann ist mein Arbeitsplatz gesichert...
Du hast den wichtigsten Teil vergessen zu zitieren:
weil er selbstdokumentierend ist
Lies dich mal in Clean Code ein.
merciless
MaWin schrieb:> 'Man' verwendet das auch heute noch, vor allem wenn es sinnvoll und> praktikabel ist.
Das ist es aber selten bis nie. Es gibt auch keine Röhrenradios mehr,
mit dem kompletten Schaltplan incl. Arbeitspunkten auf der Innenseite
der Rückwand. Oder Fernseher mit kompletten Schltplänen zu Reparatur.
Die Zeiten sind schlicht vorbei. Wir nutzen auch keinen Faustkeil mehr,
auch wenn der vor einigen 10.000 Jahren überaus fortschrittlich war!
Es gibt vernünftige, allgemein verbreitete und akzeptierte Datenformate.
U.a. PDF, im Idealfall als Vektorzeichnung. Damit kann man weltweit
Schaltpläne dokumentieren. Und dort kann und darf auch ein Softwerker
mal reinschauen! Problem gelöst!
MaWin schrieb:> 'Man' verwendet das auch heute noch, vor allem wenn es sinnvoll und> praktikabel ist. ASCII kann mitten in den Text einer Textdatei wie es> eine Quelltextdatei darstellt, kann man einfach mit copy&paste kopieren> und zusammenstellen, und nicht ohne Grund sagt ein Bild oft mehr als> tausend Worte.
Auch einen Doxygen-Kommentar kann man einfach per copy&paste kopieren.
Dafür muss man nicht auf Keilschrift zurück gehen.
Probiere mal den Kicad SVG Export, ob dich das anspricht. Falls nicht
musst du bei AACircuit bleiben, was besseres gibts da nicht. Da ist
einfach zu wenig Interesse um ein derartiges Tool zu entwickeln, selbst
fuer freie Software. Ist auch nicht gerade trivial, siehe obige
Kommentare.
https://en.wikipedia.org/wiki/File:Kicad_SVG_Output_Sample.svg
Neuere OpenSource Python Version:
https://github.com/Blokkendoos/AACircuit
Peter K. schrieb:> vor vielen Jahren waren Schaltungsdarstellungen in ASCII eine feine> Sache, da man sie mit einfachen Bordmitteln (z.B. Texteditor) erstellen> und selbst in reinen Text-Foren (ohne Binär-Upload) zur Diskussion> platzieren konnte.
Das ist 40 Jahre her und stammt aus Zeiten, als der Umfang von Uploads
in Byte gemessen wurde und per Modem mit 300, 600 oder gar 1200 Baud
übertragen werden musste.
Kann das Zeugs nicht allmählich einfach im Museum bleiben?
Inzwischen sind Fernschreiber und Zeilendrucker durch Bildschirme
ersetzt, die Graphiken direkt mit deutlich besserer Auflösung anzeigen
können.
Rainer W. schrieb:> Das ist 40 Jahre her
Warum nur bin ich überzeugt, dass deine Geburt schon mehr als 40 Jahre
ger ist und man so altes Zeug wie dich heute echt nicht mehr brauchen
kann, kannst du nicht einfach im Altersheim bleiben statt in Foren
rumzutrollen ?
Es steht dir frei, deine Beiträge mit, ja was denn, LTSpice auf
Smartphone? Eher nicht, vielleicht Freihandgekrakel auf Touchscreen?
Oder doch oldschool mit Bleistift auf Papier und dann abphotographieren?
Nee, ekelig, besser Normachriftschablobe auf Zeichenbrett mit Rotring.
Ach blöd, hat msn auch nicht dabei, wo man mit dem Smartphone gerade
ist.
Ich hätte da einen Tip: Einfach per Tastatur zeichnen, geht so schnell
wie schreiben.
Aber schreiben kannst du sicher auch nicht, die Tätigkeit wurde ja schon
weit früher als 40 Jahre erfunden und ist heute megaout.
Thread beobachten
Seitenaufteilung abschalten