Opened 4 years ago

Closed 19 months ago

Last modified 17 months ago

#36 closed defect (fixed)

use SDL TTF without needing X Windows

Reported by: paul.wratt Owned by: PulkoMandy
Priority: major Milestone: 2.6
Component: GrafX2 Version: 2.4
Keywords: TTF fonts Cc:

Description

this is a fix that unbinds Grafx2 from X Windows (on Linux/Unix?), allowing console use of any font SDL_TTF can read (not just TTF)

The original code locks in the use of X Windows by querying the fontpath array, however nowadays "built-ins" is the primary and cant be resolved without further coding.

Solution, provide a directory tree iterator that is fed a path where fonts are know to live in common Nix distributions (Solaris, Debian, etc)

provided here are the two (2) modified files, and a 3rd that dumps your X Windows FontPath? array (from a console under X Windows).

The principle of the modifications basically search the entire tree "one-up" from what is shown for fontpath, which (mostly) by default will be your actual root font folder (eg /usr/share/font instead of only /usr/share/font/ttf/cyrillic)

SDL_TTF can read and render TTF, OTF, BDF, PCF, Windows FON plus others. This needs to be further researched so "Add_font()" can be updated to ALL formats, not just the common ones. A user provided fontpath supplied on the command line should be added to the array as well.

The result allows use of TTF (and other) under console and X Windows

NOTE: the default path currently set for Atari ST systems is non-standard, more commonly found in C:\GEMSYS\FONTS or C:\GEMSYS\TTF or similar. Use of SDL_TTF and an FontPath? Array with an additional command line option would assist a default installation without need for source changes/edits.

Attachments (4)

text.c (17.9 KB) - added by paul.wratt 4 years ago.
Adds USE_XLIB in Init_text() to allow X Windows only or "both" when compiled
io.c (15.1 KB) - added by paul.wratt 4 years ago.
Adds For_each_font_in_tree() (needs to be declared in io.h too), calls Add_font() in text.c
find_X11_fontpaths.cpp (657 bytes) - added by paul.wratt 4 years ago.
outputs FontPath? as found in "xset q" output, /usr/share/font == "built-ins" on Debian
noX11.patch (6.2 KB) - added by pulkomandy 4 years ago.

Download all attachments as: .zip

Change History (17)

Changed 4 years ago by paul.wratt

Attachment: text.c added

Adds USE_XLIB in Init_text() to allow X Windows only or "both" when compiled

Changed 4 years ago by paul.wratt

Attachment: io.c added

Adds For_each_font_in_tree() (needs to be declared in io.h too), calls Add_font() in text.c

Changed 4 years ago by paul.wratt

Attachment: find_X11_fontpaths.cpp added

outputs FontPath? as found in "xset q" output, /usr/share/font == "built-ins" on Debian

Changed 4 years ago by pulkomandy

Attachment: noX11.patch added

comment:1 Changed 4 years ago by pulkomandy

Hi,
Which version of the code did you base your changes on?

I generated a patch from your files against the current source tree, and I see several problems:

  • Some Android and GCW-Zero specific parts are removed (but we can re-add these),
  • More annoyingly, in the current sources, the X11 specific code had already been removed to use fontconfig instead. This change was made back in 2013: http://pulkomandy.tk/projects/GrafX2/changeset/2050

I would prefer to keep fontconfig at least as an option, instead of using hardcoded paths.

comment:2 Changed 3 years ago by Paul Wratt

it think it was: grafx2-2.4.2035-src.tgz

I wanted to use a later on, 2037 nokturnal, but the source was not in the zip

Last edited 3 years ago by Paul Wratt (previous) (diff)

comment:3 Changed 3 years ago by Paul Wratt

NOTE: on X fonts and 'fontconfig'

some time ago the internals where renamed, so there is a 'built-ins' used internally in fontconfig, which it maps to what ever path is default for the OS (Debian/Raspbian? its /usr/share/fonts). But there is no way to query what that is. I also believe some font type that SDL_TTF can read which are no longer supported by X Font system. ATM the code scraps the folders for known font formats, but there is no way to scrap 'built-ins', and unlike SDL2, SDL 1.2 handles a lot of older screen based fonts..

