RedeemerSVG.TSVGImage - Kleine SVG-Unit für Delphi mit GDI

[jaenicke]

Ich verstehe die Spezifikation so, dass SVG alleine XML kompatibel ist, aber auch mit HTML Syntax in HTML-Dokumente eingebettet werden kann.

Gibt es bei SVG tatsächlich Elemente die gar nicht geschlossen werden müssen, oder nur die Möglichkeit von self closing tags?

[himitsu]

Wenn/da es mit XML kompatibel ist, müssen alle Elemente geschlossen sein.
Allgemein ist XML mit HTML kompatibel und mit XHTML sowieso, bzw. XHTML ist eigentlich eine Erweiterung von HTML, die mit XML kompatibel ist.

[Redeemer]

Zitat von jaenicke:

Ich verstehe die Spezifikation so, dass SVG alleine XML kompatibel ist, aber auch mit HTML Syntax in HTML-Dokumente eingebettet werden kann.

Welche hast du gelesen? SVG1 und SVG2 sind da komplett unterschiedlich. Der von mir zitierte Teil ist durch „can generate a conforming DOM“ ja schon sehr deutlich, dass eine SVG2-Datei weder XML noch DOM ist. Statt mir kompliziert das dazugehörige XML oder DOM zu generieren, habe ich mir lieber einen Parser geschrieben, der da toleranter ist.
Ich weiß gerade keine Tags, die nur optional geschlossen werden müssen, das liegt aber auch daran, dass ich keine Website finden konnte, wo das steht. selfHTML behandelt in der Hinsicht nur SVG1. Meine Klasse lädt übrigens auch das erste SVG-Bild in HTML-Dateien, was nicht unbedingt beabsichtigt ist, aber ein nettes Feature.

[Redeemer]

Habe die neue Version 0.2b-alpha um die Lösung mit dem alternativen UTF-8-Encoding ergänzt. Der Download enthält jetzt das Projekt für die Demoanwendung.

In dem Projekt, in dem ich das nutze, habe ich leider ein Problem:

Delphi-Quellcode:

type TSVGImage = class(TPNGImage)
  ...
end;

...

procedure DoSomething();
var
  GraphicClass: TGraphicClass;
  Graphic: TGraphic;
begin
  GraphicClass := TSVGImage;
  Graphic := GraphicClass.Create(); // Ruft TPNGImage.Create() auf. (schlecht)
  // ...aber...
  Graphic := TSVGImage.Create();     // Ruft TSVGImage.Create() auf. (gut)
end

Das liegt wohl daran, dass ich bei Create reintroduce verwende statt override, denn die CreateBlank-Methode des zugrundeliegenden PNG-Bilds benötigt die Create-Methode des PNG-Bilds, weshalb ich Create nicht überschreiben kann. Habt ihr da Ideen?

[TiGü]

Zitat von Redeemer:

]Das liegt wohl daran, dass ich bei Create reintroduce verwende statt override, denn die CreateBlank-Methode des zugrundeliegenden PNG-Bilds benötigt die Create-Methode des PNG-Bilds, weshalb ich Create nicht überschreiben kann. Habt ihr da Ideen?

Hä, wieso nicht override?
Du rufst doch den TPNGImage.CreateBlank innerhalb deines TSVGImage.Create auf. Muss doch gehen ohne reintroduce.

Delphi-Quellcode:

...
  public
    constructor Create(); override;
    procedure LoadFromStream(Stream: TStream); override;
end;

constructor TSVGImage.Create;
begin
  inherited CreateBlank(COLOR_RGBALPHA, 8, 1, 1); // 0 führt beim Setzen einer neuen Größe zum Fehler
end;

[Redeemer]

inherited CreateBlank ruft Create auf. Wenn ich Create überschreibe, gibt's also 'ne endlose Rekursion und damit einen Stack Overflow.

[TiGü]

Zitat von Redeemer:

inherited CreateBlank ruft Create auf. Wenn ich Create überschreibe, gibt's also 'ne endlose Rekursion und damit einen Stack Overflow.

Ja richtig, da habe ich nicht mitgedacht bzw. nicht ausprobiert.

Du musst letztendlich gar nichts hinschreiben und es sollte dann so gehen wie gewünscht:

Delphi-Quellcode:

type
  TMyPngImage = class(TPngImage)
  public
    constructor Create;
  end;

...

{ TMyPngImage }

constructor TMyPngImage.Create;
begin
  inherited CreateBlank(COLOR_RGBALPHA, 8, 1, 1);
end;

[jaenicke]

Das ist einer der Gründe weshalb Konstruktoren möglichst schlank sein sollten. In diesem Fall reicht es doch CreateBlank nicht als Konstruktor zu implementieren (was ohnehin nicht schön ist), sondern als simple Methode. Der überschriebene Konstruktor ruft dann CreateBlank und nur inherited auf, das war es.