FreePascal Text in Grafik

[andreas1234]

Danke für die Antworten
Im Quelltext finde ich leider weder "SetTextStyle" noch eine Zuweisung von Werten zu "CharArray[1]" bzw "CharArray" überhaupt, es kommen im Debugger allerdings unterschiedliche Größen dort an.

[wp_xyz]

Nachdem ich deinen Code-Ausschnitt nochmals angesehen habe, muss ich meine Antwort revidieren. Im BGI gab es damals nur ein paar Fonts, und schon gar keine mit Namen 'arial10.CHR', 'arial12.CHR', 'arial14.CHR'... Diese hier scheinen aufgrund ihres Namens tatsächlich jeweils für feste Schriftgrößen zuständig zu sein. Es könnte sogar sein, dass diese Fonts gar nichts mit dem BGI zu tun haben.

Was ist denn das für eine Bibliothek, in der diese Prozedur, NXLoadFont, vorkommt?

[andreas1234]

Danke für die Antwort.
Die Prozeduren die diese "NXLoadfont" Aufrufe machen heißen "NXInitFonts" und "NXReloadFont" und werden beim Aufbau der GUI durchlaufen. Es handelt sich dabei nicht um eine bekannte Bibliothek sondern ist vom Vorgänger, (der nicht mehr da ist) so Programmiert worden, die ganze GUI nutzt keine Formulare sondern "zeichnet" (und schreibt) per Koordinaten auf den Bildschirm. Ich denke da wurden damals einige Schriftarten mit Borland Pascal bzw BGI Tools in der benötigten Größe erstellt. Ich habe die Dateien auch gefunden kriege aber leider nichts lesbares zu sehen, wenn ich sie im Editor öffne und habe keine Version von BGI Tools für ein aktuelles Windows gefunden. Meine Hoffnung war man könnte für bestimmte Elemente die Größe nachträglich noch verändern.

[andreas1234]

Hallo nochmal, ich habe grade in der Prozedur "NXLoadFont" mal die Größen Zuweisung von den zu ändernden Texten ganz leicht abgeändert:

Code: Alles auswählen

with CharSet[pFont]^do begin
      if (pFont=12) then begin
          CharWidth := CharArray[0];
          CharHeight := CharArray[1]+1;
      end else begin
          CharWidth := CharArray[0];
          CharHeight := CharArray[1];
      end;

      CharBytes := (CharWidth-1) div 8 + 1;
      CharFactor := CharBytes*CharHeight+1;
      CharYOffset := pYOffset;
      Name := pFilename;
    end;

und bekomme daraufhin so eine Anzeige (Die gelbe Box erhält nun "CharHeight" +1 = 32 zugewiesen):

screen.png (43.31 KiB) 253 mal betrachtet

weise ich "CharHeight" 31 zu (Orginalgröße) sieht es so aus:

screen2.png (24.71 KiB) 253 mal betrachtet

Das sieht für mich nicht nach etwas größer sondern nach "total zerschossen" aus

[af0815]

Das zerschossen ist klar. Wenn man sich das Laden des Fonts ansieht, so ist in den ersten beiden Bytes die Höhe und Breite des umgewandelten Fonts hinterlegt. Stimmt die Umrechnung nicht mehr mit dem geladen Raster Daten überein, gibt es nur Müll. Und in deinem Beispiel überspringst du genau eine Bytes Grenze.

Mit einem Hexeditor, der auch binär darstellen kann, kann man sich die Daten ansehen. Mit einem normalen Editor geht da gar nichts.

Wenn du also die Schriftgrößen ändern willst, wirst du nicht umhin kommen, die CHR Dateien selbst zu erzeugen. So kompliziert scheint der Aufbau der Dateien nicht zu sein.

[andreas1234]

