ganz simples Vektor-Grafikformat

[_frank_]

Hallo,
ich bin am überlegen, dem DFM-Editor eine funktion bereitzustellen um Vektorgrafiken darzustellen. Diese soll benutzt werden, um unbekannte controls darzustellen.

Bedingungen:
- definition im textformat (für Speicherung in ini)
- ohne header etc.
- nur einfache Befehle wie linie, rechteck, kreis, text, farbe setzen, etc.
- relative definition (%)

ich hab mir schonmal SVG und WMF angeschaut, wobei SVG einen nicht unbedeutenden Header mitbringt, und somit der Parser ziemlich riesig ist und WMF nicht textbasiert ist.

vielleicht hat der eine oder andere sowas schonmal geschrieben, in der Forumsuche hab ich noch nichts passendes gefunden.

habe mir auch schon Gedanken (in Anlehnung an SVG und den Canvas-Methoden) gemacht, wie man sowas realisieren könnte:

Linie: LXXYYXXYY (XX,YY => zweistellige prozentuale Angaben, anfangs und Zielpunkt)
Rechteck: RXXYYXXYY
Elipse: EXXYYXXYY
Stifteigenschaften setzen: PSRGB (S=>Style/Mode,1 HexDigit pro Farbkanal, wird gedoppelt [F=>FF])
Hintergrund: BSRGB
Schriftfarbe: FSRGB

die Definition ggf. per Komma getrennt (wegen besserer Lesbarkeit und Einlesen in stringlist :) )
nur beim Text bin ich noch am grübeln, da ich sowas wie Positionierung/Ausrichtung und schriftgröße mit einbauen müsste...

TASXXYY:hier_der_text (A=>Alignment[R,C,L],S=>size[%])

vielleicht fällt jemanden eine bessere Idee an... :)

Gruß Frank

[arbu man]

Als ich den Titel gesehen hab musst ich spontan an XML denken. Damit ließe sich die Sache leicht realisieren.

mfg, Björn

[xaromz]

Hallo,

Zitat:

Zitat von arbu man

Als ich den Titel gesehen hab musst ich spontan an XML denken. Damit ließe sich die Sache leicht realisieren.

damit sind wir ja schon wieder bei SVG.

Gruß
xaromz

[Bernhard Geyer]

Evtl. gleich ein Delphi-Win32-Projekt aufsetzen das XAML (jedenfalls die GUI-Beschreibung) als Beschreibung verwendet.

[arbu man]

Zitat:

Zitat von xaromz

Hallo,

Zitat:

Zitat von arbu man

Als ich den Titel gesehen hab musst ich spontan an XML denken. Damit ließe sich die Sache leicht realisieren.

damit sind wir ja schon wieder bei SVG.

Gruß
xaromz

Es muss ja nicht gleich so Komplex sein. Ein einfaches Format würde sicher auch reichen. Z.B. :

XML-Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<grafik>
  <element>
    <typ>linie</typ>
    <farbe>rot</farbe>
    <start>(0:0)</start>
    <ende>(10:10)</ende>
  </element>
</grafik>

Ließe sich einfach mit ein paar Zeilen parsen:

Delphi-Quellcode:

function StrToPoint(Str: string): TPoint;
var
  s, s1: string;
  p: integer;
begin
  s := StringReplace(Str, '(', '', []);
  s := StringReplace(s,   ')', '', []);
  p := Pos(':', s);
  s1 := Copy(s, 1, p-1);
  result.X := StrToInt(s1);
  Delete(s, 1, p);
  result.Y := StrToInt(s);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
  s: string;
  start, ende: TPoint;
  Element: TJclSimpleXMLElems;
