Wie stellt ihr sicher, dass Untertitel nicht aus dem Bild laufen?

  • Ich schreibe Untertitel oft selbst mit Aegisub. Dabei gibt es natürlich das Problem, dass eine Zeile nicht zu lang sein darf. Da die Schriftgrösse im Videobild aber nicht mit der von DVDLab oder meinem Popcorn Hour Mediaplayer übereinstimmt, mache ich die Endkontrolle mit Windows Notepad. (SRT-Datei)


    Ich kontrolliere das immer in dem ich mir eine Dummy-Zeile gespeichert habe, die gerade noch auf den Schirm passt und alles andere muss eben kürzer oder höchstens gleichlang sein. (bei gleicher Schriftart und Grösse versteht sich) Nun stelle ich mir den Rand des Notepads auf diese Zeile ein und kontrolliere ob alle anderen Zeilen nicht aus dem Bild wandern.
    Kennt ihr ne bessere Möglichkeit? Es wäre schön, wenn Aegisub schon beim schreiben der Untertitel mir im Vorschaufenster anzeigen würde was aus dem Bild läuft aber wie gesagt, das passt dort nicht.

  • MaestroSBT geht schon in die Richtung aber ich brauche als Endergebnis eine SRT-Datei und keine Bildtafeln. Gibt es denn nix was so ungefähr arbeitet wie der VSFilter oder VLC-Player? Also ich gebe ihm Schriftart und Grösse vor und er macht selbstständig einen Zeilenumbruch in die SRT-Datei.

  • Nochmal zum Thema:

    Es hat mir keine Ruhe gelassen und ich habe die Breite, die die Zeilen maximal breit sein dürfen einfach mal gemessen.

    Gemessen: in dem ich mit FreePascal eine Testzeile auf den Canvas ausgebe und dann die Breite bei meiner Schriftart und Größe messe mittels einer Freepascal Pixel-Funktion.



    Meine Werte sind:

    z.B. Tahoma, 24, fett

    "Testzeile, genau so lang darf sie breit sein......."


    Ergibt z.B. 740 px


    Jetzt lasse ich jede Zeile meiner SRT-Datei auf ihre Breite durchtesten und falls sie 740px überschreitet wird der Untertitel-Item neu "sortiert". (neuer Zeilenumbruch)

    Das ganze ist nun ein FreePascal-Tool geworden, was genau das macht, was ich brauche.

    So stelle ich sicher, dass alles im Rahmen bleibt und auch DVD-Programme nichts mehr aus dem Rand laufen lassen oder Zeilenumbrüche auftauchen wo ich gar keine gesetzt habe.

  • Scheint mir auch der einzig vernünftige Ansatzpunkt zu sein: Erst beim Rendern in einem speziellen Font kann man dessen spezifischen Platzbedarf ermitteln. Und nein, Ligaturen erwähne ich besser gar nicht erst...


    Ich vermute mal, in PHP mit GD2 würde man das auch schaffen.

  • Mein Programm ist nun fertig aber eine Sache ist mir aufgefallen. Editoren unterscheiden sich wie sie eine Schriftart darstellen abhängig von der Größe.

    Ich meine Folgendes:


    Ich habe folgende zwei Zeilen.


    Eins zwei drei vier fünf sechs sieben acht neun

    ...........................................................................





    Bei Word, Libreoffice, Aegisub, Tmpgenc Authoring Works, Google Docs und bei der Schriftart "Tahoma" fett (Schriftgröße egal) wird sie so dargestellt, dass Punkte und die obere Zeile genau gleich lang sind. Fast bis aufs Pixel genau. (und wie gesagt: egal bei welcher Schriftgröße von 12-38)






    Dann aber "Windows Notepad" und mein PascalTool mit dem Canvas oder der TMemo.Box stellt das Verhältnis der Zeilen bei jeder Schriftgröße anders dar. Manchmal sind die Punkte kürzer als die obere Zeile. Manchmal sind die Punkte länger als die obere Zeile. Manchmal sind sie genau gleich lang.





    Woran könnte das liegen? Ich kenne mich mit Schriftarten nicht so aus. Ich möchte schon, dass mein Tool irgendwann so arbeitet, dass die Zeilen genau gleichlang sind. Genau wie es bei Word/Aegisub und anderen Tools ist. Denn die sind die Referenz.

  • Man kann Outline-Schriftarten (TrueType, OpenType, PostScript) auf unterschiedliche Art rendern: Mit oder ohne Antialiasing (was bei DVD-Untertiteln mit nur max. 4 Palettenfarben problematisch ist), mit oder ohne Hinting (Hinweise zu Abständen zwischen speziellen Paaren von Buchstaben und zur Ausrichtung an Pixelgrenzen werden beachtet oder nicht), mit einer festen ganzzahligen Pixel-Breite pro Zeichen (das tun simple Textsysteme) oder höherer Genauigkeit in "Punkt" für die komplette Zeile (das tun Satzsysteme für professionellen Druck).


    Es überrascht mich, dass Aegisub ebenso präzise wie eine Textverarbeitung arbeitet.

  • Bei Subtitle Edit kann man ja UTs als sub/idx exportieren.


    https://www.nikse.dk/SubtitleEdit/Help#export


    und dort kann man einstellen "simple rendering" oder nicht. Genau der Haken bewirkt den selben Effekt. Einmal sind die Punkte unterschiedlich lang und einmal sind beide Zeilen identisch lang. Jetzt müsste ich nur wissen was der Haken da macht.

    Antialiasing hat keinen Einfluss auf die Zeilenbreite.

  • BGRABitmap tutorial Font rendering – hier finde ich v.a. dieses Kapitel interessant:


    Using fonts with LazFreeType integrated in Lazarus


    und dabei diese Stelle: bmp.FontQuality := fqFineClearTypeRGB; – denn ClearType sorgt u.a. auch für das Hinting, allerdings wird Sub-Pixel-Antialiasing dir nicht helfen, weil es Pixel an den Rändern rötlich oder bläulich färbt. Vielleicht gibt es da eine Möglichkeit, das Antialiasing monochrom zu halten und zu reduzieren. Aber das greift schon tief in die Optionen von ClearType ein.


    Also lies dich mal ein, welche Konstanten es für dieses Attribut noch gibt, und welche weiteren Steuerfunktionen für das Font-Rendering man noch finden kann.

  • Meine Idee ist: Was passiert, wenn du statt fqFineClearTypeRGB eine andere Konstante an bmp.FontQuality zuweist? Da wirst du erstmal herausfinden müssen, welche es sonst noch gibt, und was die im einzelnen bedeuten. Und vielleicht findest du dabei noch einen Guide, der das mit Zoom-Bildchen vergleicht?

  • Ausser der fqFineClearTypeRGB und fqFineAntialiasing hat .FontQuality keine vernünftigen Optionen mehr. Und beides erzeugt haargenau die selben Zeilenbreiten. Aber es ist natürlich viel besser als ohne die Optionen.

    Ich messe bei allen Schriftgrößen die Differenz der Zeilenlängen und mit den Optionen liege ich bei maximal 10 Pixel Unterschied.

    ohne die Optionen liegen die Zeilen oft >40 Pixel auseinander. Also der richtige Weg aber leider nicht so schön wie Word. Denn da ist kaum ein Unterschied zu erkennen.

  • Nun, wie angedeutet: Es wird wohl daran liegen, dass hochwertige Textverarbeitungen mit einer Präzision rechnen, die der Einheit "Punkt" in der Drucktechnik (1/72 Zoll) entspricht, also feiner als Bildpixel. Von einem freien PDF-Renderer für PHP (FPDF / TCPDF und einige weitere Forks) kenne ich das auch. Warum Aegisub das anscheinend auch tut, und vor allem wie (vielleicht indem einfach möglichst lange mit Fließkomma gerechnet wird), wird man aber wohl nur durch Studium seiner Quelltexte herausfinden, falls die öffentlich sind.