Danke für die Antwort und auch für den Hinweis mit der Bytegrenze.
Das es beim vergrößern Probleme geben kann mit der Darstellung habe ich mir schon gedacht, daher habe ich "nur" 1 Pixel vergrößert und auch ein paar Verkleinerungen mit 30, 23 und 8 Pixel versucht, die waren auch alle "zerschossen"...
Muss ich mir jetzt eine DOS Maschine aufsetzen, mir BGI Tools irgendwo besorgen und da versuchen den Schriftsatz in der CHR Datei zu vergrößern, oder gibt es noch eine einfachere Möglichkeit?
ps: Ich habe mir die CHR Datei mal mit einem Hex Editor angesehen und es bleibt leider kryptisch (egal ob ich ihn auf Windows ANSI oder DOS / IBM ASCII einstelle)

[wp_xyz]

Mir ist immer noch nicht klar, ob das überhaupt Fonts für das BGI sind. Wenn du keinen Hex-Editor hast, lade einmal einen in einen TextEditor, der Anfang der Datei ist lesbar. Im Screenshot siehst du das für den Original-Font Bold.CHR. Die ersten zwei Bytes sind der Text 'PK', es folgt zweimal #8#8, dann der Text 'BGI '. Der folgende Text könnte für nicht Borland-Fonts abweichen. Wichtig ist noch, dass anschließend irgendwo nochmal der Name der Font-Datei wiederholt wird (https://www.fileformat.info/format/borl ... corion.htm).

Nachdem die NX* Routinen selbst geschriebene Routinen sind, würde es vielleicht helfen, wenn du sie einfach hier mal hochlädst (vorausgesetzt, du darfst das): Einfach alle Routinen, deren Namen mit NX beginnt, in ein zip stecken und hier hochladen. Dann könnten wir feststellen, ob die Textausgabe überhaupt über das BGI geht.

[siro]

Beim stöbern auf meiner Platte habe ich grad diese Datei gefunden.
Evtl. hilft es weiter, wenn nicht einfach ignorieren..

Code: Alles auswählen

{ Copyright (c) 1985, 1990 by Borland International, Inc. }

program BgiLink;
{ This program demonstrates how to link graphics driver and font files
  into an EXE file. BGI graphic's drivers and fonts are kept in
  separate disk files so they may be dynamically loaded at runtime.
  However, sometimes it is preferable to place all auxiliary files
  directly into an .EXE. This program, along with its make file
  (BGILINK.MAK) and two units (BGIDRIV.PAS and BGIFONT.PAS) links all
  the drivers and fonts directly into BGILINK.EXE.

  Have these 3 programs in the current drive or directory, or
  have them available via a path (both are on Disk II):

    MAKE.EXE     - Make utility that will build BGILINK.EXE
    BINOBJ.EXE   - utility program to convert any file into an .OBJ file

  Place in the current drive or directory the following files (all
  are on Disk III):

    BGILINK.PAS  - this sample program
    BGIDRIV.PAS  - Pascal unit that will link in all BGI drivers
    BGIFONT.PAS    - Pascal unit that will link in all BGI fonts
    *.CHR        - BGI font files
    *.BGI        - BGI driver files
    BGILINK.MAK  - "make" file that builds BGIDRIV.TPU, BGIFONT.TPU, and
                   finally BGILINK.EXE

  DIRECTIONS:
  1. Run MAKE on the BGILINK.MAK file by typing the following command
     at a DOS prompt:

       make -fBGIlink.mak

     Using BINOBJ.EXE, this will first build .OBJ files out of the driver
     files (*.BGI) and then call Turbo Pascal to compile BGIDRIV.PAS.
     Next, the font files (*.CHR) will be converted to .OBJs and
     BGIFONT.PAS will be compiled. Finally, BGILINK.PAS will be compiled
     (it uses BGIDRIV.TPU and BGIFONT.TPU).

  2. Run BGILINK.EXE. It contains all the drivers and all the fonts, so it
     will run on any system with a graphics card supported by the Graph
     unit (CGA, EGA, EGA 64 K, EGA monochrome, Hercules monochrome,
     VGA, MCGA, IBM 3270 PC and AT&T 6400).

  EXPLANATION

    BGILINK.PAS uses BGIDRIV.TPU and BGIFONT.TPU in its uses statement:

      uses BGIDriv, BGIFont;

    Then, it "registers" the drivers it intends to use (in this case,
    all of them, so it will run on any graphics card). Then it registers
    all of the fonts it will use (again all of them, just for demonstration
    purposes) and finally it does some very modest graphics.

    You can easily modify BGILINK.PAS for your own use by commenting out
    the calls to RegisterBGIdriver and RegisterBGIfont for drivers and
    fonts that your program doesn't use.

    For a detailed explanation of registering and linking drivers and fonts,
    refer to the RegisterBGIdriver and RegisterBGIfont descriptions in
    GRAPH.DOC (on Disk III).
}

