burn-Plugin: korrigiert: Überlänge mancher Menüzeilen (neue wrap_text)

Damit es nicht in der allgemeinen Diskussion zum Plugin-Patchen unter Ubuntu off-topic wird, mache ich hier mal einen eigenen Thread zum in http://vdr-portal.de/board/thr…?postid=802254#post802254 beschriebenen verbliebenen burn-Problem auf (siehe dort info.vdr zum Reproduzieren):
[Blockierte Grafik: http://vdr-portal.de/board/attachment.php?attachmentid=21579]

Die Zeilenerstellung (wohl in wrap_text von gdwrapper.c) scheint noch einen Bug zu haben.

Ich habe mal Logger für ein paar Variablen in den Sourcecode gepanscht, die (wie im beiliegenden Protokoll zu sehen) zeigen, daß noch ein append übernommen wird, auch wenn damit lineWidth>width wird (siehe Vorkommen von 595 bzw. 481) - wo der String eigentlich spätestens beim vorangehenden Leerzeichen hätte beendet werden müssen. Bei der Titelzeile sollten im Idealfall auch vor dem Wort stehende delimiters.find( *pos ) abgeschnitten werden (außer vielleicht ! und ?), damit diese nicht z.B. auf einen Bindestrich endet...

The Source, Luke! ab Zeile 88.

Sieht einer der anwesenden C-Gurus hier schneller eine Lösung?

gdwrapper.c habe ich mit ein paar Loggern gepanscht http://rafb.net/p/DL0MSX75.html, so daß man in Zeilen 93 und 306 von http://rafb.net/p/AVwYvP65.html genau sehen kann, wo wrap_text (Zeilen 142 bis 162) wegen lineWidth > width zu lange Ergebnisse liefert.
Weiß jemand einen Weg, ihm das auszutreiben?

Um mich in die Plugin-Entwicklung in C++ auf die denkbar schwierigste Art einzuarbeiten und weil sich leider niemand sonst darum kümmern konnte (während ich keinen Weg gefunden habe, dem alten Code die zu überlangen Zeilen führenden Fehler auszutreiben), habe ich den größten Teil von wrap_text aus gdwrapper.c neu und hoffentlich verständlich implementiert, dabei aber soweit möglich die gewohnten Bezeichner (wenn auch z.T. mit etwas veränderter Funktion) weiterverwendet.

string image::wrap_text( int width, int& lineHeight, const string& text, const font_spec& font )
	{
		static const string delimiters( " -_" );

		const string fontPath( setup::get_font_path() + "/" + font.face + ".ttf" );
		string result;
		string oldresult;
		string::const_iterator thisLine = text.begin();
		lineHeight = 0;

		for ( string::const_iterator pos = text.begin(); pos < text.end(); ++pos ) {
			if ( (delimiters.find( *pos ) == string::npos) && (pos+1 < text.end() ) ) {
				result += *pos;
			}
			else {
				string sample( thisLine, pos );
				string::const_iterator nextpos = pos;
				sample += *nextpos;
				++nextpos;
				while ( (delimiters.find( *nextpos ) == string::npos) && (nextpos < text.end()) ) {
					sample += *nextpos;
					++nextpos;
				}
				int bounds[8];
				const char* error = gdImageStringFT( 0, bounds, 0, const_cast<char*>( fontPath.c_str() ), font.size, 0, 0, 0,
												 const_cast<char*>( sample.c_str() ) );
				if (error != 0) {
					string message( error );
					if ( message == "Could not find/open font" )
						message += " " + fontPath;
					logger::error( format( "Couldn't render text: {0}" ) % message, false );
					throw user_exception( tr("Couldn't render menu images!") );
				}
				int currentLineHeight = bounds[3] - bounds[5];
				if (currentLineHeight > lineHeight)
					lineHeight = currentLineHeight;
				int lineWidth = bounds[2] - bounds[0];
				if (lineWidth>width) 
					if (pos+1 == text.end() )
						result = oldresult;
					else {
						result += "\n";
						thisLine = pos+1;
						if (*pos != ' ')
							result += *pos;
					     }
				else {
					oldresult = sample;
	  				result += *pos;
				}
			}				
		}
		return result;
	}

Noch nicht getestet wurde es mit weiteren Fremdsprachen, und evtl. lässt die Position des Auswahlcursors gegenüber dem Text noch an einigen Stellen um wenige Pixel optimieren, sowie durch einen umlaufenden schwartzen Rand bei der Schrift die Lesbarkeit auch auf
hellen Hintergründen verbessern - freue mich über Vorschläge mit Code und "Zielfoto"... [Blockierte Grafik: http://vdr-portal.de/board/attachment.php?attachmentid=21630]
Nun bin ich natürlich gespannt, welche Fehler und Verbesserungsmöglichkeiten Ihr mir aufzeigt!

Zitat

Originally posted by FireFly
ich finde es sehr gut, dass endlich mal jemand dieses Problem angegangen ist. Ich habe mal ein diff daraus gemacht, aber leider funktioniert der Patch nicht: ich habe jetzt immer doppelten Zeilenabstand
Hast Du evtl. in einer anderen Funktion noch etwas geändert? Kannst Du mal ein diff zum Standard-gdwrapper.c machen? Oder woran könnte das sonst liegen?

Das liegt am in der Beschreibungszeile der info.vdr für zusätzliche Zeilenumbrüche genutzten |-Zeichen ("Pipe") - hatte ich unter http://vdr-portal.de/board/thr…?postid=809576#post809576 schon gepostet: ersetze das mal in der info.vdr probeweise durch ein Leerzeichen: | wird wohl noch an irgendeiner anderen Stelle des burn-Plugins verarbeitet und das ist dann doppelt.
Wollte schon die neue wrap_text-Schleife um eine Sonderbehandlung dafür ergänzen, war aber leider zu wenig am System&habe auch Lordschaft nicht erreicht - vielleicht kannst Du etwas Passendes einbauen?

Zitat

Originally posted by FireFly
Ich habe mal in einen Text (info.vdr) ohne Pipe-Umbrüche ein einzelnes Pipe-Zeichen eingebaut - und prompt habe ich zweiligen Abstand wie im Bild zu sehen. Ohne Pipe ist es ok.

Was machen denn lineHeight und currentLineHeight? Die habe ich mir schon mal ausgeben lasse, verstehe aber nicht so ganz deren Sinn, weil erst pendeln deren Wete um 18-22 und plötzlich schießen sie auf 45...

An der Stelle konnte ich leider auch nur lordjaxoms Verwendung der Rückgabewerte von gdImageStringFT übernehmen, da mir mangels C-Erfahrung auch keine andere Debugging-Möglichkeit als die Ausgabe einzelner Werte über den Error-Logger zur Verfügung steht.
Könnte es sein, daß das "|" schon in dieser externen Funktion irgendwie interpretiert wird?
Ein "grep" über die Sourcen hat mir nämlich keinen Anhaltspunkt für seine weitere Berücksichtigung geliefert...
Ursprünglich war es mir leider in ein paar durchhackten Nächten gar nicht aufgefallen, da nur manche Sender Zeilenumbrüche in den EPG-Beschreibungen verwenden und damit "Pipes" in der D-Zeile von info.vdr haben.

Spezialitäten für | werden AFAICS allerdings weder in der offiziellen GD-Doku http://www.boutell.com/gd/manual2.0.1.html#gdImageStringFT noch z.B. in http://linuxgazette.net/issue91/shuveb.html erwähnt.

Okay, also wird | wohl tatsächlich nicht mehr in burn berücksichtigt (die wegen Zeilen 35+36 gestiegene currentLineHeight erklärt dann auch, warum die folgenden Zeilen ebenfalls einen Umbruch zuviel zu haben scheinen) und deswegen liefen meine Versuche dazu ins Leere:
Dann müssen wir nur obige Zeilen 38 und 44 jeweils um ein OR ergänzen:
*pos == '\n' darf dann eben auch nicht sein, dann sollte es gehen:
Zeile 38 bricht dann bei *pos == '\n' wie bei Überlänge um,
Mit zusätzlichem if *pos != '\n' in Zeile 44 hängt Zeile 45 kein weiteres \n an, wo dann ja schon der VDR selbst eines eingefügt hat.
Mir zu spät für make, aber das sollte dann klappen - danke für's Ausprobieren!

P.S.: lineHeight habe ich IIRC gar nicht weiter verwendet, wird aber wohl als Rückgabewert gebraucht.

Und natürlich müssen wir dafür sorgen, daß der String vor Aufruf von gdImageStringFT aus wrap_text um das \n gekürzt wird, damit nur die Höhe der höchsten Einzelzeile ohne Umbruch zurückgegeben wird.

P.S.: Du hast wahrscheinlich die geänderten Koordinaten für den Textrahmen noch nicht alle übernommen.
Die Koordinaten für den Auswahlcursor könnten noch um ein paar Pixel verbessert werden, auch wenn dort ein gelegentlicher kleiner Versatz nicht weiter stört.

Die Änderungen, damit der Text nicht über die Rahmen hinaus oder verschoben in diesen erscheint, stecken momentan in http://launchpadlibrarian.net/24628642/99_ten.fullfix.tar.gz (debian/patches/99_ten.dpatch ist das diff, IIRC zur vdr-plugin-burn-0.1.0~pre21/setup.c) - lordjaxom wollte sie übernehmen, sobald er dazu kommt, da sich irgendwann wieder die alten, "schiefen" Werte eingeschlichen hatten, die eigentlich schon in burn-0.0.9-TEN/burn-0.0.10 korrigiert worden waren.

Zitat

Originally posted by FireFly
Meine "grep's" haben mir gezeigt, dass die Description direkt vom VDR kommen über die Funktion Info()->Description() in config.c des burn-Plugins. Vermutlich übersetzt der VDR also schon das "|" in "\n" zurück; auch die fehlende Sonderbehandlung in meinem Skin spricht dafür, dass das im VDR gemacht wird (mach ja auch Sinn ;D).

Ich ergänze die Beschreibung öfters, gerade wenn es um Fileme geht, die ich evtl. archivieren möchte. Da mache ich dann öfters davon Gebrauch und mit Absätzen kann man die längeren Texte etwas besser strukturieren.

Ich gehe davon aus, dass currentLineHeight dann plötzlich größer wird, wenn ein Umbruch ("\n") festgestellt wird.

Habe das mal wie besprochen aufgebohrt - kann aber sicher noch optimiert werden, vor allem darauf, daß mehrere |s z.B. in Deinen info.vdrs auftauchen können, also gerne testen.

string image::wrap_text( int width, int& lineHeight, const string& text, const font_spec& font )
	// rewritten by TEN 2009-03-22 fixing http://vdr-portal.de/board/thread.php?threadid=85412
	{ 
		static const string delimiters( " -_" );

		const string fontPath( setup::get_font_path() + "/" + font.face + ".ttf" );
		string result;
		string oldresult;
		string::const_iterator thisLine = text.begin();
		lineHeight = 0;

		for ( string::const_iterator pos = text.begin(); pos < text.end(); ++pos ) {
			if ( (delimiters.find( *pos ) == string::npos) && (pos+1 < text.end() ) ) {
				result += *pos;
			}
			else {
				string sample( thisLine, pos );
				string::const_iterator nextpos = pos;
				sample += *nextpos;
				++nextpos;
				while ( (delimiters.find( *nextpos ) == string::npos) && (nextpos < text.end()) ) {
					sample += *nextpos;
					++nextpos;
				}
				int bounds[8];
				const char* error = gdImageStringFT( 0, bounds, 0, const_cast<char*>( fontPath.c_str() ), font.size, 0, 0, 0,
												 const_cast<char*>( sample.c_str() ) );
				if (error != 0) {
					string message( error );
					if ( message == "Could not find/open font" )
						message += " " + fontPath;
					logger::error( format( "Couldn't render text: {0}" ) % message, false );
					throw user_exception( tr("Couldn't render menu images!") );
				}
				int currentLineHeight = bounds[3] - bounds[5];
				if ((currentLineHeight > lineHeight) && (currentLineHeight < 40)) /* kludge to avoid having to eliminate trailing \n */
					lineHeight = currentLineHeight;
				int lineWidth = bounds[2] - bounds[0];
				if ( (lineWidth>width) || (*pos == '\n') ) /* VDR itself will already have replaced | by \n (as FireFly pointed out) */
					if (pos+1 == text.end() )
						result = oldresult;
					else {
						result += "\n";
						thisLine = pos+1;
						if ( !((*pos == ' ') || (*pos == '\n')) ) /* don't double line break */
							result += *pos;
					     }
				else {
					oldresult = sample;
	  				result += *pos;
				}
			}				
		}
		return result;
	}

Die saubere Lösung wäre natürlich, in Zeile 36 nicht einfach auf (currentLineHeight < 40) zu testen, sondern den letzten Operanden irgendwo vorab einmalig mit Anwendung von gdImageStringFT auf (nur) " \n" zu kalibrieren - aber da will ich Ihro Lordschaft von und zu Jaxom nichts an anderer Stelle in den Code murksen...:whatever

Und | am Ende von Zeile 4 ist natürlich überflüssig, da es wie von FireFly herausgefunden ja nie in der Eingabe auftreten kann (VDR selbst hat es dann jeweils schon zu \n umgeschrieben).

FireFly: Hoffe mit den Änderungen funktioniert es auch für alle Deiner "handoptimierten" info.vdrs?
Bzgl. Layout siehst Du ja, wie der Text nun schön mit gleichmäßigen Abständen in die Rahmen passt - da hatte es wohl eine Regression auf schon in der Entwicklungslinie 0.0.9+ gefixte Bugs gegeben.

Wenn alles passt, findet LordJaxom hoffentlich demnächst Gelegenheit, die Änderungen "offiziell" in vdr-plugin-burn zu übernehmen - sonst bleiben sie in https://bugs.launchpad.net/ubu…r-plugin-burn/+bug/226072 usw. wohl leider liegen.

Zitat

Originally posted by FireFly
ich bin dem Fehler im wrap_text seiner Lordschaft auf der Spur Konkret heißt das, dass es mit meinen info.vdr's und Deiner o.a. info.vdr funktioniert. Ich muss aber noch ein paar Sachen checken, bevor ich einen Patch machen kann.

Klang zuletzt im IRC nicht so, als ob er besonders an seiner (längeren, aufwendigeren) Version von wrap_text hängt - die war nicht mehr sonderlich verständlich oder wartbar.
So gesehen, wenn obige geht, nehmen wir sie halt.

Zitat

Die Änderung an der Größe des Textbereichs aus dem genannten Patch begreife ich aber nicht: da wird der Bereich ja deutlich kleiner gemacht?

Nein, die Zeilenhöhe wächst nur maximal bis 39. Eigentlich sollte man nicht 40 in den Code schreiben, sondern eine (Global-)Variable, die mit der für "\n" ermittelten lineHeight initialisiert wurde.

Oder meinst Du die Koordinaten der Begrenzungslinien in den Hintergrundbildern?
Da war in der Tat die Überschriftenzeile zu kurz, aber die Beschreibung etwas zu breit. An den Bildern siehst Du ja, wie es jetzt gleichmäßig in die bei den meisten Hintergründen sehr ausgeprägten Rahmen passt.

Zitat

ich fürchte eher, dass das burn-Plugin auch tot ist, weil trotz etlichen Patches ewig keine neue (Pre-)Release rausgekommen ist

Na ja, er wollte zumindest die Änderungen einpflegen, mit denen es bei Ubuntu wieder funktionsfähig wurde.