Closed ropod7 closed 8 years ago
VeraMono_10: It should be 10 pixels of height, if you hide black dot at the bottom of char.
Could you provide an example? I do have some trouble to figure out what's happening/wrong.
Now there I changed 'height' : 0xf,
I'm encoding the font in multiple of 8 bits (for data alignment and further binary reading allowing fast seek in file... thank to predictive seek calculation). Characters rendering is done from the top-left corner... Just not draws over the mentioned "height" in the dictionary, this height indicate the position of bottom of the characters (said bottom-line). From that bottom line, I did calculate the baseline position on wich a placed the "a" characters.
Here 2 detailed samples (with additional explanation here under).
The 1 bits at the bottom of the characters are not "used" since they are over the real height of the font (in pixel) as mentioned in the "height" property. Characters columns are draw from the top of the character. By reading the pixels from the top of its representation (and only the mentioned height, not over) THEN the characters should be properly aligned including the descenders (from the top-left corner of the characters). This allows to have a baseline (under the a) different form the bottom-line (under the A or the q). The black rectangle under the bottom-line (of "a" in Vera_10) should never be draw... so never visible. This is why I did left them to 1 (to identify drawing issue).
so the font 'height' mentioned in the dictionary indicate how many bits (pixels) must be draw on a character column (from the top of the column)... even if the number of bit available are bigger (always being a multiple of 8 bits).
Presently, ft-generator can encode any characters height (by using multiple of 8 bits). 8, 16, 24, 32, ... bits encoding.
This explanation would it help you? or do you want me to update the way ft-generator encode the font?
I may try to slice them shortly. But memory usage is important. What do you think obout it? It most important in large fonts.
I'm really planning to swith to binary file (and load on the fly) at next step. As soon as you confirm that this encoding works properly for you I would start to work on it.
Then memory allocation should not be a problem since data would only be loaded by small chunck at drawing time.
Meurisse D. (Gérant) MC Hobby SPRL Service R&D et support
Le 17/04/16 16:43, Roman Podgaiski a écrit :
I may try to slice them shortly. But memory usage is important. What do you think obout it? It most important in large fonts.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/mchobby/freetype-generator/issues/1#issuecomment-211034292
You may try in there shift registers, something like: char = 0b11110011110100 & 0b10011111111 Or: 15604 & 1279 Where 15604 is ! and 1279 is template.
If it hard way, for me is shortly. Let's see who do it faster. I am away now from my lab. But if you try, your fonts structure must to be the same for any font.
I do clearly understand what you are saying about the masquerading. I will update the ft-generator to use it while generating py files.... but I have to work now.
Meurisse D. (Gérant) MC Hobby SPRL Service R&D et support Le 17/04/16 16:58, Roman Podgaiski a écrit :
If it hard way, for me is shortly. Let's see who do it faster. I am away now from my lab. But if you try, your fonts structure must to be the same for any font.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/mchobby/freetype-generator/issues/1#issuecomment-211038540
Sorry, it seems like: char = 0b11110011110100 & 0b11111111111
Without zeros in template.
QPython for android roling in this scope. ;)
Ok, issue catched. I did reproduced it (after PyBoard Firmware update). I will look to it tomorrow (certainly in the evening)
Fixed. Font file renamed (accordingly to real height). You can use the following code in the fonts/init.py
# -*- coding: utf-8 -*-
__all__ = []
def importing(font):
if font == 'Vera_10':
from fonts.vera_10 import Vera_10 as font
elif font == 'Arial_14':
from fonts.arial_14 import Arial_14 as font
elif font == 'Vera_15':
from fonts.vera_15 import Vera_15 as font
elif font == 'VeraMono_15':
from fonts.veram_15 import VeraMono_15 as font
elif font == 'Pitch_15':
from fonts.pitch_15 import Pitch_15 as font
elif font == 'Pitch_23':
from fonts.pitch_23 import Pitch_23 as font
elif font == 'Vera_23':
from fonts.vera_23 import Vera_23 as font
elif font == 'VeraMono_23':
from fonts.veram_23 import VeraMono_23 as font
elif font == 'Heydings_23':
from fonts.heyd_23 import Heydings_23 as font
elif font == 'Entypo_13':
from fonts.etypo_13 import Entypo_13 as font
elif font == 'Entypo_23':
from fonts.etypo_23 import Entypo_23 as font
else:
raise ImportError('wrong font name: ' + font)
return font
Just remember to fix initial issues VeraMono_10: It should be 10 pixels of height, if you hide black dot at the bottom of char. Vera_10: Same trouble. Vera_14: Check symbols - ° ^2 ^3 ^1 VeraMono_14: Same as Vera_14 Pitch_14: May be symbols / \ ° , (beatiful font) Pitch_22: Symbols ; * ° Vera_23: Same as Vera_14 VeraMono_23: Same Entypo_23: I think this should be 14 pix of height. Bold line at the bottom of symbol. Entypo_42: I think it should be 23 px. Looks perfect.
Vera_14: Check symbols - ° ^2 ^3 ^1
Pitch_14: May be symbols / \ ° , (beatiful font)
__ Pitch_22: Symbols ; * ° __
VeraMono_23: Same
Entypo_23
Entypo_42
font will be generated this afternoon
in fonts:
VeraMono_10: It should be 10 pixels of height, if you hide black dot at the bottom of char. Vera_10: Same trouble. Vera_14: Check symbols - ° ^2 ^3 ^1 VeraMono_14: Same as Vera_14 Pitch_14: May be symbols / \ ° , (beatiful font) Pitch_22: Symbols ; * ° Vera_23: Same as Vera_14 VeraMono_23: Same Entypo_23: I think this should be 14 pix of height. Bold line at the bottom of symbol. Entypo_42: I think it should be 23 px. Looks perfect.