uses Graph,     { library of graphics routines }
     BGIDriv,   { all the BGI drivers }
     BGIFont;   { all the BGI fonts }
var
  GraphDriver, GraphMode, Error : integer;

procedure Abort(Msg : string);
begin
  Writeln(Msg, ': ', GraphErrorMsg(GraphResult));
  Halt(1);
end;

begin
  { Register all the drivers }
  if RegisterBGIdriver(@CGADriverProc) < 0 then
    Abort('CGA');
  if RegisterBGIdriver(@EGAVGADriverProc) < 0 then
    Abort('EGA/VGA');
  if RegisterBGIdriver(@HercDriverProc) < 0 then
    Abort('Herc');
  if RegisterBGIdriver(@ATTDriverProc) < 0 then
    Abort('AT&T');
  if RegisterBGIdriver(@PC3270DriverProc) < 0 then
    Abort('PC 3270');


  { Register all the fonts }
  if RegisterBGIfont(@GothicFontProc) < 0 then
    Abort('Gothic');
  if RegisterBGIfont(@SansSerifFontProc) < 0 then
    Abort('SansSerif');
  if RegisterBGIfont(@SmallFontProc) < 0 then
    Abort('Small');
  if RegisterBGIfont(@TriplexFontProc) < 0 then
    Abort('Triplex');

  GraphDriver := Detect;                  { autodetect the hardware }
  InitGraph(GraphDriver, GraphMode, '');  { activate graphics }
  if GraphResult <> grOk then             { any errors? }
  begin
    Writeln('Graphics init error: ', GraphErrorMsg(GraphDriver));
    Halt(1);
  end;

  MoveTo(5, 5);
  OutText('Drivers and fonts were ');
  MoveTo(5, 20);
  SetTextStyle(GothicFont, HorizDir, 4);
  OutText('Built ');
  SetTextStyle(SmallFont, HorizDir, 4);
  OutText('into ');
  SetTextStyle(TriplexFont, HorizDir, 4);
  OutText('EXE ');
  SetTextStyle(SansSerifFont, HorizDir, 4);
  OutText('file!');
  Rectangle(0, 0, GetX, GetY + TextHeight('file!') + 1);
  Readln;
  CloseGraph;
end.

[af0815]

Mir ist immer noch nicht klar, ob das überhaupt Fonts für das BGI sind.

Das sind keine BGI Fonts, sondern einfach gespeichertes array der Pixeldaten. Der Header mit 2 Bytes, fertig. Sowas war unter TP beliebt, da man ja am Anfang im Grafikmodus selbst oft was zeichnen musste. So brauchte man nur richtig in den Grafikspeicher kopieren. Ich würde jetzt nicht soviel auf die Endung chr geben.

Ich habe mich bei meinen ersten Programmen mit TP 3.0 auch mit solchen Sachen herumschlagen dürfen.

Wäre interessant eine der chr Dateien mal zu bekommen. Ev. per PN.

[andreas1234]

Ich habe mir die Datei mit HxD angesehen und bekomme je nach Einstellung ANSI oder ASCII folgende Ansichten:

HXD1.png (143.4 KiB) 221 mal betrachtet

HXD2.png (154.09 KiB) 221 mal betrachtet

Das geht dann die nächsten Seiten so weiter, lesbaren Text habe ich da nicht entdeckt, bin mir aber nicht sicher ob HxD ein geeigneter Hex Editor ist, den hatte ich hier auf dem Arbeitsrechner schon vorinstalliert...
Das ganze Projekt hochladen darf ich wohl eher nicht und wäre auch sehr komplex, aber die CHR Datei hänge ich mal an, vielleicht kann sich das ja noch jemand mit BGI Tools oder was anderem anschauen:

