tomolt / libschrift Goto Github PK

Hey tomolt, thanks for the great library. I'm encountering a problem that whitespaces are not being rendered for some reason. Did I miss something? I used your stress.c file as template.

Here's a snippet of my code. letterImagePtr is just a struct that groups several image related information.

SFT sft = {0};
SFT_Glyph gid;
SFT_GMetrics *metricsPtr = &(letterImagePtr->metrics);
SFT_Image *imagePtr = &(letterImagePtr->image);

sft.font = font;
sft.xScale = size;
sft.yScale = size;
sft.flags = SFT_DOWNWARD_Y;

if (sft_lookup(&sft, c, &gid) < 0)
{
    /* Lookup failed. */
}
else if (sft_gmetrics(&sft, gid, metricsPtr) < 0)
{
    /* Metrics evaluation failed. */
}
else
{
    imagePtr->width  = metricsPtr->minWidth;
    imagePtr->height = metricsPtr->minHeight;
    imagePtr->pixels = malloc((size_t)imagePtr->width * (size_t)imagePtr->height);
    printf("\n-------> Char: '%c', width: %d\n", (const char)c, imagePtr->width);
    if (imagePtr->pixels)
    {
        sft_render(&sft, gid, *imagePtr);
    }
    else
    {
        /* Pixel reservation failed. */
    }
}

Here's the Output:

Thanks and BR
monstermichl

RTL languages, such as Persian, are rendered as though they are LTR text, and therefore appear disjointed as shown below.

Are there any plans to add support for RTL languages?

Many thanks.

Persian test text

I'm using SFT_CHAR_IMAGE flag to get a bitmap, and it all looks fine at first. I'm getting a nice white glyph on black background. But then I noticed the background is not always (0,0,0) black. There are plenty of (1,1,1) pixels to the right side of the glyph. Barely visible horizontal lines going from the right side of the glyph up to the right edge of the bitmap.

I have no idea how emojis work....

Do emojis have many glyph for each color?
Do emojis have a special glyph which has lots of colors in it?

But in any case, does libschrift has support for colored emojis?

Hello, I am trying to compile the static libraries .lib for Windows. I tried using make and it didn't seem to work. Does this mean I have to compile it manually? If so, what libraries do I need to link against?

When there is more than 1 subtable the loop will break because it adds to offset more than just the subtable length.
offset += 6;
offset += 8;
offset += length;
According to MS, the header contains "Length of the subtable, in bytes (including this header)"

Futhermore, there should be an is_safe_offset litany before bsearch.

On macOS unsigned long is uint_fast64_t and uint_fast32_t is just unsigned int. This creates a compilation due to differing definitions for various functions which are declared using SFT_Glyph in schrift.h and uint_fast32_t in schrift.c.

A minimal fix for this would be sternenseemann@1b1292f, but this still creates a lot of conversion errors on macOS.

I think to fix this we either need to consistently use uint_fast32_t or unsigned long (and ignore that it's bigger on macOS).

https://tomolt.github.io/libschrift/v0.10.2.schrift.3.html#RETURN_VALUES

sft_gmetrics() instead of sft_hmetrics()

Very nice stuff. I have looked over the code briefly, but how hard would it be to get a scaled output of a character for just the line points and then can be processed from there. I will take some more time to look at the code, but maybe can come up with a sample app that does this quickly? Going to try and put this on a small micro, etc.

Will deal with the curves later depending on how it looks.

Thanks

I used your lib and render the demo on bmp picture, but my pic is not as clear as your x display. I can not figure out why this happen? Does x render support this function(anti-aliasing).
Looking forward to your reply, thanks.

Hi tomolt,

Thanks for this library. I'm trying to use it under windows, but I always get an unmodified bitmap, regardless what I do. I used the latest tag 10.2 as well as the current main.

I compiled it with gcc (mingw64) and tested it with the demo from https://github.com/lhf/libschrift-show :

gcc -c -o schrift.o schrift.c
gcc -o schrift.dll -s -shared schrift.o -Wl,--subsystem,windows
gcc -o show.exe show.c -I./ -L./ -lschrift

The program then runs fine, I tried it with different fonts like arial etc, but the resulting image is always plain white. The same happens when I use the library from my own program.
One thing I noticed is that populating the image struct with anything other than 0 results in an error. Is this intended?

Hello! I had to add following code to make compiling in C++ possible. I think it should be added to the library.
In schrift.h:

// Just before first struct declarations
#ifdef __cplusplus
extern "C" {
#endif

// (schrift.h code here...)

// Before the last #endif
#ifdef __cplusplus
}
#endif

Please show example in vector
for example SDL draw lines

I've been having compile issues for this on several of my machines, I'm not very confident of this fix other than for my own use, but thought I'd post it here in case either I'm doing something entirely wrong, or this is actually something that belongs in the code.

for reference, the errors:

libschrift/schrift.c:417:1: error: static declaration of ‘reallocarray’ follows non-static declaration
  417 | reallocarray(void *optr, size_t nmemb, size_t size)

libschrift/schrift.c:32: warning: "_POSIX_C_SOURCE" redefined
   32 | # define _POSIX_C_SOURCE 1
      |
In file included from /usr/include/assert.h:35,
                 from /(blah-blah-blah)/libschrift/schrift.c:17:
/usr/include/features.h:292: note: this is the location of the previous definition
  292 | # define _POSIX_C_SOURCE        200809L

Either way here's the diff I use to fix.

diff --git a/schrift.c b/schrift.c
index eb39376..1109022 100644
--- a/schrift.c
+++ b/schrift.c
@@ -29,7 +29,9 @@
 # define WIN32_LEAN_AND_MEAN 1
 # include <windows.h>
 #else
+#ifndef _POSIX_C_SOURCE
 # define _POSIX_C_SOURCE 1
+#endif
 # include <fcntl.h>
 # include <sys/mman.h>
 # include <sys/stat.h>
@@ -125,7 +127,9 @@ struct SFT_Font

 /* function declarations */
 /* generic utility functions */
+#ifndef __USE_MISC
 static void *reallocarray(void *optr, size_t nmemb, size_t size);
+#endif
 static inline int fast_floor(double x);
 static inline int fast_ceil (double x);
 /* file loading */
@@ -406,6 +410,7 @@ failure:
  * if both s1 < MUL_NO_OVERFLOW and s2 < MUL_NO_OVERFLOW */
 #define MUL_NO_OVERFLOW        ((size_t)1 << (sizeof(size_t) * 4))

+#ifndef __USE_MISC
 /* OpenBSD's reallocarray() standard libary function.
  * A wrapper for realloc() that takes two size args like calloc().
  * Useful because it eliminates common integer overflow bugs. */
@@ -419,6 +424,7 @@ reallocarray(void *optr, size_t nmemb, size_t size)
        }
        return realloc(optr, size * nmemb);
 }
