Cdev wrote:
Alright , I respect your project and the effort you put into your documentation , but "you should read the documentation" doesn't apply here.
I read the API docu 3 times , and attempted to understand what your code was doing. I did not "just copy and paste" , I did lack the knowledge of the difference between hicolor and truecolor
Well, that's unfortunate, but I don't think it should be discussed in a font renderer's manual.
Cdev wrote:
because, well I haven't really developed any graphics or an OS before , and (very understandably , but notably) the docu 's comment for [/code]#define SSFN_CONSOLEBITMAP_HICOLOR[/code] was basically something like "use hicolor" .
Yes, absolutely. I expect the readers to know the difference between packed pixel models. For example, if you read a book about file systems, there will be no explanation on how a sector is read or write, because that's supposed to be known.
Cdev wrote:
Of course, it is my ignorance to not know the difference , but that has nothing to do with reading the API docs, which obviously I did.
Okay, sorry, I thought you are one of the many who just copy'n'pastes blindly and expects everything to work.
Cdev wrote:
Further, I never was illusioned that your API would handle newline / other escape sequences , and you have every right to leave that to the developer using your putc. I was making my own putc for handling escape sequences anyways.
Yes, exactly. The "putc" in the name does not mean it's a putc implementation, rather it means it should be called from your putc. Console driver has to handle a lot of character sequences, and when it decides that the character is to be shown, that's when SSFN comes into play.
Cdev wrote:
However, the fact that ssfn_dst.y is pixels and not chars , was , at the time of posting my question , mentioned nowhere in the API docs.
You are right, I should add that.
Cdev wrote:
Had I known this it would have been trivial to firgure out the above. Thanks for clearing that up .
You're welcome.
Cdev wrote:
If yu care for my opinion, you don't need to add support for escape sequences , just mention or hint at them in the docs and that's enough. The renderer's work is NOT handling input , but rather plotting output, but of course, you know best for your project.
Exactly. I've added newline for convenience, but I've mentioned it in the API.md doc that you should parse the sequences yourself.
Cdev wrote:
"read the API documentation section "Render a Glyph" with ssfn_render()" - well , since I wasn't using it , I didn't pay much attention to it. Also, I don't quite understand what you mean by clipping. Will ssfn_putc attempt to (the only function I'm really interested in) write beyond ssfn_dst.w ?
If ssfn_dst.w is set, then no, it won't. Clipping means that you specify a rectangular area on screen where the render is allowed to draw. For a simple console, that area is the entire screen. But for a windowed GUI terminal, it could be anywhere on screen and could have any size (because you can resize and move the window around).
Cdev wrote:
NOTE : Since you are recompiling , though I'd let you know : the font editor won't work on macOS BigSur (latest) on my Intel mac
What's the error message? I don't have BigSur, so there's absolutely no chance that I could compile or test it on that. If you are willing to provide detailed error messages in a gitlab issue, then I'll do my best to guide you how to fix.
Cheers,
bzt