lucid22.7z

(3.32 KiB) 19-mal heruntergeladen

[af0815]

Danke für die Datei. Hier ein schneller Betrachter für die Datei.

Ich bin mir bei der decodierung noch nicht ganz klar wie die Bytes einer Zeile ineinander verwoben sind. Aber als Start für eine Anzeige sollte es mal reichen. Weil, wenn man das Prinzip verstanden hat, so kann man auch den umgekehrten Weg gehen.
BTW: Die lucid22.chr muss man natürlich ins Verzeichnis kopieren oder den Pfad/Dateinamen anpassen.

EDIT: Programm erweitert

[andreas1234]

Vielen Dank für die Mühe,
mit dem Betrachter sieht man jetzt (denke ich) Teile von Zeichen (hat Ähnlichkeit mit ASCII-Arts),
aber wie ich da jetzt die Größe der Zeichen geändert kriegen soll weis ich leider nicht.
Ich frage mich ob das überhaupt möglich ist für jemand anderen wie den ursprünglichen Entwickler.
Ist das den jetzt eigentlich eine richtige CHR Datei oder ist sie blos so benannt worden?

[wp_xyz]

Ist das den jetzt eigentlich eine richtige CHR Datei?

Nein.

Vielleicht kann man mit einem der in FPC/Lazarus enthaltenen FreeType-Renderern die Pixel-Matrizen erzeugen. Nur müsste man genau über den Aufbau dieser Font-Dateien bescheid wissen. Ist die Textausgabe auch von deinem Vorgänger geschrieben? Dann suche die Routine, in der ein Zeichen dargestellt wird. Umgekehrt kann man daraus vielleicht ableiten, wie die Datei aufzubauen ist.

[af0815]

Nachdem ich bereits mit TP 3.0 Programme erstellt habe, habe ich ähnliche Probleme gehabt. In den produktiven Code kann man relativ wenig hineinpacken ohne gleich an die Speichergrenzen zu kommen, bzw. das das Programm nicht allzuviel Performance verliert. Hat man heute nicht unbedingt, außer man arbeitet auf Microcontrollern.

Ich frage mich ob das überhaupt möglich ist für jemand anderen wie den ursprünglichen Entwickler.
Ist das den jetzt eigentlich eine richtige CHR Datei oder ist sie blos so benannt worden?

Meiner Meinung nach ist das keine richtige CHR Datei. Sondern ein gespeichertes Rasterimage der Buchstaben.

Wenn das Programm mit dem decodieren richtig funktioniert, so kann man sich an das Erstellen eigener (fake) CHR Dateien machen, die man dann auf die richtige Größe skalieren kann. Ja es ist somit möglich die Zeichengröße zu ändern, nur ist der Aufwand dahinter das erste Mal recht groß. Ich gehe davon aus, das der Entwickler ein Tool gehabt hat (oder sich selbst geschrieben) wo er Zeichensätze in seiner richtigen Größe in eine solche fixe Darstellung gebracht hat.

Bei so alten Code würde ich die Eingriffe nur minimalinvarsiv machen, alles andere öffnet, meiner Meinung nach, nur die Büchse der Pandora.

Und ja, es ist immer gut, auch solchen alten Code in ein GIT Repository zu legen, weil dann kann man bei Änderungen sich immer ansehen, was gemacht wurde.

[af0815]

Umgekehrt kann man daraus vielleicht ableiten, wie die Datei aufzubauen ist.

Die Datei ist relativ einfach aufgebaut. 2 Bytes Header und dannach direkt die Rasterdaten. Siehe auch in den Q&D Beispiel.

EDIT:
Beispiel ist erweitert. Und auch die Reihenfolge der Bytes ist jetzt gefixt. Neuer Download.
Aufbau ist nicht allzu kompliziert.

Screenshot 2025-09-12 163958.png (26.42 KiB) 182 mal betrachtet

In den ersten Bytes gibt es IMHO 2 Marker, der erste sagt wo das Zeichen aufhört, der zweite ist vermutlich für den Abstand zum nächsten Zeichen.