begin
  Refresh;
  XML.LoadFromString(Editor.Lines.Text);
  for i := 0 to XML.Root.Items.Count - 1 do begin
    Element := XML.Root.Items[i].Items;
    if Assigned(Element.ItemNamed['typ']) then begin
      if Element.ItemNamed['typ'].Value = 'linie' then begin
        if Assigned(Element.ItemNamed['farbe']) then begin
          s := Element.ItemNamed['farbe'].Value;
          if s = 'rot' then begin
            Canvas.Pen.Color := clred;
          end;
          // usw.
          // viell. html farbcodes parsen
        end;
        if
          Assigned(Element.ItemNamed['start'])and
          Assigned(Element.ItemNamed['ende'])
        then begin
          start := StrToPoint(Element.ItemNamed['start'].Value);
          ende := StrToPoint(Element.ItemNamed['ende'].Value);
          Canvas.MoveTo(start.X, start.Y);
          Canvas.LineTo(ende.X, ende.Y);
        end;
      end;
      if Element.ItemNamed['typ'].Value = 'rechteck' then begin
        //...
      end;
    end; // else Fehler behandeln
  end;
end;

Im Beispiel für das XML Mit einen TJvSimpleXMl der JEDIS verarbeitet. Okay ein richtiges Vektorformat ist es nicht aber vielleicht ein guter Anfang.

mfg, Björn

[_frank_]

Wie gesagt, das ganze soll ziemlich kompakt sein, da ich dies mit in meine vorhandenen (INI-) Konfigurationsdateien einbauen kann...
weiterhin möchte ich auf XML-Routinen verzichten, da mir unter D3 der entsprechende Parser fehlt bzw. diesen nachzurüsten den Nutzen übersteigt...

Gruß Frank

[Bernhard Geyer]

1, Inidateien stoßen schnell an ihre grenzen wenn es geht gruppierte Elemente zu verwenden
2, Ein eigenes XML-Format wird schnell komplexer als man denkt da man über der laufe der Zeit immer mehr Elemente benötigt. Und wenn man sich an ein bestehendes Format (SVG) ranhängt braucht man sich neue Tags keine gedanken zu machen. Man unterstützt halt mehr Elemente. Ein Ansatz wäre evtl. das Tiny-SVG-Format das gegenüber dem "normalen" SVG-Format schon eingeschränkt ist. Für den anfang hat man halt keine 100%ige Tiny-SVG-Unterstützung.

[_frank_]

wen es interessiert, ich hab mal angefangen ein eigenes Format zu implementieren, um Vektor-Grafiken relativ platzsparend im Textmodus zu definieren (etwa so wie im ersten Posting).

http://www.fw-web.de/download.php?file=unknownImage.zip

vielleicht kann es noch jemand anderes gebrauchen ;)

Gruß Frank

[kalmi01]

Moin moin,

Zitat:

Vektor-Grafiken relativ platzsparend im Textmodus zu definieren

also ob das so platzsparend ist ?
Und lesbar ist es auch nicht gerade.

Warum verwendest Du nicht vorhandenes ? Z.B. PostScript:

Delphi-Quellcode:

0 0 m        % moveto
0 200 l      % lineto
200 200 l
200 0 l
0 0 l
1 1 0 sc     % setrgbcolor
f            % fill
1 0 0 sc
50 180 m
(Hallo) show

Ist Text, ist nicht so exotisch, braucht auch nicht viel Platz.

[alzaimar]

Da fällt mir noch HPGL ein, eine ziemlich alte Grafik-Sprache von Hewlett-Packard für ihre Plotter. Es scheint jedoch immer noch aktuell zu sein. Vielleicht ist das etwas für Dich.

PostScript ist zwar genauso gut, nur ist die zu implementierende Stack-Maschine nicht ganz so trivial, wie ein simpler HPGL-Interpreter. Das gilt allerdings nur, wenn man die gesamte Postscript-Sprache implementieren will, ansonsten nehmen die beiden Sprachen sich nicht viel.

[kalmi01]

Hi alzaimer,

Zitat:

Da fällt mir noch HPGL ein

Ist aber gegenüber PS sehr eingeschränkt !

Zitat:

PostScript ist zwar genauso gut, nur ist die zu implementierende Stack-Maschine nicht ganz so trivial

