Tweet
AW: Bilder-Beschriftung
lieber deconstruct,
ich danke dir natürlich für deine ausführliche reaktion und all die sachliche aufklärung bzgl. der angesprochen punkte. es geht mir ja mit meiner 'kritik' keineswegs darum, deine tatsächlichen leistungen zu mindern, sondern einfach nur deutlich herauszuarbeiten, worin sich meine persönliche unzufriedenheit mit der gegenwärtigen lösung gründet -- obwohl ich es natürlich genaus gut einfach dabei belassen könnte, still und heimlich für mich selbst zu beschließen, dieses programm gar nicht erst zu verwenden und daher alle damit verbunden debatten schlichtweg zu ignorieren.
zum gegenwärtigen format der der konfigurations-/daten-speicherung bzw. meiner charakterisierung als 'proprietäres' format:
ich spreche hier von 'proprietär' -- obwohl sich dieser gebrauch evtl. nicht wörtlich mit dem zu decken scheint, was man unter diesem stuichwort in lehr- u. gesetzbüchern od. gar im wikipädia finden mag --, um den umstand hervorzuheben, dass es dafür keine allgemein verfügbare geregelte definition gibt und daher jedes andere programm, das sich auf entsprechende intuitive einfühlung bzw. reverse-engeneering der gegenwärtigen funtionsweise verlässt, jederzeit durch änderungen seitens des ursprünglichen programms/herstellers etc. als hinfällig erweisen kann!
und um hier gleich auch noch ein paar weitere details anzusprechen, die mir beim entsprechenden studium relativ rasch ins auge gefallen sind, und möglicher weise im rahmen div. verbesserungsbemühungen berücksichtigt werden könnten, sei als anregung noch stichwortartig ergänzt:
trotzdem -- so schrecklich kompliziert ist das ganze im vorliegenden falle nun auch wieder nicht -- es geht mir hier vielmehr ganz prinzipiell darum, ob man diverse probleme nicht einfach gelich von grund auf vermeiden kann, wenn man den ganz allgemein sinnvollen maßstab der interoperabilität nicht völlig aus den augen verliert.
eine umstellung auf XML oder JSON bringt hier sicher gewisse vorteile mit sich, trotzdem hoffe ich, dass wir über derartige nebensächlichkeiten wirklich nicht lange streiten müssen!
was die rolle bzw. möglichkeiten und kompatibilität von SVG anbelangt, liegt die sache allerdings meiner ansicht nach nicht mehr ganz so einfach, wie du es hier darzustellst versuchst:
würde sich dein programm tatsächlich darauf konzentrieren, entsprechende zurdnungen (position des gipfels im bild, benennung, zusatzangaben...) zu erfassen und in seinen datensätzen festzuhalten, würde es sich doch meines erachtens nach geradezu aufdrängen, sich darauf zu konzentrieren, die entsprechenden -- von mir aus, an ganz spezifischen semantischen gesichtspunkten ausgerichteten -- datenstruktur in ihrer grafische entsprechung zu übersetzten. sollten die ausgangsdaten dafür tatsächlich bereits in XML-format vorliegen, ließe sich das hier vermutlich mustergültig mit einer XSL-transformation gewährleisten.
wirklich spannend bzw. auch für die praktische anwendung von interesse wird die ganze sache hier aber gerade erst deshalb, weil sich auf diesem wege beschriftungen realisieren lassen, die das ursprüngliche vorliegende bild gar nicht erst antasten und verändern verändern müssen, sondern quasi wie eine darüber liegende transparente schicht (=overlay) zu beschriften vermögen(!), darüber hinaus aber auch in ihrer darstellung im web eine weitaus bessere optische umsetztung bieten (schriften und stark kontrastierende linien müssen in einem hoch komprmierten JPEG immer unangenehm überschwingen) und -- aber, da wird's dann vermutlich den meisten wieder ein wenig zu kompliziert -- durch die verwendung von CSS den darstellungsstil (bsp. schriftgöße...) von der ursprünglichen angabe der zuordnungspunkte weitestgehend lösen und einem später leicht abzuänderndem einheitlichen web-design überantworten, darüber hinaus aber auch noch von sich aus div. scriptbasierende interaktion vorsehen!
lauter dinge also, von denen ich doch denke, dass sie ganz deutlich über jenen status quo hinausweisen, den du hier so nachdrücklich zu verteidigen versuchst.
ich halte daher SVG weniger für ein zusätzliches feature, dass man ggf. noch zusätzlich über externe konverter etc. abdecken könnte, sondern vielmehr für eine höchst interessantes arbeits- und austauschformat, dass man höchstens mit rücksichtnahme auf veraltete webbrowsere u.ä. unter umständen durch parallele ausgabe in einem traditionellen pixmap-format als fall-back-lösung ergänzen sollte, prinzipell aber als absolut ideale und zukunftsweisende basis für ein derartiges projekt verstehen könnte.
trotzdem: weder will ich dich hier unnötig belehren, noch dir meine überzeugungen aufdrängen! -- ich finde es nur immer wieder recht schade, wenn derartige ganz grundsätzliche überlegungen bzw. entwicklungsmöglichkeiten in der praxis durch unnötig vereinfachenden zugangsweisen gar nicht erst als sinnvolle möglichkeit erkannt od. angedacht werden.
haltst es den wirklich für so viel zweckmäßiger, wenn man in dieser schonen neuen/simplen nett-2.0-welt für jede neue sich stellende aufgabe tatsächlich wieder ein neues programm benötigt und die dadurch gegeben vorgaben mehr oder weniger widerspruchslos hinzunehmen hat?
ich persönlich halte es hier wirklich für weit sinnvoller, wenn sich die leute ein klein wenig zusammenraufen und die bestehenden ansätze und frei verfügbaren produktionsmittel gemäß ihren ganz spezifischen bedürfnissen ständig noch ein klein wenig besser werden lassen!
deshalb auch mein verweis auf andere leistungsfähigere programme, die es auch für praktisch alle platformen in frei verfügbarer und einfachst zu installierenden bzw. zu erlernen versionen gibt, mit denen man durchaus auch einigermaßen effizient einen paar wörter und einen geraden strich über ein beliebiges bild drüberzusetzen vermag. (wobei ich durchaus nicht verschweigen möchte, dass ich natürlich auch z.b. am inkscape einiges auszusetzen habe oder für zumindest für höchst verbesserungswürdig erachte! -- nur scheint mir dort ein entsprechendes engagement zeiführender zu sein, als wenn jeder sein kleines suppchen kocht und das rad hundertmal neu erfunden wird!)
nun -- dann würde ich dir ganz dringend an herz legen, dass du die datei:
-rw-r--r-- 1 mash mash 18009 2003-10-09 23:28 PanoLab/LICENSE
wie sie sich im
-rw-r--r-- 1 mash mash 1800896 2007-04-28 14:05 PanoLab.jar
findet, dringend entfernen solltest -- um nicht versehentlich in konflikt mit irgendwelchem 'linken gesindel' zu geraten, wo man gerade in derartigen fragen relativ empfindsam zu reagieren pflegt
aber wie gesagt, auch ich finde es weiterhin höchst vorbildlich, dass du dich hier in dieser konstruktiven weise praktisch betätigst... es ist mir nur einfach ein gewisses bedürfniss, in dieser angelegeheit einmal das spektrum der möglichen sichtweisen und positionen hier im forum ein wenig zu erweitern.
liebe grüße
martin
lieber deconstruct,
ich danke dir natürlich für deine ausführliche reaktion und all die sachliche aufklärung bzgl. der angesprochen punkte. es geht mir ja mit meiner 'kritik' keineswegs darum, deine tatsächlichen leistungen zu mindern, sondern einfach nur deutlich herauszuarbeiten, worin sich meine persönliche unzufriedenheit mit der gegenwärtigen lösung gründet -- obwohl ich es natürlich genaus gut einfach dabei belassen könnte, still und heimlich für mich selbst zu beschließen, dieses programm gar nicht erst zu verwenden und daher alle damit verbunden debatten schlichtweg zu ignorieren.
zum gegenwärtigen format der der konfigurations-/daten-speicherung bzw. meiner charakterisierung als 'proprietäres' format:
Zitat von deconstruct
und um hier gleich auch noch ein paar weitere details anzusprechen, die mir beim entsprechenden studium relativ rasch ins auge gefallen sind, und möglicher weise im rahmen div. verbesserungsbemühungen berücksichtigt werden könnten, sei als anregung noch stichwortartig ergänzt:
- magic-cookies, um trotz der inflationär genutzten file-endung ".INI" eine klare zuordnung der benutzten daten zu gewährleisten.
- explizite angabe der programm- bzw. format-VERSION, um entsprechende änderungen beim einlesen berücksichtigen zu können.
- uneinheitlichkeit der delimiter ('|' vs '###') und evtl. sogar dadurch bedingte side-effects.
- nützlich wäre evtl. auch ein abspeichern der bildgröße in px-angaben, weil sich gerade das auffinden dieser werte u.u. bei späteren transformationen relativ umständlich gestalten kann.
- unter linux erfolgt das update der entsprechenden daten-änderungen offenbar tlw. erst beim schließen/beenden -- zusätzliches flush() od. close() könnte hier hilfreich sein um die entsprechenden JDK-eigeheiten auszubügeln...
trotzdem -- so schrecklich kompliziert ist das ganze im vorliegenden falle nun auch wieder nicht -- es geht mir hier vielmehr ganz prinzipiell darum, ob man diverse probleme nicht einfach gelich von grund auf vermeiden kann, wenn man den ganz allgemein sinnvollen maßstab der interoperabilität nicht völlig aus den augen verliert.
eine umstellung auf XML oder JSON bringt hier sicher gewisse vorteile mit sich, trotzdem hoffe ich, dass wir über derartige nebensächlichkeiten wirklich nicht lange streiten müssen!
was die rolle bzw. möglichkeiten und kompatibilität von SVG anbelangt, liegt die sache allerdings meiner ansicht nach nicht mehr ganz so einfach, wie du es hier darzustellst versuchst:
Zitat von deconstruct
wirklich spannend bzw. auch für die praktische anwendung von interesse wird die ganze sache hier aber gerade erst deshalb, weil sich auf diesem wege beschriftungen realisieren lassen, die das ursprüngliche vorliegende bild gar nicht erst antasten und verändern verändern müssen, sondern quasi wie eine darüber liegende transparente schicht (=overlay) zu beschriften vermögen(!), darüber hinaus aber auch in ihrer darstellung im web eine weitaus bessere optische umsetztung bieten (schriften und stark kontrastierende linien müssen in einem hoch komprmierten JPEG immer unangenehm überschwingen) und -- aber, da wird's dann vermutlich den meisten wieder ein wenig zu kompliziert -- durch die verwendung von CSS den darstellungsstil (bsp. schriftgöße...) von der ursprünglichen angabe der zuordnungspunkte weitestgehend lösen und einem später leicht abzuänderndem einheitlichen web-design überantworten, darüber hinaus aber auch noch von sich aus div. scriptbasierende interaktion vorsehen!
lauter dinge also, von denen ich doch denke, dass sie ganz deutlich über jenen status quo hinausweisen, den du hier so nachdrücklich zu verteidigen versuchst.
ich halte daher SVG weniger für ein zusätzliches feature, dass man ggf. noch zusätzlich über externe konverter etc. abdecken könnte, sondern vielmehr für eine höchst interessantes arbeits- und austauschformat, dass man höchstens mit rücksichtnahme auf veraltete webbrowsere u.ä. unter umständen durch parallele ausgabe in einem traditionellen pixmap-format als fall-back-lösung ergänzen sollte, prinzipell aber als absolut ideale und zukunftsweisende basis für ein derartiges projekt verstehen könnte.
trotzdem: weder will ich dich hier unnötig belehren, noch dir meine überzeugungen aufdrängen! -- ich finde es nur immer wieder recht schade, wenn derartige ganz grundsätzliche überlegungen bzw. entwicklungsmöglichkeiten in der praxis durch unnötig vereinfachenden zugangsweisen gar nicht erst als sinnvolle möglichkeit erkannt od. angedacht werden.
Zitat von deconstruct
ich persönlich halte es hier wirklich für weit sinnvoller, wenn sich die leute ein klein wenig zusammenraufen und die bestehenden ansätze und frei verfügbaren produktionsmittel gemäß ihren ganz spezifischen bedürfnissen ständig noch ein klein wenig besser werden lassen!
deshalb auch mein verweis auf andere leistungsfähigere programme, die es auch für praktisch alle platformen in frei verfügbarer und einfachst zu installierenden bzw. zu erlernen versionen gibt, mit denen man durchaus auch einigermaßen effizient einen paar wörter und einen geraden strich über ein beliebiges bild drüberzusetzen vermag. (wobei ich durchaus nicht verschweigen möchte, dass ich natürlich auch z.b. am inkscape einiges auszusetzen habe oder für zumindest für höchst verbesserungswürdig erachte! -- nur scheint mir dort ein entsprechendes engagement zeiführender zu sein, als wenn jeder sein kleines suppchen kocht und das rad hundertmal neu erfunden wird!)
Zitat von deconstruct
-rw-r--r-- 1 mash mash 18009 2003-10-09 23:28 PanoLab/LICENSE
wie sie sich im
-rw-r--r-- 1 mash mash 1800896 2007-04-28 14:05 PanoLab.jar
findet, dringend entfernen solltest -- um nicht versehentlich in konflikt mit irgendwelchem 'linken gesindel' zu geraten, wo man gerade in derartigen fragen relativ empfindsam zu reagieren pflegt
aber wie gesagt, auch ich finde es weiterhin höchst vorbildlich, dass du dich hier in dieser konstruktiven weise praktisch betätigst... es ist mir nur einfach ein gewisses bedürfniss, in dieser angelegeheit einmal das spektrum der möglichen sichtweisen und positionen hier im forum ein wenig zu erweitern.
liebe grüße
martin
Kommentar