OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Nov 14, 2019 6:15 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Simple font rendering library
PostPosted: Fri Aug 02, 2019 1:25 pm 
Offline

Joined: Wed Jul 17, 2019 2:27 pm
Posts: 11
bzt wrote:
There are several ways for combining characters:
1. if UNICODE has specified a combined ligature, then you can use its UTF-8 sequence (mostly in Latin-1 supplement, Extended Latin-A, B and in Alphabetic Presentation Forms blocks, but the latest UNICODE standard has code points for combined Devanagari letters too for example)
2. if combined code point is not specified, then you can get two or more UTF-8 sequences for the combination, all having zero advances except for the last one (as specified by UNICODE in the Combining Diacritical Marks and other blocks)
3. with ssfn_render(), use kerning to zero out the left glyph's advance value
4. with ssfn_render(), ignore the advance values returned, do as you want. This is a low level rendering library, meaning it returns the rasterized glyphs, and you can combine those on screen as you please.


So I've very curious about your mention of combining a UTF-8 character with zero width UTF-8 characters. You mentioned that they all have zero width except for the last one. When I was trying to research this, most of the standards (web, Unicode, etc.) used the non-zero width character first and then combined it with the zero width character(s). Putting the zero width characters first (not incrementing location) and then adding a standard character would seem to make more sense from a programmatic viewpoint. I only remember finding one other solution that did it that way though. The rest of the references I looked at did the reverse. Did you end up doing it this way because it made the most sense for the library or were there some other standards you followed? If there are other standards/references that do it this way, do you have some pointers to them? Thanks.


Top
 Profile  
 
 Post subject: Re: Simple font rendering library
PostPosted: Fri Aug 02, 2019 2:42 pm 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 401
Hi,

Thanks for checking out my font library!

lmemsm wrote:
You mentioned that they all have zero width except for the last one. When I was trying to research this, most of the standards (web, Unicode, etc.) used the non-zero width character first and then combined it with the zero width character(s). Putting the zero width characters first (not incrementing location) and then adding a standard character would seem to make more sense from a programmatic viewpoint. I only remember finding one other solution that did it that way though. The rest of the references I looked at did the reverse. Did you end up doing it this way because it made the most sense for the library or were there some other standards you followed? If there are other standards/references that do it this way, do you have some pointers to them? Thanks.
Considering that you adjust the cursor after drawing the glyph, it makes only sense to write the zero adjustment glyphs first. Consider this: you have an acute ' with zero adjustment (in UNICODE combining marks block) and an A (in UNICODE standard Latin block) with some. If you draw the accent first then the letter, then you'll start drawing the letter A at the same position as the acute, and since the last glyph has an adjustment, the cursor will be moved to the next character's position correctly. On the other hand if you write it the other way around, then you would first draw the letter, move the cursor then draw the acute without moving the cursor, therefore it would appear above the next glyph, and not above the letter A.
Of course you could draw them in that order too, if you specify a negative kerning value for the A and ' combination. In this case you would draw the A, adjust the cursor, then subtract a value from the cursor because of the kerning, draw the acute and move the cursor after the letter A.

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: Simple font rendering library
PostPosted: Fri Aug 02, 2019 2:58 pm 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 401
Craze Frog wrote:
Unfortunately, the rendering quality doesn't look all that good. Do you want to give a brief overview of the algorithm it uses?
What's wrong with it? I'd appreciate any constructive criticism.

Assuming you have problem with the outline, it's using a simple anti-aliasing algorithm, in which I draw the outline with 8 bit precision. I shift it so that 127 is complete background, 255 (or -1) and 1 is almost foreground. Then I use that value for the alpha channel mask. The goal was a very simple, integer-only implementation, even in the price of quality. You can find the algorithm here. For bitmaps, I've implemented a reentrant pixel addition function (small code size), which decreases the alpha channel by each recursion. A pixel is added if there's at least two foreground neighbouring pixels. That can be found here (recursion converted into an iteration for smaller stack usage).

If by rendering quality you refer to the shape's quality, that's configurable. Most compressed, worst quality ratio uses 16x16 grid, while the less compressed but best quality uses 4096x4096 grid. According to my findings, 256x256 is usually offers good compression without loosing significant typeface details. Of course a font with 64x64 grid would yield much worse rendering quality (but smaller file size) than a 1024x1024 grid font for example. More about font quality.
Image

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: Simple font rendering library
PostPosted: Sun Aug 04, 2019 9:23 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 148
The image in the last post shows there's not enough space between the characters for me. I have always had this problem with Ariel, actually. At some sizes, the gap between characters is no wider than the lines, while the spaces within characters is many times larger. If my eyes are even a little bit tired or my screen less than perfectly sharp, it turns into bizarre alien glyphs!