man muss ja nicht gleich einen kompletten PS-Interpreter basteln.
Ein einfacher Parser reicht doch schon.
War mal ne Übung für mich, um Delphi zu lernen :mrgreen:
Aber irgendwann bastel ich mir aber noch mal meinen eigenen PS-Interpreter :wink:

PS hat den Charme, dass man mit Ghostview bereits einen PreViewer hat.

[_frank_]

Zitat:

Zitat von kalmi01

also ob das so platzsparend ist ?
Und lesbar ist es auch nicht gerade.

platzsparend find ichs schon (wird ja evtl noch optimiert, z.b. braucht man bei zentrierter Text-Ausrichtung den jeweiligen offset nicht)...
gut, lesbar ist so ne sache, aber ist ja auch noch der Anfang, evtl bau ich noch trennzeichen ein, um die befehle optisch zu trennen. ist aber eigentlich nicht notwendig, da es dafür irgendwann mal nen Editor geben soll.

Zitat:

Zitat von kalmi01

Warum verwendest Du nicht vorhandenes ? Z.B. PostScript:

Delphi-Quellcode:

0 0 m        % moveto
0 200 l      % lineto
200 200 l
200 0 l
0 0 l
1 1 0 sc     % setrgbcolor
f            % fill
1 0 0 sc
50 180 m
(Hallo) show

Ist Text, ist nicht so exotisch, braucht auch nicht viel Platz.

nutzt zeilenumbrüche als Trennzeichen, oder? in dem fall ists halt für ini ungeeignet...
da dürfte meine definition aber kürzer sein, oder täusche ich mich da ;)

Delphi-Quellcode:

//postscript scheint absolute positionsangaben zu haben...ich hab prozentuale :)
R*FF000009999 //mit der 99 wird noch geändert damit 100% möglich ist, farbe hab ich jetzt mal FFFF00 genommen, Stift: den aktuellen
//dürften die ersten 7 zeilen sein :)
TF0000030605Hallo //die letzten 3

Ansonsten bin ich für verbesserungsvorschläge zu haben :)

Gruß Frank

[kalmi01]

Zitat:

nutzt zeilenumbrüche als Trennzeichen, oder?

Nein, war nur der Optik wegen.

Zitat:

//postscript scheint absolute positionsangaben zu haben

Nein, es gibt auch relative Bewegungen.
Es gibt:
- absolute
- relative
- transformierte/skalierte
Bewegungen

Man kann schön übersichtlichen oder aber kompakten Code erzeugen, lediglich Space als Trenner reicht.
Also Zeilen orientiert oder als Stream, das ist völlig egal.

Nur um Missverständnissen vor zu beugen:
- Ich will Dich nicht von irgendwas überzeugen/abbringen.
- Ich beabsichtige nur, Dir Vorhandenes auf zu zeigen.

[_frank_]

Zitat:

Zitat von kalmi01

Nein, es gibt auch relative Bewegungen.
Es gibt:
- absolute
- relative
- transformierte/skalierte
Bewegungen

Man kann schön übersichtlichen oder aber kompakten Code erzeugen, lediglich Space als Trenner reicht.
Also Zeilen orientiert oder als Stream, das ist völlig egal.

also mit relativ mein ich prozentual zur Größe der zeichenfläche, nicht die position relativ zu der aktuellen position. kann es das wirklich? dann schau ich mir das mal an.

Zitat:

Zitat von kalmi01

Nur um Missverständnissen vor zu beugen:
- Ich will Dich nicht von irgendwas überzeugen/abbringen.
- Ich beabsichtige nur, Dir Vorhandenes auf zu zeigen.

dafür danke ich dir ja auch :) würde niemanden einen Vorwurf machen, der versucht mir zu helfen ;)
sorry, wenn es vielleicht anders rüberkam.