Also, as far as I know, fontconfig is bound to X. That is to say, if you install 'fontconfig' it will install X. My fix, although not pretty does unbind Grafx2 from X. There is notes about 'default' font paths in the attached files.

The lack of fontconfig support does not stop any fonts from being used on X, as 'built-ins' is different on may (not all) systems, and some builds (Atari ST) already don't use it.

You really need to add either a global variable check or a command line option (or both) so that Grafix2 can then add that path to the font directory list

Currently for an Atari ST build the path is hard coded, and that path is also not a common one. Especially on an Atari ST, the default fontpath can be (literally) anywhere, even if you are lucky enough to have a working X Windows setup (and hence fontconfig).

Last edited 3 years ago by Paul Wratt (previous) (diff)

comment:4 Changed 3 years ago by PulkoMandy

You can get the latest sources from gitlab, as an archive: https://gitlab.com/GrafX2/grafX2/repository/master/archive.tar.gz

comment:5 Changed 2 years ago by Thomas Bernard

is this ticket still relevant ?
I don't think current builds need XWindow for TTF rendering

comment:6 Changed 2 years ago by PulkoMandy

No, as mentionned above a similar change had already been merged in. To make sure, we could check by using SDL with the framebuffer driver or directfb, or using Wayland (if that's even possible with SDL 1.x?)

I think there should not be a problem, provided fontconfig is configured properly it is possible to get it to enumerate bitmap fonts as well - unfortunately, this is not the default on usual Linux distros, however. But I'd rather let people fix this on the system side than working around the problem.

Last edited 2 years ago by PulkoMandy (previous) (diff)

comment:7 Changed 2 years ago by PulkoMandy

Milestone: 2.52.6

comment:8 Changed 2 years ago by PulkoMandy

Owner: changed from Adrien Destugues to PulkoMandy
Status: newassigned

comment:9 Changed 19 months ago by Thomas Bernard

Resolution: fixed
Status: assignedclosed

comment:10 Changed 17 months ago by Paul Wratt

what was the fix that was applied.

remember the original issue was building on posix systems WITHOUT X-Windows, and that forcing the use of fontconfig forces the use of X.

All the systems I have used, usually TTF fonts are in /usr/share/fonts/ttf/*, but this is not a given (Gentoo? Redhat? Arch? Mage?).

If that path was accepted as a default, then compiling AND running it would on any system with that path, irrelavent of waether X Windows (thence fontconfig) was present

Specifically for systems that dont have that path, it would be package maintainers who would set/add the default path for that OS.

Anyone else compiling for a system that did not have that path, _should_ have enough info and/or skills to find the path on their system, so a note in compiling would be advisable.

Recipricol: for flexibility, there should be a make define or config switch to allow others to build "with fontconfig (X Windows Only, not console)", or something similar.

Last edited 17 months ago by Paul Wratt (previous) (diff)

comment:11 Changed 17 months ago by Thomas Bernard

https://www.freedesktop.org/wiki/Software/fontconfig/

Fontconfig does not:

  • render the fonts themselves (this is left to FreeType? or other rendering mechanisms)
  • depend on the X Window System in any fashion, so that printer only applications do not have such dependencies

So if your fontconfig requires X, that's a problem of your fontconfig build. As Pulkomandy said, you should fix this on system side.

comment:12 Changed 17 months ago by Thomas Bernard

for example, the debian package does NOT depends on X Window :
https://packages.debian.org/buster/libfontconfig1
Fontconfig is a font configuration and customization library, which does not depend on the X Window System.

comment:13 Changed 17 months ago by Paul Wratt

ok, I did this build on a Raspbian Jessie build maybe 2 years ago, and although its just a tweaked Debian, things have changed considerably in the last 12 months and i am due for an OS upgrade for other reasons, so I'll test it again with a build from source (the version I use does not have X Windows), and let you know how things turned out.

thanks for quick reply btw.

Paul

Note: See TracTickets for help on using tickets.