Hallo Besucher, der Thread wurde 106k mal aufgerufen und enthält 727 Antworten

letzter Beitrag von emulaThor am

Webbrowser für 8-Bit-Rechner

    Ich finde, hier geht man mit der richtigen Einstellung ran. Wenn man über etwas gar nicht erst spricht, keine Visionen hat und keine "Wolkenkuckucksheime" baut, wird es auch niemals möglich.


    Wenn die Webseite grösser als der Speicher des Rechners ist, wird man sie ja aufteilen. Dann wäre aber doch sogar die Darstellung der eingebetteten Grafik möglich? Im Text erscheint nur ein Symbol, das da eine Grafik vorhanden ist oder eine sehr grob aufgelöste (Zeichensatz?) und beim anklicken wird dann das auf das System optimierte Bild angezeigt.

    Passt irgendwie ganz gut zu meinem Hires-/Proportional-/WIP-Dingens:



    Kein Mock-Up. Quasi echt. Das erwähnte Menü könnte vielleicht (besser) mittels Sprites generiert (eingeblendet) werden (nur so ein Gedanke).

    Zitat von Hexworx

    Kein Mock-Up. Quasi echt.

    Toll. Was kann das Programm denn? Ein Browser wird es ja (noch) nicht sein. Lädt es einen Text und stellt ihn mit der eingebauten Proportionalschrift dar? Und scrollt womöglich? Das wäre ja schon eine schöne Basis. Wir könnten ja zusammen am SMPL-Browser (steht für Simpel) ;) arbeiten, wenn du nichts dagegen hast – fehlt halt noch das Wichtigste: Der Proxy. :(


    Ich frage mich, wem man die Proxy-Idee mal vorlegen müsste, damit sich jemand findet, der in der Lage und willens ist, sowas zu programmieren.


    Zitat von Rapid Eraser

    Eine recht simple Möglichkeit dazu wäre es das man sich (oder jemand anderen...) mal hinsetzt und versucht die generierten Webseiten gängiger CMS mittels XSLT o.ä. in ein Homecomputer-freundliches HTML-Derivat zu verwandeln. Falls das tatsächlich gelingt wäre der Aufwand dafür überschaubar, und fertige Proxies die damit umgehen können gibt es sicherlich auch schon.

    Ja, XSLT scheint mir ein probates Werkzeug zu sein, HTML (auf weniger HTML oder was anderes) "runterzukürzen". Dieses Wenn-Dann-Ersetzen könnte sogar richtig Spaß machen. Wenn sich da jemand ersthaft dransetzen will, würde ich gerne über die Schulter gucken (und notfalls helfen, wo ich kann).


    Zitat von tilobyte

    Im Text erscheint nur ein Symbol, das da eine Grafik vorhanden ist oder eine sehr grob aufgelöste (Zeichensatz?) und beim anklicken wird dann das auf das System optimierte Bild angezeigt.

    Das wäre nicht komplett unmöglich. Ein anklickbarer [Bild]-Link, der dann (beim C64) ausschließlich das Bild anzeigt. Koala (MC-Bitmap) für JPGs, Hi-Eddi+ (Hires-Bitmap) für GIF und PNG. Bildkonverter gibt es als fertige Bibliotheken für gängige Server – C64-Formate (und die anderer Retro-Systeme) müsste man dort aber wohl noch ergänzen.

    Ich habe mir Markdown nochmal angesehen und finde weiterhin, dass das ein gutes (und vor allem auch etabliertes) System für die Textformatierung darstellt. Auch Links und Bildeinbettungen sind damit möglich. Es gibt auch Erweiterungen, die uns aber bei den für uns fehlenden Elementen nicht weiterführen. Aber es spricht nichts dagegen, selbst Erweiterungen zu integrieren. Das Wichtigste wären natürlich Formulare, damit eine Interaktionsmöglichkeit gegeben ist.


    Ein HTML-Formular in der Art wie


    Code
    1. <form>
    2. Vorname:<br />
    3. <input type="text" name="firstname"><br />
    4. Nachname:<br />
    5. <input type="text" name="lastname"><br />
    6. <input type="radio" name="gender" value="male" checked> männlich<br />
    7. <input type="radio" name="gender" value="female"> weiblich<br />
    8. <input type="submit" value="Anmelden">
    9. </form>

    könnte in etwa folgendermaßen aussehen: (Ich weiß nicht, ob ich MD schon wirklich verinnerlicht habe – ich vermisse schmerzlich die End-Tags)


    Code
    1. []
    2. Vorname:
    3. [[firstname]]
    4. Nachname:
    5. [[lastname]]
    6. (x) männlich (gender:male)
    7. () weiblich (gender:female)
    8. ///Anmelden

    Das wäre für den C64 schonmal deutlich kürzer (und sogar besser lesbar, wenn es nicht formatiert wird).


    Und wie das ganze dann formatiert wird, darum kümmert sich (wie bei HTML) der Browser. Wer möchte, kann sich das dann auch gerne (mit einem entsprechenden "Browser") im BTX-Style angucken.


    Jaja, ich weiß, ich sagte vorher, dass es nicht an der Zeit ist, über die Standards für die Übertragung zum Browser nachzudenken – aber nachdem andere Möglichkeiten präsentiert wurden, wollte ich auch Markdown eine Chance geben, sich vorzustellen. Außerdem macht es doch auch Spaß, die Möglichkeiten auszuloten. Konverter-Scripte von HTML zu MD gibt es übrigens schon fix und fertig: Link

    Und auch zum Thema Umlaute (in Kontiki ja eines der Probleme) gibt es natürlich eine sehr einfache Lösung: UTF-8. Das wird ohnehin bei 90% aller Webseiten verwendet und wenn man sich auf die ersten 256 Zeichen beschränkt, hätte man quasi alles drin, was einen Westeuropäer (und Ami, Kanadier und Australier ...) interessiert (asiatische Sprachen muss man halt auf C64 und Co. abhaken). Die ersten 128 Zeichen sind eh mit ASCII identisch und die deutschen Umlaute sowie z.B. die typisch französischen Accent-Buchstaben folgen in der Zeichentabelle recht schnell.


    Allerdings würde sich dann der Bitmap-Mode bei der Darstellung anbieten (auch für 40-Zeichen pro Zeile), weil man bei diesem nicht auf invertierte Chars (bei Kontiki für Links verwendet) angewiesen wäre und daher nicht die Hälfte eines 8-Bit-Zeichensatzes verschwenden müsste. Man wäre bei Bitmap noch nicht einmal auf einen Zeichensatz beschränkt, falls es mit 256 Zeichen eng werden sollte (was ich nicht befürchte).

    Zitat von Retrofan

    Ja, XSLT scheint mir ein probates Werkzeug zu sein, HTML "runterzukürzen". Dieses Wenn-Dann-Ersetzen könnte sogar Spaß machen. Wenn sich da jemand ersthaft dransetzen will, würde ich da gerne über die Schulter gucken (und notfalls helfen, wo ich kann).

    Hmmmnaja, prinzipiell zumindest. Wenn man mit bestehenden Standards konform gehen will. Aus eigenen Erfahrungen (die allerdings schon > 10 Jahre zurückliegen) möchte ich ich dazu jedoch noch zwei Punkte anmerken:
    1) die usability von XSLT ist mit der von vi vergleichbar
    2) Transformations-sheets für anderer Leute Webseiten zu schreiben ist eine Sisyphusarbeit. Selbst wenn sich auf einer einzelnen Seite nur alle halbe Jahre mal etwas verändert - wenn man sheets für ein Dutzend Seiten hat bedeutet daß das im Schnitt alle zwei Wochen irgendein sheet veraltet ist und nachgebessert werden muss.
    Als allgemeine Lösung taugt dieser Ansatz, so schön er auch ersteinmal klingt, glaube ich nicht wirklich.


    Interessehalber habe ich gestern mal in bestehende, möglicherweise nutzbare, Programme hineingeschaut (als Testpage diente immer http://www.forum64.de):

    • html2wml + wapua-browser
      Hat mich überhaupt nicht überzeugt. Die Unterteilung der Seite in Cards schien willkürlich zu erfolgen, Orientierungshilfen gab es so ziemlich gar keine. Unbrauchbar.
    • lynx/links/w3m in einem Terminal von 40x25 Zeichen Größe
      Naja. Ist halt nur text, aber durch die Farben immerhin benutzbar. Zumindest wenn man die Webseite schon kennt und weiss wie sie aufgebaut ist. Wenn ich dann allerdings die Anzeige "displaying screen 1 of 63" sehe - dann vergeht mir schon wieder die Lust diese 63 Seiten nach dem eigentlichen, interessanten Content der Page abzusuchen.
    • webkit
      Hier habe ich mir mal den Rendering-Tree angesehen. Ziemlich umfangreich, aber prinzipiell ließe er sich vereinfachen. In Webkit herumzuhacken um die internen Datenstrukturen abgreifen zu können wäre denkbar aber aufwendig.
    • links im graphischen Modus
      Links bietet neben dem Textmodus auch eine simple graphische Oberfläche an. Spaßeshalber habe ich gestern mal California 9 Punkt (von Geos) als Standardfont reingefrickelt, und damit sah das Ergebnis schon recht interessant aus. Das Browserfenster hatte ich auf 320 Pixel Breite gestellt, jeweils einen Screenshot gemacht, und diesen dann auf die 16 Farben des C64 reduziert. Ergebnis siehe Anhang. Sich in Links einzuhacken wäre durchaus eine Alternative zu Webkit (auch wenn die Hälfte der von mir getesteten Webseiten in Links immer noch furchtbar aussahen...).
    • zwei verschiedene html2markdown tools
      Deren Ergebnisse waren auch nicht besser als Lynx.


    Quintessenz: Ehrlich gesagt finde ich den weiter oben schon von jemandem geäußerten Gedanken fertig gerenderte Webseiten als Bitmap an den C64 zu schicken noch am erfolgversprechendsten. Dazu Metainformationen bezüglich Links, Formularen usw., dann könnte man vielleicht auch mit einem C64 einigermaßen spaßig im Web surfen.

    Erstmal Danke für deine Mühe.

    Zitat von Rapid Eraser

    lynx/links/w3m in einem Terminal von 40x25 Zeichen Größe
    Naja. Ist halt nur text, aber durch die Farben immerhin benutzbar. Zumindest wenn man die Webseite schon kennt und weiss wie sie aufgebaut ist. Wenn ich dann allerdings die Anzeige "displaying screen 1 of 63" sehe - dann vergeht mir schon wieder die Lust diese 63 Seiten nach dem eigentlichen, interessanten Content der Page abzusuchen.

    Mir ist natürlich auch aufgefallen, dass Lynx nicht gerade optimal mit Platz umgeht und halt massenhaft Leerzeilen und Zeilen mit nur einem Wort etc. produziert. Nur ist Lynx ja auch nicht darauf hin optimiert worden, irgend etwas hübsch zu positionieren, sondern einfach eine Website, wie sie ist, ausschließlich mit Text darzustellen. Aus meiner Ansicht sollte man das nur als Basis ansehen und dann halt gucken, was man da noch weiter filtern kann. Und das natürlich auch besser auf dem Proxy als auf dem Zielgerät.


    Wenn man auf 80 Zeichen pro Zeile geht, halbiert sich ja schon die Seitenzahl und wenn man die ganzen Lücken rauswirft, dann schrumpft der Inhalt wahrscheinlich nochmal auf 50% zusammen. Dann wäre das Forum nur noch 15 Screens lang (und die F64-Startseite ist nun mal sehr lang). Ob man seitenweise umschalten muss, ist ja auch noch nicht gesagt. Scrollend erträgt man solche Textwüsten ja meistens besser. Da muss man natürlich gucken, wie viel von einer Seite in den knappen C64-Speicher in einem Stück hineingeladen werden kann.


    Man sollte auch bedenken, dass es Webseiten/Foren gibt, die deutlich bessere Mobile-Ansichten produzieren. Die Forums-Sodtware, auf der das F64 läuft, ist zwar in den letzten Jahren dahingehend besser geworden (weswegen man ja auch auf eine weitere Tapatalk-Unterstützung verzichtet) aber im Grunde unterscheidet sich die Mobile Ansicht nicht sehr von der klassischen. Auf vielen anderen Seiten bekommt man deutlich besseren Basiscode geliefert, wenn man statt der PC-Ansicht die Mobile-Ansicht aufruft.

    Zitat von Rapid Eraser

    zwei verschiedene html2markdown tools
    Deren Ergebnisse waren auch nicht besser als Lynx.

    Bei einer Umwandlung zu Markdown geht es ja auch nicht darum, die Seiten hübscher werden zu lassen, sondern im Code kompakter. Und ich nehme an, dass das bestimmt gelungen ist.

    Zitat von Rapid Eraser

    Ergebnis siehe Anhang

    Es ist erahnbar aber leider komprimiert das Forum große Grafiken zu sehr. Vielleicht mal extern ablegen oder als ZIP-Archiv?

    Aber mehr als ein 40-75 Zeichen Anzeiger und Bediener auf Textbasis wird ein C64 dann nicht sein. Sobald das Ding ein bischen mehr Eigenintelligenz haben will haben wir schon keinen Speicher mehr.
    Das ist zwar alles nett als "proof of concept aber das "warum?" (weils irgenwie geht) ist immer noch da.
    Benutzen werden das effektiv 5 Leute von denen 3 immer Fragen haben.
    Auf Dauer wird das auch maximal unhandlich sein.


    WAP war schon immer mal im Gespräch deswegen...ist aber auch komplett tot. Praktisch niemand unsterstützt mehr diesen Standart.

    Zitat von Sheltem

    Aber mehr als ein 40-75 Zeichen Anzeiger und Bediener auf Textbasis wird ein C64 dann nicht sein.

    Ein Browser halt. Dein Computer, den du jetzt gerade benutzt, ist auch mit dem Browser darauf reduziert, dass du auf Text starrst und ein paar Eingaben tätigst.

    Zitat von Sheltem

    Sobald das Ding ein bischen mehr Eigenintelligenz haben will haben wir schon keinen Speicher mehr.

    Was schwebt dir da vor? YouTube, 3D-Spiele?

    Zitat von Sheltem

    Benutzen werden das effektiv 5 Leute

    Ich sehe das Potential etwas höher. Es gibt nicht wenige, die ihre C64-Rechner mit Turbo-Chameleon und Co. aufbrezeln. Die meisten Spiele werden dadurch aber nicht besser. Diese User lechzen quasi nach adäquaten Anwendungen für ihre Hochleistungs-8-Bitter. Das wären schon mal ein paar Dutzend. Und dann kämen ja die Nutzer der ganzen anderen Vintage-Plattformen dazu, vor allen die von Amiga, ST und den ganzen veralteten Smartphones, PDAs und DOSen.

    Zitat von Sheltem

    WAP war schon immer mal im Gespräch deswegen

    WAP war gedacht, um Dumbphones und ganz frühe Internet-Devices mit Online-Angeboten zu versorgen. Als die Geräte leistungsfähiger wurden und mit (echtem) HTML und Farbe zurechtkamen, war das schnell obsolet – spätestens mit dem iPhone und Mobile-Safari war der Drops gelutscht. Ich hatte mein WML-Handbuch noch nicht ganz durch, da zeichnete sich schon ab, dass es sich nicht lohnt, in das Thema tief einzusteigen.


    Das hätte trotz des frühen Todes eine gute Technologie-Basis für unsere Retro-Geräte sein können – und kann es weiterhin. Nur sehe ich keinen Vorteil von WAP/WML gegenüber z.B. MarkDown. Im Gegenteil: WML ist ähnlich "lang" wie HTML, während MD (wie man oben sieht) deutlich kompakter ist. Zudem versucht WML, Inhalte auf "Pages" zu verteilen, was einer flexiblen Darstellung auf sehr unterschiedlichen Geräten eher zuwiderläuft.


    Erst einmal verfolgen MD und WML unterschiedliche Ansätze. Und obwohl der Gedanke von WML näher an dem ist, was wir hier versuchen, bringt das 5 Jahre jüngere (und hier etwas missbrauchte) MD mehr Vorteile – einfach, weil MarkDown kompakter in der Schreibweise ist als MarkUP (IrgendwasML). Bei C64 und Co kommt es auf jedes Byte an (deutlich stärker als selbst bei jedem internetfähigen Dumbphone) und man wäre ja blöd, nicht die beste Technik zu nehmen, die es zu einem gegebenen Zeitpunkt gibt.


    Es gäbe für mich nur einen Grund, WAP einem selbst erweiterten MD als Struktursprache vorzuziehen: Wenn Google nicht vor ein paar Jahren seine WAP-Server ausgeschaltet hätte. Denn die konnten on-the-fly aus HTML-Seiten WAP-Seiten generieren. Aber die gibt es nun mal nicht mehr. Wir müssten also alles selber machen und da sollte man das Beste und einfachste nehmen, was es aktuell so gibt. Meine Meinung zum Thema.


    Allerdings kann das jeder, der es aktiv angeht, natürlich machen, wie er will. Das hier ist nur als Tipp/Anregung zu verstehen und es ist letztlich egal – Hauptsache, irgendwer nimmt sich der Sache an.

    Zitat von Retrofan

    Bei einer Umwandlung zu Markdown geht es ja auch nicht darum, die Seiten hübscher werden zu lassen, sondern im Code kompakter. Und ich nehme an, dass das bestimmt gelungen ist.


    Das war in der Tat der Fall. Hier[1] kann man das mal online ausprobieren. Der dort erzeugte Markdown-Code ist um circa 70% kürzer als der jeweilige HTML-Code meiner getesteten Seiten. Allerdings ist man mit Markdown halt wieder bei einfachem Text ohne Formulare angelangt - also so ziemlich auf dem Stand von Kontiki.


    Zitat von Sheltem

    Aber mehr als ein 40-75 Zeichen Anzeiger und Bediener auf Textbasis wird ein C64 dann nicht sein. Sobald das Ding ein bischen mehr Eigenintelligenz haben will haben wir schon keinen Speicher mehr.


    Das ist richtig. In 64kb bekomme ich nicht mal die Bookmarks untergebracht. :D Aber nun, dann nimmt man sich halt 'ne REU, SCPU, Chameleon o.ä. hinzu, dafür sind die Teile ja da.


    Zitat von Sheltem

    Das ist zwar alles nett als "proof of concept aber das "warum?" (weils irgenwie geht) ist immer noch da.


    Yo, bisher klingt das für mich auch so als solle es ein "Partygag" werden. Um es mal irgendjemandem vorzuführen - und dann kann's ab in die Tonne. Aber selbst dafür müsste man schon mehr bieten, denn Ascii-Browsen ist ein ganz alter Hut. Es ist 20 Jahre her, das ich mich mit Desterm von zu Hause aus in den "Großrechner" der Uni eingewählt habe um dort auf der Shell Lynx zu starten und im Internet zu surfen. Das ging durchaus einigermaßen gut, denn damals waren die Webseiten halt noch einfacher gestrickt - und man hatte keine bessere Möglichkeit.
    Hmm, jetzt wo ich es schreibe fällt mir auf: Das entspricht eigentlich genau dem hier vorgeschlagenen Konzept: "Ein Proxy soll die Webseiten on the fly vereinfachen und in irgendeinem Format an den C64 schicken damit man surfen kann". Prima, Aufgabe gelöst! :)



    [1] http://island205.github.io/h2m/

    Zitat von Rapid Eraser

    Allerdings ist man mit Markdown halt wieder bei einfachem Text ohne Formulare angelangt

    Wie man es um Formulare erweitern kann, habe ich ja explizit oben beschrieben, Bilder sind sogar im Standard schon drin. Wir könnten den Standard jederzeit erweitern, denn eine Kompatibilität muss nur zwischen dem angedachten Proxy und den ja auch neu zu schreibenden Browsern existieren. Wer immer es macht, kann da reinpacken, was immer er will.


    Zitat von Rapid Eraser

    In 64kb bekomme ich nicht mal die Bookmarks untergebracht.

    Die müssen ja nun nicht alle im RAM liegen, selbst der C64 hat Massenspeicher. Und auch wenn wir hier über eine möglichst große Kompatibilität zu allen möglichen Webseiten nachdenken, so wird jeder einzelne User doch nur ein paar Dutzend immer wieder aufrufen.


    Zitat von Rapid Eraser

    Yo, bisher klingt das für mich auch so als solle es ein "Partygag" werden. Um es mal irgendjemandem vorzuführen - und dann kann's ab in die Tonne.

    Also wie bei jeder C64-Demo, an der ja auch Monate lang herumprogrammiert wird. ;) Natürlich gäbe es auch einen Showeffekt, wenn ein C64 oder ZX-Spectrum oder Atari 800 Webseiten (bzw. deren Inhalte) anzeigen und man damit sogar in Foren schreiben könnte. Der reine Nutzfaktor ist halt nicht wahnsinnig hoch, denn jeder wird ein Gerät haben, mit dem man besser surfen kann – und sei es ein modernes Handy.


    Das erhoffte Phänomen beschrieb ich ja schon weiter oben: Dass Leute so einen Browser nutzen würden, einfach weil es geht und man die alten Geräte "liebt". So wie es bei allem der Fall ist, was wir hier so tun. Mal ehrlich, durch unser Hobby wird die Welt kaum besser, Hunger wird nicht gelindert und die technische Entwicklung der Menschheit wird ebenfalls nicht vorangebracht. Unsere Lebenszeit könnte sicherlich produktiver verbracht werden als ausgerechnet mit 30 Jahre altem Elektroschrott herumzuspielen. Wir tun es trotzdem – weil es uns Spaß macht, egal ob es sinnvoll ist. Punkt. Und deshalb wird es Leute geben, die mit dem C64 im Netz surfen würden – auch wenn niemand dabei zuguckt und klatscht.


    Und es wäre nochmal eine ganz andere Sache, wenn man deutlich leistungsfähigere Geräte anguckt, die aber immer noch zu schwach für das "echte WWW" sind, bzw. für die es keinen (mehr oder weniger aktuellen) Browser mehr gibt. Auf einem Windows CE-Gerät mit Uralt-IE-5 ist das Web auch keine Freude mehr, übers 2G-Mobilnetz schon mal gar nicht. Statt der durcheinander gewürfelten IE-Darstellung würde ich eine aufgeräumte Textdarstellung (aufgepeppt um reduzierte Grafiken und Menüs) bevorzugen. Auch auf einem Amiga 1200, Atari ST oder Mac Classic könnte ich mir unseren Proxy-unterstützen Browser gut vorstellen. Auch für diese Geräte gibt es Liebhaber, die den Geräten gerne wieder etwas praktisches Leben einhauchen möchten.


    Hey, natürlich mache ich mir keine Illusionen – das ganze ist Nerd-Kram für ein paar Spinner, wie mich. Niemand wird das ERNSTHAFT täglich 6 Stunden lang nutzen. Aber morgens, als erstes zum Kaffee kurz den C64 anwerfen (der Browser ist vom EF in einer Sekunde im RAM) und bei Heise.de oder hier ins Forum gucken? Warum nicht?


    Zitat von Rapid Eraser

    Ascii-Browsen ist ein ganz alter Hut.

    Deswegen muss es nicht schlecht sein – der C64 ist auch ein alter Hut.


    Und nochmal (deswegen auch mein Mockup weiter oben): Ziel wäre nicht nur ASCII (bzw. UTF-8), sondern durchaus etwas aufbereitet – Menüs z.B. grafisch, statt mit einer Liste (auch weil es Platz spart), Bilder optional auf Abruf (auf stärkerer Hardware eingebunden). Und wenn es um reine Informationen geht, gibt es nichts besseres als fast nackten Text – auf dem Smartphone mag ich die eher reduzierten, mobilen Darstellungen auch lieber als die teils komplexe Desktop-Ansicht.



    Hier ein Mockup der möglichen Darstellung des Formulars aus meiner weiter oben versuchten MarkDown-Erweiterung:



    Ich finde, das wäre schon hübscher, übersichtlicher und bedienbarer als es Formulare in Lynx sind. Ich würde nicht sagen, dass wir hier einen reinen ASCII-Browser erdenken.

    Ich habe mal ausprobiert, wie viel Inhalt man auf einem C64-Screen unterbringen kann, je nach verwendetem Font. Kontiki verbraucht ja leider schon 5 Zeilen nur für das Interface – das geht deutlich besser. In meinem Beispiel sind es nur 2 Kopfzeilen. Bei der Standard-C64-Darstellung (40 x 25 Zeilen minus Interface) sieht man im Beispiel 2 Absätze eines ORF-Online-Artikels (siehe Bild 1). Möchte man in Kontiki den Rest sehen, muss der erst neu geladen werden. Da würde ich natürlich empfehlen, so viel zu laden, wie der C64 verkraften kann (evtl. unter Ausnutzung von Speichererweiterungen) und das nicht stumpf (wie bei BTX) auf Bildschirmseiten zu beschränken.


    Ich habe testweise einen Proportionalfont (namens READ) gezeichnet, den es leicht abgewandelt in normal und fett gibt. Er ist darauf hin optimiert, trotz der Unschärfen eines C64-Röhrenmonitors eine gute Lesbarkeit zu gewährleisten (er arbeitet quasi MIT den Unschärfen) und dabei möglichst wenig Platz auf dem Screen zu benötigen. Er ist schmaler als der GEOS-Standard-Font (BSW) und funktioniert gut mit dem C64-Standard-Zeilenabstand von 8 Pixeln.



    In Bild 2 sieht man nun die fette Variante meines Fonts, deren Zeichen genauso fett sind sind, wie der Standard-C64-Font. Der Platzgewinn wird größtenteils über die Proportionalität der Zeichen erreicht. Im Schnitt bekommt man rund 60 Zeichen in eine (vollständige) Zeile. Dank des Zugewinns von rund 50% gegenüber den üblichen 40 Zeichen sieht man nun einen Absatz mehr (3 Absätze – und damit den ganzen Artikel).


    Wechselt man auf den normalen Schnitt des Fonts (Bild 3), erreicht man sogar ca. 80 Zeichen pro Zeile, allerdings besser lesbar als mit einem 80-Zeichen-Font mit fester Breite, denn man kann ja die typische Form eines Buchstabens besser pixeln, wenn man nicht mit der konstanten Breite eingeschränkt wird. Hier habe ich sogar einen Absatz dupliziert, damit man sieht, dass hier die doppelte Menge Text (= 4 Absätze) gegenüber der Original-Ansicht dargestellt werden kann. Klar, 80 ist das Doppelte von 40 aber dennoch muss man das Ergebnis sehen, um sich wirklich ein Bild davon zu machen.


    Auf den ersten Blick sieht der Text in Bild 3 schon sehr klein aus (obwohl die Zeichen- und Zeilenhöhe identisch zum fetten Schnitt ist) aber ich habe auf einem echten 1084s die Lesbarkeit getestet und war überrascht. Auch wenn der einzelne Buchstabe ab und zu verschwommen wirkt, so kann man den Text im Gesamtbild gut lesen – wahrscheinlich weil die Wörter ähnlich aussehen, wie wir sie von höher aufgelösten Bildschirmen und dem Druck her kennen (und man liest ja nicht (mehr) Zeichen für Zeichen).


    Der fettere READ-Schnitt lässt sich meines Erachtens sogar deutlich schneller lesen als der original-C64-Font. Das liegt wahrscheinlich an dem optisch größeren Zeilendurchschuss (bei gleichbleibendem Zeilenabstand von 8 Pixeln), den kleineren Wortabständen und optimierten Zeichen-Formen.


    Was soll das ganze? ich möchte u.a. zeigen, dass eine flexible Textdarstellung, wie sie mit einem echten Browser möglich ist (und bei BTX oder VT z.B. nicht) zu einem Gewinn für den Leser führt. Er kann die Lesbarkeit je nach vorhandener Technik und Sehkraft flexibel einstellen (durch die Font-Auswahl und auch die Farbe) und erhält ein möglichst optimales Ergebnis mit so viel gleichzeitig dargestelltem Inhalt, wie machbar (was Scrollen bzw. Screen-Redraws reduziert).

    Zitat von Womak

    Ist es nicht Möglich, die nächsten Seiten o.ä. auf z.B. Floppy oder SD während des lesens der "ersten" Seite zwischenzuspeichern?

    Das wäre sicherlich möglich. Aber auch im RAM könnte dafür Platz sein. Der Text einer Standard-Bildschirmseite ist ca. 1 KB groß, bei 80 Zeichen sind es 2 KB. Der Interpreter für Markdown sollte weniger komplex sein als der für HTML und je nach Hardware-Lösung benötigt man noch nicht einmal einen TCP/IP-Stack (wenn der schon in der Hardware steckt). OK, mein Browser-Konzept verbrät 9 KB RAM (statt 1 KB bei Kontiki) für den Bildschirmspeicher (wegen Bitmap-Mode). Aber wenn man optional REU-Speicher unterstützt, sollte ein Auslagern auf Massenspeicher gar nicht nötig sein, um flüssig einen Artikel lesen zu können. Wenn der C64 immer Text für 2 Bildschirme im Speicher halten könnte (also rund 4 KB bei 80 Zeichen), dann könnte er beim Lesen nachladen, ohne dass man Pausen bemerkt. Man kann auch mit 64 KB überraschend viel machen.

    Wer die Darstellung mal selber am eigenen Monitor testen möchte, kann das jetzt tun. Ich habe ein ZIP-Archiv mit den 3 Mockups als PRGs angehängt. So kann man die Grafiken direkt auf dem C64 starten und gucken, welche Darstellung einem am Meisten zusagt. Über Rückmeldungen würde ich mich freuen.

    Zitat von MaTel

    das s sieht auf dem dritten Bildschirm unabsichtlich sehr "zackig" aus

    Bei 4 Pixeln Höhe ist es nicht einfach, was anderes zu zeichnen – und auf einem echten Bildschirm wirkt es meistens auch runder als auf den Mockups. Einfach mal ausprobieren. (Wenn der Font wirklich eingesetzt werden sollte, würde ich ihn natürlich nochmal überarbeiten)

    Es liegt mir fern, mit meinem Font negative Assoziationen auslösen zu wollen – und welche mit dem 3. Reich schon mal gar nicht. Daher habe ich mich nochmal an den Font gesetzt und das kleine "s" modifiziert. Ich befürchte, dass die Lesbarkeit etwas unter der Modifikation leidet aber dafür hat das "s" jetzt keine Blitz-Form mehr. Wie gesagt, 4 Pixel Höhe sind die Herausforderung, bei 5 Pixeln wäre alles kein Problem.



    Das sind aber natürlich alles nur Marginalien – toll wäre es hingegen, wenn sich fähige Programmierer für das Projekt begeistern könnten. Vielleicht bin ich hier aber auch falsch und muss meine Suche ausdehnen. Für den Proxy bräuchte man eh eher einen Server-Programmierer (Kenntnisse von PHP, Ruby, HTTP, HTML, XML und solchen Sachen) und die sitzen sicherlich mehrheitlich woanders. Und beim Client ist ja auch nicht wichtig, welche Plattform zuerst bedient wird. Ich hatte zwar auf den C64 als Leuchtturm-Projekt gehofft, da es mein Lieblingssystem ist – aber vielleicht hat man ja beim ABBUC oder der (US) Apple II Community mehr Kapazitäten frei – und vor allem mehr Interesse oder Hoffnung auf Realisierbarkeit.


    Naja, vielleicht ist das aber alles auch Quatsch und man sollte sich aufs reine Spielen mit den alten 8-Bittern konzentrieren.

    Also ich verfolge das auf jeden Fall mit Interesse. Über Sinnhaftigkeit kann man sich ja generell streiten.
    Ich befürchte, dass die Darstellung jeglichen Inhalts wohl mehr Probleme als Spaß machen wird. Die Beschränkung auf bestimmte Formate (z.B. Foren, WIKI...) wäre da vielleicht realistischer.


    Weiß nur nicht, ob ich da eine große Hilfe sein kann.


    Die Fonts finde ich übrigens gut lesbar und die korrigierte Doppel-s kommt wirklich besser - auch weil alle anderen Buchstaben doch eher "runder" wirken.
    Und das nach unten verlängerte f versteh ich nicht so ganz.