+#endif

 /* TODO maybe we should use long here instead of int. */
 static inline int

Hey there,

I've encountered a stack overflow crash in render_outline due to the fact that in my setup I cannot allocate 256KB onto the stack.
STACK_ALLOC requires at least 256KB of memory (sizeof(Cell) * 128 * 128) which is not available.

On my setup, I've lowered this number to 32 * 32 which fits fine.

Both C and POSIX only specifies that int must be at least 16 bits wide (Linux says 32 bits), so charCode in stf_char should either be an uint_least32_t, an unsigned long int, or a long int (uint32_t could also be used if you only care for normal computers).

The order libraries are passed to the linker matters, more specfially all external libraries should be at the end.

The current master can not be built

cc -Os -lm sftdemo.o -o sftdemo -L/usr/lib/X11 -L. -lX11 -lXrender -lschrift
/usr/bin/ld: ./libschrift.a(schrift.o): in function `draw_line.isra.0':
schrift.c:(.text+0x334): undefined reference to `floor'
/usr/bin/ld: schrift.c:(.text+0x3ea): undefined reference to `floor'
/usr/bin/ld: ./libschrift.a(schrift.o): in function `proc_outline':
schrift.c:(.text+0x969): undefined reference to `floor'
/usr/bin/ld: schrift.c:(.text+0x98e): undefined reference to `floor'
/usr/bin/ld: schrift.c:(.text+0x9aa): undefined reference to `ceil'
/usr/bin/ld: schrift.c:(.text+0x9d6): undefined reference to `ceil'
collect2: error: ld returned 1 exit status
make: *** [Makefile:17: sftdemo] Error 1

After applying a simple patch it does build.

$ make
cc -Os -std=c99 -pedantic -Wall -Wextra -I./  -c -o schrift.o schrift.c
ar rc libschrift.a schrift.o
ranlib libschrift.a
cc -c -Os -std=c99 -pedantic -Wall -Wextra sftdemo.c -o sftdemo.o -I./ -I/usr/include/X11
cc -Os -lm sftdemo.o -o sftdemo -L/usr/lib/X11 -L. -lX11 -lXrender -lschrift -lm
cc -c -Os -std=c99 -pedantic -Wall -Wextra stress.c -o stress.o -I./
cc -Os -lm stress.o -o stress -L. -lschrift -lm

For completness sake my toolchain is:

$ gcc --version
gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.33

csearch() has multiple edge cases, notably when the search key is larger than any elements in the array.
Go through all occurences of csearch in the code and make sure edge cases are handled gracefully everywhere.

Hi,
I am working on implementing this library on my hardware platform. To get higher performance, I plan to harden some calculation function in FPGA. The function draw_line looks suitable for harden. However, I noticed that the 2d raycasting is customized algorithm. Could you help provide some reference for understanding the algorithm? what's the pros/cons for this algorithm compared to other legacy algorithm such as Xiaolin-Wu algorithm?

Thanks for the help.

The demos included in libschrift depend on the X11 graphics environment. I've written a longer, exploratory demo that does not: instead, it generates a PGM file, which can be viewed virtually everywhere. See https://github.com/lhf/libschrift-show.
Feel free to use it any way you see fit.

Thank you for libschrift!

To be sure that module at least successfully compiles.

A function that returns all glyphs and their codepoints in a font would make it really easy to create packed textures for use in OpenGL.
Currently there's no way to do that without calling sft_lookup for every code point.

I'm a beginner in OpenGL, I don't use XLib at all, and this looks like a really nice alternative for the very heavy FreeType. I don't want to spend days/weeks learning XLib to figure out how to port either, so if you could provide a tutorial/demo for graphical OpenGL C programs, it would be extremely appreciated!!