ich muss halt nur schauen, ob es meinen Anforderungen gerecht wird.
hab mir jetzt halt die mühe gemacht, das irgendwie zu implementieren und würde ungern alles verwerfen.
aber sicher lässt sich das eine oder andere mit einbauen bzw. an meinem Konzept verbessern. von daher nützen mir die Tips schon, auch wenn ich das format selbst vermutlich nicht übernehme...
ich brauche halt nur überall den relativen bezug auf die Zeichenfläche (bei der schrift haut das noch nicht so hin, wie es soll). ich beabsichtige mit dem code das komplette canvas auszufüllen, nicht nur irgendwas skalierbar zu malen.
und z.b. eine liniendefinition mittels moveto/lineto finde ich nicht so gut wie einen linienbefehl der beide endpunkte beinhaltet. Auch aus dem Grund, da man das moveto eigentlich nirgends anders verwenden kann, oder sehe ich das falsch?

Gruß Frank

[kalmi01]

Hallo,

Zitat:

eine liniendefinition mittels moveto/lineto finde ich nicht so gut wie einen linienbefehl der beide endpunkte beinhaltet

dann würde ich in Postscript eine Prozedur einbauen

Delphi-Quellcode:

/line { 4 -2 roll
        moveto
        lineto
      } def

und schon wäre es um eine Funktion erweitert, welche Start- und Endkoordinaten benötigt.

Zitat:

a man das moveto eigentlich nirgends anders verwenden kann, oder sehe ich das falsch?

Naja, das moveto fährt halt einen Punkt an.
Also quasi die Bewegung mit angehobenem Stift.

Zitat:

mit relativ mein ich prozentual zur Größe der zeichenfläche

das ist kein Standard in PS.
Liesse sich aber auch realisieren :dancer2:
Nur wozu braucht man Größendefinitionen relativ zur Zeichenfläche ? :gruebel:
Also für geometrische Objekte kann ich mir das ja noch vorstellen, aber für Text ? :gruebel:

Wenn es nur darum geht, eine Seite immer gleich aussehen zu lassen, egal ob auf A5 oder A0, dann geht das mit PS mit Sicherheit eleganter.

Zitat:

würde niemanden einen Vorwurf machen, der versucht mir zu helfen
sorry, wenn es vielleicht anders rüberkam.

Nein, kam es nicht.
Ich wollte nur klar stellen, dass ich Dich nicht von irgendetwas zwanghaft überzeugen will.

Ausserdem ist das hier ein Delphi-Forum und keine PS-Bastelecke :mrgreen:

Erzähl doch mal, was Du eigentlich genau beabsichtigst mit diesem Format ?

[Lannes]

Hallo,

eventuell ist das Datenformat DVKAZ interessant.

Das Format DVKAZ enthält Vektordaten zur Darstellung der amtlichen Verkehrszeichen und Symbole.
Hier mal ein paar Links:
http://www.bast.de/cln_007/nn_42742/.../vz-start.html
http://www.bast.de/cln_007/nn_42742/.../vz-daten.html
http://www.bast.de/cln_007/nn_42742/...dvkaz-zip.html

[kalmi01]

Da hat wohl IGES Pate gestanden :kotz:
Das ist alles, aber nicht kompakt, sorry :duck:

[Lannes]

Hallo,

hab ich auch nicht geschrieben :)

Dachte halt das er sich da eventuell Anregungen holen kann.

[_frank_]

Hallo,

Zitat:

Zitat von kalmi01

dann würde ich in Postscript eine Prozedur einbauen und schon wäre es um eine Funktion erweitert, welche Start- und Endkoordinaten benötigt.

wo würdest du die einbauen? in den parser, den ich schreiben müsste? die Befehle von vorhin

Zitat:

Zitat von kalmi01

Naja, das moveto fährt halt einen Punkt an.
Also quasi die Bewegung mit angehobenem Stift.

soweit schon klar :) (kenne das ja von Canvas.moveTo), ich hab da nur den praktischen Nutzen gesucht, da moveto (bei Canvas) nur für linien genutzt wird, alles andere wird ja separat definiert (unabhängig von der aktuellen position)

Zitat:

Zitat von kalmi01

Zitat:

mit relativ mein ich prozentual zur Größe der zeichenfläche

