Opened 7 years ago
Closed 4 years ago
Last modified 4 years ago
#36 closed defect (fixed)
use SDL TTF without needing X Windows
|Reported by:||paul.wratt||Owned by:||PulkoMandy|
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.
Change History (17)
by , 7 years ago
by , 7 years ago
Adds For_each_font_in_tree() (needs to be declared in io.h too), calls Add_font() in text.c
by , 7 years ago
outputs FontPath as found in "xset q" output, /usr/share/font == "built-ins" on Debian
by , 7 years ago
comment:1 by , 7 years ago
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 by , 5 years ago
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
comment:3 by , 5 years ago
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).
comment:4 by , 5 years ago
You can get the latest sources from gitlab, as an archive: https://gitlab.com/GrafX2/grafX2/repository/master/archive.tar.gz
comment:5 by , 5 years ago
is this ticket still relevant ?
I don't think current builds need XWindow for TTF rendering
comment:6 by , 5 years ago
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.
comment:7 by , 5 years ago
|Milestone:||2.5 → 2.6|
comment:8 by , 5 years ago
|Status:||new → assigned|
comment:9 by , 4 years ago
|Status:||assigned → closed|
comment:10 by , 4 years ago
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.
comment:11 by , 4 years ago
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 by , 4 years ago
for example, the debian package does NOT depends on X Window :
Fontconfig is a font configuration and customization library, which does not depend on the X Window System.
comment:13 by , 4 years ago
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.
Adds USE_XLIB in Init_text() to allow X Windows only or "both" when compiled