Another problem: inter-char spacing is erratic, especially at 1024x1024. Compare 'am' in 'amet' with 'ps' in 'ipsum' for the extremes. The gap between 'a' and 'm' is almost large enough to look like space between words, while the p and the s are actually touching. See 'ons' in 'consectetur' for general erraticness, less terrible but still enough to cause me trouble on a bad day. The gap between o and n is fine, but n and s are very close to merging. I think it might help to have 'margins' in the font so that important parts of adjacent characters may be prevented from merging. These margins would be permitted to overlap with each other, but not with solid areas.

To be honest, my eyes are really hard on font renderers. :) After using Freetype for 25 years plus some experience with professional font renderers rendering professional fonts, (Apple and Microsoft,) I decided to severely limit my use of scalable font rendering in my own work. I'll use it in high-dpi screens, but I won't even try on regular screens. By "high-dpi", I mean "4k" up to 28 inches, (not larger!) or just-about any tablet or smartphone. Even with professional font rendering, I've just configured a console, full-screen in 1920x1080, for 70x20 characters to give my eyes a break. :)

_________________
Wir mussen wissen, wir werden wissen.


Top
 Profile  
 
 Post subject: Re: Simple font rendering library
PostPosted: Mon Aug 05, 2019 5:54 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 401
Hi,

eekee wrote:
The image in the last post shows there's not enough space between the characters for me.
When converting OTF to SSFN with ttf2sfn tool you can specify a delta adjustment on the command line. For example "-a 2" will add 2 grid pixels to the advance to increase the spacing between all glyphs.

eekee wrote:
I have always had this problem with Ariel, actually. At some sizes, the gap between characters is no wider than the lines, while the spaces within characters is many times larger. If my eyes are even a little bit tired or my screen less than perfectly sharp, it turns into bizarre alien glyphs!
For those bizarre alien glyphs you can add kerning.

eekee wrote:
Another problem: inter-char spacing is erratic, especially at 1024x1024. Compare 'am' in 'amet' with 'ps' in 'ipsum' for the extremes. The gap between 'a' and 'm' is almost large enough to look like space between words, while the p and the s are actually touching.
The ttf2sfn tool uses the values that Freetype2 returns with FT_Outline_Decompose. Originally I've used ttf advances, but that was even worse. If it doesn't seem right, that's a Freetype2 issue. The solution is easy, you can modify the spacing as you like in the SSFN font independently to the original font.

eekee wrote:
See 'ons' in 'consectetur' for general erraticness, less terrible but still enough to cause me trouble on a bad day. The gap between o and n is fine, but n and s are very close to merging. I think it might help to have 'margins' in the font so that important parts of adjacent characters may be prevented from merging. These margins would be permitted to overlap with each other, but not with solid areas.
Again, ttf2sfn uses the kerning values that Freetype2 returns (see FT_Get_Kerning call here. You can modify the kerning values as you like in the SSFN font.

eekee wrote:
To be honest, my eyes are really hard on font renderers. :) After using Freetype for 25 years
I've spent a week to read all the FT2 documentation and make the appropriate FT2 calls. If you can help me to fix these to provide better results, I'd appreciate your help!

eekee wrote:
plus some experience with professional font renderers rendering professional fonts, (Apple and Microsoft,) I decided to severely limit my use of scalable font rendering in my own work. I'll use it in high-dpi screens, but I won't even try on regular screens. By "high-dpi", I mean "4k" up to 28 inches, (not larger!) or just-about any tablet or smartphone. Even with professional font rendering, I've just configured a console, full-screen in 1920x1080, for 70x20 characters to give my eyes a break. :)
Besides professional renderers are not an option for a hobby OS :-) I also though that maximum size of a 255x255 pixels rasterized glyph on a 4k screen should be sufficient, that's why my reference SSFN renderer is maximized at that size. This allows me to optimize for a lot smaller memory footprint.


As for the font files, I would suggest to convert them to plain ASCII format, fix the spacing and kerning as you like with a simple text editor, then convert back to binary format. This is well documented. (FYI I'm also working on a font editor with a GUI. It's almost finished, you can load SSFN and ASC files, modify them, but you can only save in ASC format as of now).

As for the reference renderer implementation, the goal was to be embedable as possible, therefore I've made a lot of trade offs: compact size, integer-only arithmetic and low memory consumption was my preference over rasterized quality. One could write another renderer that aims at perfect rasterization using more memory and floating point arithmetic with the data read from the same SSFN files. Would you be interested in that? I'd be great!

Cheers,
bzt


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: MSN [Bot] and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group