Mein momentaner Fokus ist gerade auf dem neuen HTML Reader und Tabellen.
Der HTML Reader kann nun eingeschränktes CSS interpretieren.
Dabei können die Stylesheets in der HTML-Seite drin, extern oder inline sein, es kommt letzlich aufs selbe raus.
Sie werden einfach gewissen Regeln folgend "eingehängt"
Beispiel:
Code: Alles auswählen
<link href="style.css" media="screen" type="text/css" rel="stylesheet"/>
<style>
span.sym {
color: darkred
}
</style>
</head>
<body>
<span class="sym" style="color:red;">hallo</span>Der CSS Parser ist eingeschränkt, weil es sehr viele Varianten und Regeln gibt, die ich erstens zeitlich nicht alle umsetzen kann und die "in the wild" praktisch nie angetroffen werden. Ich würde auch nie behaupten, dass ich die Geschichte begriffen hätte
Trotzdem: Was kann der Parser:
- Selektoren
- Klassen
- IDs
- Pseudos
- Sub-Selektoren
Also ein CSS Auszug wie folgender
Code: Alles auswählen
body, td, a {
font-family: Helvetica, Arial, Geneva, SunSans-Regular, sans-serif;
font-size: 12px;
text-decoration: none;
color: #000000;
}
div a{
color:red;
}
td {
vertical-align: top;
}
.spacer {
margin-top: 10px;
margin-bottom: 10px;
height: 1px;
}
a:hover, #navigation a:hover {
color: #72A436;
}Hier sieht man praktisch alle interpretierten Regeln:
z.B. "a" hat Grundsätzlich die Eigenschaften von body, td, a {..} ebenso ein td
dieses wir aber überschrieben von td {vertical-align: top;}
Während die meisten Styles statisch zugewiesen werden können, muss man bei der Deklaration des Subselektors von div a{color:red;} den Parse-Tree hochkraxeln und sehen, ob für eines der Elternelemente einen anderen Style für den a-tag vorgesehen ist.
Dazu kommen noch die Pseudos wie a:hover, also den Style für ein a Tag auf dem der Cursor steht.
Das gleiche geht mit den Klassen und ID's wie #navigation a:hover, Also ein a-Tag in einem Elternelement mit der ID "navigation" kann wieder anders dargestellt werden beim hovern.
Confusing isn't it?
Mehr kann und will ich im Augenblick nicht umsetzen zumal das ca 95% aller Stylesheets die man "so antrifft" abdeckt.
------------
Eine grundsätzliche Entscheidung war es, den DOM-Tree abzuflachen für WOPR.
Während es für handgeschriebenes HTML sinnvoll sein kann, auf Hierarchie zu setzen, macht das für eine Wysiwyg Editor keinen Sinn.
Wie und warum sollte ich dem User verklickern, dass der Absatz den er gerade bearbeitet, das X-te Kind eines Elternabsatzes ist und beispielsweise dessen
Einzugseigenschaften erbt? Der User kann einfach einen Teil markieren und dessen Einzug bestimmen.
Das zeigt natürlich ein Grund-Dilemma von WOPR für HTML, weshalb es auch nicht als HTML Editor zu interpretieren ist.
Also das:
test
test
test
wandle ich um in
para [margin-left 20px] test
para [margin-left 40px] test
para [margin-left 20px] test
------------
Dann kommt das herausfinden der defaults für das darstellen des HTML (ohne CSS).
Interessanterweise regelt das W3Consortium oft das rendering nicht.
Man kann dann nur versuchen herauszufinden wie die Browser das machen.
Beispiel:
Ein hat keinen vordefinierten Abstand (margin), ein aber schon. Der Abstand oben und unten an einem scheint jeweils
nochmal die font-size in pt zu sein. Also die Font.Size * PPI / 72.
Ein Tag hat einen margin-top und margin-bottom. Wenn aber direkt ein weiteres Block-element mit einem margin-top folgt, wird dieser nicht angewandt.
Lustig wa?
------------
Noch lustiger ist es mit Tabellen. Dort gibt es explizit keine Regeln des W3C.
Eine HTML Tabelle ohne Eigenschaften passt sich der Grösse des Inhalts an.
Dazu musste ich ein 2-Pass verfahren anwenden.
Also erstmal schauen wie die Minimalbreite einer Tabellenspalte (ein Wort, ein Bild), und die Maximalbreite des nicht umgebrochenen
Textes ist. Anhand dieser Daten kann man dann die Spaltenweiten verteilen und im zweiten Pass die Zellen befüllen und die Umbrüche machen.
So weit bin ich schon. Auch fixe bzw. prozentuale Tabellenbreiten habe ich schon.
Was ich noch machen muss ist der Mix also z.B. Erste Spalte 200px, Zweite Spalte 70%, dritte Spalte undefiniert.
Dazu kommen colspan rowspan etc.
Und für alle die jetzt immer noch lesen:
Wie sollte eine Markierung auf mehreren Zellen einer Tabelle kopiert werden?
Ob ich eure Vorschläge umsezten kann weiss ich nicht.
Aber was wäre ideal?
Beispiel: Ich selektiere zwei Zellen einer vierspaltigen Tabelle.
Wenn ich diese Selektion nun einfüge, soll diese dann innerhalb der Tabelle als zwei neue Zellen eingefügt werden oder nur als Text?
Soll ausserhalb der Tabelle eine neue, zweispaltige Tabelle erstellt werden, oder nur der Text gepastet werden?
Ich hoffe ich habe euch nicht zu sehr gelangweilt.
P.S: Warum frage ich das? Es ist interessant zu sehen wie z.B. OpenOffice und KWord diese Dinge anders lösen.
Von daher ist keine Referenz zu erwarten.
Es tut aber auch ein bisschen gut, zu sehen das WOPR OpenOffice Text in Positionsrahmen wenigstens anzeigt (wenn auch an falscher Position) während KWord (in 3.5.5) diese einfach verschluckt und dem User vorenthält.
Aber das Positionsrahmen Konzept ist momentan für WOPR noch nicht zu bewältigen.
Anzeigen wäre nicht so schwerig, der Text-Umlauf aber schon eher.
Das was komplett aus dem System fallen würde ist die Navigation. Während der WOPR Cursor eigentlich immer den Document-Tree rauf und runter kraxelt,
ist dies bei Positonsrahmen nicht möglich. Diese fänden ja quasi ausserhalb des Document-Trees statt und wären and die Seite oder einen Absatz gebunden.
Also müsste man einen zweite Liste halten mit allen fix-positionierten Elementen. Ich weiss nicht ob ich das umsetzen werde.
Gerne nehme ich eure Ideen entgegen, aber den Source-Code veröffentliche ich nicht, solange ich das Ganze nicht für einigermassen brauchbar halte.
Ich mache es ja nur als Hobby aber möchte etwas vernünftiges abliefern.
Also wer in den nächsten zwei Wochen sowas braucht, muss sich nach anderen Lösungen umsehen.
Ich glaube auch nicht, dass mir jemand dabei helfen kann.
Nicht dass ich denke, dass ihr zu doof seid, aber ich verstehe ja schon manchmal selber meinen Code nicht mehr und ich kann mir nicht
vorstellen, dass sich jemand auf die Schnelle in die Problematik und meinen Ansatz eindenken kann.
Hier mal ein paar Dateigrössen:
woprdocument.pas 130.4 KB
woprcontrol.pas 74.5 KB
woprrendering.pas 33.9 KB
woprkeycmds.pas 33 KB
woprstreamerhtml.pas 27.1 KB
woprdoctree.pas 26.0 KB
woprstreamerod.pas 25.3 KB
woprcss.pas 22.9 KB
etc. pp
Verein
Links
Suche