Empty rendering output under windows about libschrift

[tomolt]

Thank you, I'll investigate this once I find some time.

One thing I noticed is that populating the image struct with anything other than 0 results in an error. Is this intended?

That does sound very odd. The image struct is supposed to be populated by the caller with the width, height, and some memory to store the pixel values to. The exact contents of the pixel memory shouldn't matter, they will be overwritten by sft_render() anyway.

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

How did you test with the X11-specific demo program on windows? Did you use a X11-server like Xming or VcXsrv?
Do you have any tips in general for how I can reproduce this problem?

[kleinsimon]

Ah sorry, that was the wrong link. I took the demo from https://github.com/lhf/libschrift-show

[tomolt]

So far I'm not able to reproduce your issue.
That demo program works fine under Linux.
I also tested it on Windows 10 with MinGW-w64 with the built-in system fonts.
That also generated a non-empty image, although there seems to be some other kind of row stride bug, as the image is skewed horizontally.

What kind of system are you on? Is it x86-64 or ARM? What Windows version?
This might be an endianness problem in the TTF parsing code, or maybe the file mapping code doesn't function properly?

What do you mean by 'populating the image struct with anything other than 0 results in an error'?
What kind of error? Does it crash, or does some function return an error code, or do you get an error message?
Also, what do you mean by 'unmodified bitmap'? (That demo program is supposed to write a Portable Graymap (*.pgm) file
to stdout, not *.bmp.) Is it a completely empty file, or are all pixels blank?

[tomolt]

Alright, so far I found the cause of the skewing bug that happens with libschrift-show on Windows (lhf/libschrift-show#1).
This probably won't solve your issue though.