das ist kein Standard in PS.
Liesse sich aber auch realisieren :dancer2:
Nur wozu braucht man Größendefinitionen relativ zur Zeichenfläche ? :gruebel:
Also für geometrische Objekte kann ich mir das ja noch vorstellen, aber für Text ? :gruebel:

naja, auch der Text sollte sich an die jeweiligen proportionen halten, nur ist das da nicht ganz so einfach...müsste den text ggf. auch stauchen können.

Zitat:

Zitat von kalmi01

Wenn es nur darum geht, eine Seite immer gleich aussehen zu lassen, egal ob auf A5 oder A0, dann geht das mit PS mit Sicherheit eleganter.

Erzähl doch mal, was Du eigentlich genau beabsichtigst mit diesem Format ?

siehe erstes Posting *g*

Zitat:

Zitat von _frank_

ich bin am überlegen, dem DFM-Editor eine funktion bereitzustellen um Vektorgrafiken darzustellen. Diese soll benutzt werden, um unbekannte controls darzustellen.

die grafiken sind für die Formular-Vorschau gedacht, um Controls abzubilden, die der dfm-editor nicht kennt. Wenn es mehrere sind, kann man die momentan nicht mehr unterscheiden (es sei denn man nutzt das ControlReplacement, wie das aktuell für die TNTControls eingearbeitet ist).
es geht also um eine reine Bildschirmdarstellung...nicht für den druck
die Konfiguration des DFM-Editors beruht auf mehrere Ini-Dateien, somit würde ich die Definition auch gerne in diese einarbeiten.
ini habe ich deswegen genommen, da es keinen einfachen XML/SVG-Parser für D3 gibt (zumindest hab ich noch keinen funktionierenden finden können) und diese für meine bisherigen Einstellungen ausgereicht haben.
Da die Definition evtl. sehr komplex werden kann, sollte das format ziemlich kompakt sein und keine Zeilenumbrüche etc enthalten, da es in inis auch gewissen Grenzen gibt :)
es geht auch weniger um die lesbarkeit...ist ja nicht so, dass man da ständig was dran ändert.
btw.
ich überlege aber auch schon, das ganze dynamisch (an die jeweiligen Eigenschaften gekoppelt) zu definieren. aber da ist mir noch nichts sinnvolles eingefallen. Dafür müsste man natürlich ein komplexeres Format nehmen

Hoffe etwas mehr klarheit in die Sache gebracht zu haben :)

Gruß Frank

[kalmi01]

Hallo Frank,

Zitat:

ich hab da nur den praktischen Nutzen gesucht, da moveto (bei Canvas) nur für linien genutzt wird

in Postscript gibt es immer eine aktuelle Position, d.h. man muss erst eine Position anfahren bevor man was machen kann: Linie, Kreisbogen, Spline, usw.

Zitat:

siehe erstes Posting *g*

Naja, hatte ich schon, nur war mir der Hintergrund nicht klar geworden.
Nach Deinem letzten posting ist klar, was Du Dir dabei gedacht hast. In diesem Fall wäre PS denkbar ungeeignet.
Eigentlich brauchst Du nur Polylines und Text, den Rest kann davon ableiten.

[_frank_]

das mit den Polylines hab ich mal aufgegriffen :) man kann nun bis zu 15-eckige polygone erstellen mit einem line-befehl (offen/geschlossen).
der Line-Befehl hat jetzt ein byte mehr vor der ersten position (count-byte), danach kommen count*4bytes als Eckpunkte und wenn das Polygon geschlossen werden soll noch ein '*'.

weis denn jemand etwas zu dem text, also wie man den stauchen kann, momentan berechne ich ja nur anhand der höhe die entsprechende TFont.size aus. Dies haut natürlich bei bestimmten proportionen (höher als breiter) nicht wirklich hin, daher wär eine stauch-funktion ganz praktisch. Hab leider noch nicht wirklich was gefunden dazu...

evtl. fällt jemand noch eine optimierung ein :)

Gruß Frank