* grub-mkfont and DejaVu font problems @ 2010-01-21 13:19 Evgeny K 2010-01-21 13:28 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 1 reply; 19+ messages in thread From: Evgeny K @ 2010-01-21 13:19 UTC (permalink / raw) To: grub-devel Hello! I'm currently developing a path to font functionality of grub2. Anti-aliased fonts (currently 8 bit AA, but probably sub-pixel AA for LCD too). There is one problem with DejaVuSansMono*.ttf fonts. When I'm trying to render glyphs with grub-mkfont's way, all of the glyphs are rendered with baseline in the middle so glyph sticks to the top of the bitmap. While "grub-mkfont -v -v" still able to show complete glyph (i.e. glyph image is not truncated) in the grub menu glyphs overlaps. FreeSans*.ttf (as example) does not have such problem. Does anybody know what the problem with DejaVu family might be? Best regards, Evgeny. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: grub-mkfont and DejaVu font problems 2010-01-21 13:19 grub-mkfont and DejaVu font problems Evgeny K @ 2010-01-21 13:28 ` Vladimir 'φ-coder/phcoder' Serbinenko 2010-01-22 11:46 ` Antialiased fonts patch Evgeny Kolesnikov 0 siblings, 1 reply; 19+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2010-01-21 13:28 UTC (permalink / raw) To: The development of GNU GRUB [-- Attachment #1: Type: text/plain, Size: 981 bytes --] Evgeny K wrote: > Hello! > > I'm currently developing a path to font functionality of grub2. Anti-aliased > fonts (currently 8 bit AA, but probably sub-pixel AA for LCD too). > > There is one problem with DejaVuSansMono*.ttf fonts. When I'm trying > to render glyphs with grub-mkfont's way, all of the glyphs are rendered > with baseline in the middle so glyph sticks to the top of the bitmap. > > While "grub-mkfont -v -v" still able to show complete glyph (i.e. glyph > image is not truncated) in the grub menu glyphs overlaps. > > FreeSans*.ttf (as example) does not have such problem. > > Does anybody know what the problem with DejaVu family might be? > > Bug in grub-mkfont is fixed in latest trunk > Best regards, Evgeny. > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 293 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Antialiased fonts patch. 2010-01-21 13:28 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2010-01-22 11:46 ` Evgeny Kolesnikov 2010-01-22 12:53 ` BVK Chaitanya 2010-01-26 9:11 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 2 replies; 19+ messages in thread From: Evgeny Kolesnikov @ 2010-01-22 11:46 UTC (permalink / raw) To: The development of GNU GRUB [-- Attachment #1: Type: text/plain, Size: 1104 bytes --] Here is the path for anti-aliased fonts. Everything my path does is: 1) Enriches grub-mkfont with ability to write (and debug with -vv) pff3 (as I call it now) font format. There are 2 differences between pff2 and pff3 formats: FILE magic (PFF2 becomes PFF3) and DATA block entires size multiples by 8 (1bit -> 8bit). In other words PFF3 stores 8-bit alpha channel instead of 1-bit. And grub-mkfont will still be able to generate pff2, of course. 2) Adds pff3 format parsing and drawing ability to font.c. And of course pff2 still there; actually as you can understand 95% of code is reused because of such a little differences in formats. Drawing itself implemented pretty straightforward: on each glyph drawing A channel (from glyph) and foreground color are converted to RGBA buffer and then blended in RGBA_8888 mode. As far as I understand writing custom blitter for now will not worth it in terms of efficiency. When I test it I was unable to see performance difference between 1-bit fonts and my version. They both flickers a little. Files affected: /font/font.c and /util/grub-mkfont.c. [-- Attachment #2: font.c.diff --] [-- Type: text/x-patch, Size: 5512 bytes --] --- font.c 2010-01-22 16:52:54.980914210 +0600 +++ font.bak.c 2010-01-22 00:38:28.000000000 +0600 @@ -51,7 +51,6 @@ struct grub_font { - grub_uint8_t version; char *name; grub_file_t file; char *family; @@ -65,7 +64,6 @@ grub_uint32_t num_chars; struct char_index_entry *char_index; grub_uint16_t *bmp_idx; - grub_uint8_t *glyph_bitmap_buffer; }; /* Definition of font registry. */ @@ -93,7 +91,6 @@ /* Font file format constants. */ static const char pff2_magic[4] = { 'P', 'F', 'F', '2' }; -static const char pff3_magic[4] = { 'P', 'F', 'F', '3' }; static const char section_names_file[4] = { 'F', 'I', 'L', 'E' }; static const char section_names_font_name[4] = { 'N', 'A', 'M', 'E' }; static const char section_names_point_size[4] = { 'P', 'T', 'S', 'Z' }; @@ -216,8 +213,6 @@ static void font_init (grub_font_t font) { - font->version = 2; - font->name = 0; font->file = 0; font->family = 0; @@ -445,7 +440,6 @@ struct font_file_section section; char magic[4]; grub_font_t font = 0; - grub_uint8_t pff3 = 0; #if FONT_DEBUG >= 1 grub_printf("add_font(%s)\n", filename); @@ -495,15 +489,12 @@ grub_printf("read magic ok\n"); #endif - if (grub_memcmp (magic, pff2_magic, 4) != 0 && grub_memcmp (magic, pff3_magic, 4) != 0) + if (grub_memcmp (magic, pff2_magic, 4) != 0) { grub_error (GRUB_ERR_BAD_FONT, "invalid font magic %x %x %x %x", magic[0], magic[1], magic[2], magic[3]); goto fail; } - else - if (grub_memcmp (magic, pff3_magic, 4) == 0) - pff3 = 1; #if FONT_DEBUG >= 3 grub_printf("compare magic ok\n"); @@ -517,9 +508,6 @@ font_init (font); font->file = file; - if (pff3 != 0) - font->version = 3; - #if FONT_DEBUG >= 3 grub_printf("allocate font ok; loading font info\n"); #endif @@ -621,9 +609,6 @@ font->max_char_width, font->max_char_height, font->num_chars); #endif - - /* Font loaded. Create glyph to bitmap conversion buffer */ - font->glyph_bitmap_buffer = grub_malloc (font->max_char_width * font->max_char_height * 4); if (font->max_char_width == 0 || font->max_char_height == 0 @@ -752,10 +737,7 @@ return 0; } - if (font->version == 3) - len = width * height; - else - len = (width * height + 7) / 8; + len = (width * height + 7) / 8; glyph = grub_malloc (sizeof (struct grub_font_glyph) + len); if (! glyph) { @@ -806,7 +788,6 @@ grub_free (font->name); grub_free (font->family); grub_free (font->char_index); - grub_free (font->glyph_bitmap_buffer); grub_free (font); } } @@ -1079,59 +1060,29 @@ glyph_bitmap.mode_info.width = glyph->width; glyph_bitmap.mode_info.height = glyph->height; - - if (glyph->font->version == 3) - { - glyph_bitmap.mode_info.mode_type = - (1 << GRUB_VIDEO_MODE_TYPE_DEPTH_POS) - | GRUB_VIDEO_MODE_TYPE_RGB | GRUB_VIDEO_MODE_TYPE_ALPHA; - glyph_bitmap.mode_info.blit_format = GRUB_VIDEO_BLIT_FORMAT_RGBA_8888; - glyph_bitmap.mode_info.bpp = 32; - glyph_bitmap.mode_info.bytes_per_pixel = 4; - glyph_bitmap.mode_info.pitch = glyph->width * 4; - } - else - { - glyph_bitmap.mode_info.mode_type = - (1 << GRUB_VIDEO_MODE_TYPE_DEPTH_POS) - | GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP; - glyph_bitmap.mode_info.blit_format = GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED; - glyph_bitmap.mode_info.bpp = 1; - - /* Really 1 bit per pixel. */ - glyph_bitmap.mode_info.bytes_per_pixel = 0; - - /* Packed densely as bits. */ - glyph_bitmap.mode_info.pitch = glyph->width; - - glyph_bitmap.mode_info.number_of_colors = 2; - glyph_bitmap.mode_info.bg_red = 0; - glyph_bitmap.mode_info.bg_green = 0; - glyph_bitmap.mode_info.bg_blue = 0; - glyph_bitmap.mode_info.bg_alpha = 0; - } - + glyph_bitmap.mode_info.mode_type = + (1 << GRUB_VIDEO_MODE_TYPE_DEPTH_POS) + | GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP; + glyph_bitmap.mode_info.blit_format = GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED; + glyph_bitmap.mode_info.bpp = 1; + + /* Really 1 bit per pixel. */ + glyph_bitmap.mode_info.bytes_per_pixel = 0; + + /* Packed densely as bits. */ + glyph_bitmap.mode_info.pitch = glyph->width; + + glyph_bitmap.mode_info.number_of_colors = 2; + glyph_bitmap.mode_info.bg_red = 0; + glyph_bitmap.mode_info.bg_green = 0; + glyph_bitmap.mode_info.bg_blue = 0; + glyph_bitmap.mode_info.bg_alpha = 0; grub_video_unmap_color(color, &glyph_bitmap.mode_info.fg_red, &glyph_bitmap.mode_info.fg_green, &glyph_bitmap.mode_info.fg_blue, &glyph_bitmap.mode_info.fg_alpha); - - if (glyph->font->version == 3) - { - int i; - grub_uint8_t *pixel = glyph->font->glyph_bitmap_buffer; - for (i = 0; i < glyph->width * glyph->height; i++) - { - *pixel = glyph_bitmap.mode_info.fg_red; pixel++; - *pixel = glyph_bitmap.mode_info.fg_green; pixel++; - *pixel = glyph_bitmap.mode_info.fg_blue; pixel++; - *pixel = glyph->bitmap[i]; pixel++; - } - glyph_bitmap.data = glyph->font->glyph_bitmap_buffer; - } - else - glyph_bitmap.data = glyph->bitmap; + glyph_bitmap.data = glyph->bitmap; int bitmap_left = left_x + glyph->offset_x; int bitmap_bottom = baseline_y - glyph->offset_y; [-- Attachment #3: grub-mkfont.c.diff --] [-- Type: text/x-patch, Size: 8437 bytes --] --- grub-mkfont.c 2010-01-22 15:01:47.664910782 +0600 +++ grub-mkfont.bak.c 2010-01-22 00:38:28.000000000 +0600 @@ -51,7 +51,7 @@ enum file_formats { - PFN, + PF2, ASCII_BITMAPS }; @@ -59,7 +59,6 @@ #define GRUB_FONT_FLAG_NOBITMAP 2 #define GRUB_FONT_FLAG_NOHINTING 4 #define GRUB_FONT_FLAG_FORCEHINT 8 -#define GRUB_FONT_FLAG_8BIT_AA 4096 struct grub_font_info { @@ -95,7 +94,6 @@ {"version", no_argument, 0, 'V'}, {"verbose", no_argument, 0, 'v'}, {"ascii-bitmaps", no_argument, 0, 0x102}, - {"pff3", no_argument, 0, '3'}, {0, 0, 0, 0} }; @@ -111,7 +109,6 @@ Usage: %s [OPTIONS] FONT_FILES\n\ \nOptions:\n\ -o, --output=FILE_NAME set output file name\n\ - -3, --pff3 save in pff3 format (antialiased)\n\ --ascii-bitmaps save only the ASCII bitmaps\n\ -i, --index=N set face index\n\ -r, --range=A-B[,C-D] set font range\n\ @@ -157,12 +154,7 @@ grub_uint8_t *data; int mask, i, j, bitmap_size; FT_GlyphSlot glyph; - int flag = FT_LOAD_RENDER; - - if (font_info->flags & GRUB_FONT_FLAG_8BIT_AA) - flag |= FT_LOAD_TARGET_NORMAL; - else - flag |= FT_LOAD_MONOCHROME; + int flag = FT_LOAD_RENDER | FT_LOAD_MONOCHROME; if (font_info->flags & GRUB_FONT_FLAG_NOBITMAP) flag |= FT_LOAD_NO_BITMAP; @@ -193,11 +185,7 @@ width = glyph->bitmap.width; height = glyph->bitmap.rows; - if (font_info->flags & GRUB_FONT_FLAG_8BIT_AA) - bitmap_size = width * height; - else - bitmap_size = ((width * height + 7) / 8); - + bitmap_size = ((width * height + 7) / 8); glyph_info = xmalloc (sizeof (struct grub_glyph_info) + bitmap_size); glyph_info->bitmap_size = bitmap_size; @@ -223,18 +211,13 @@ if (glyph_info->y_ofs + height > font_info->max_y) font_info->max_y = glyph_info->y_ofs + height; - if (font_info->flags & GRUB_FONT_FLAG_8BIT_AA) - memcpy (glyph_info->bitmap, glyph->bitmap.buffer, bitmap_size); - else - { - mask = 0; - data = &glyph_info->bitmap[0] - 1; - for (j = 0; j < height; j++) - for (i = 0; i < width; i++) - add_pixel (&data, &mask, - glyph->bitmap.buffer[i / 8 + j * glyph->bitmap.pitch] & - (1 << (7 - (i & 7)))); - } + mask = 0; + data = &glyph_info->bitmap[0] - 1; + for (j = 0; j < height; j++) + for (i = 0; i < width; i++) + add_pixel (&data, &mask, + glyph->bitmap.buffer[i / 8 + j * glyph->bitmap.pitch] & + (1 << (7 - (i & 7)))); } void @@ -246,17 +229,18 @@ grub_uint32_t j; for (i = 0; i < font_info->num_range; i++) - for (j = font_info->ranges[i * 2]; j <= font_info->ranges[i * 2 + 1]; j++) - add_char (font_info, face, j); + for (j = font_info->ranges[i * 2]; j <= font_info->ranges[i * 2 + 1]; + j++) + add_char (font_info, face, j); } else { grub_uint32_t char_code, glyph_index; for (char_code = FT_Get_First_Char (face, &glyph_index); - glyph_index; - char_code = FT_Get_Next_Char (face, char_code, &glyph_index)) - add_char (font_info, face, char_code); + glyph_index; + char_code = FT_Get_Next_Char (face, char_code, &glyph_index)) + add_char (font_info, face, char_code); } } @@ -308,74 +292,56 @@ xmax = glyph->x_ofs + glyph->width; if (xmax < glyph->device_width) - xmax = glyph->device_width; + xmax = glyph->device_width; xmin = glyph->x_ofs; if (xmin > 0) - xmin = 0; + xmin = 0; ymax = glyph->y_ofs + glyph->height; if (ymax < font_info->asce) - ymax = font_info->asce; + ymax = font_info->asce; ymin = glyph->y_ofs; if (ymin > - font_info->desc) - ymin = - font_info->desc; + ymin = - font_info->desc; bitmap = glyph->bitmap; mask = 0x80; for (y = ymax - 1; y >= ymin; y--) - { - int line_pos; + { + int line_pos; - line_pos = 0; - for (x = xmin; x < xmax; x++) - { - if ((x >= glyph->x_ofs) && - (x < glyph->x_ofs + glyph->width) && - (y >= glyph->y_ofs) && - (y < glyph->y_ofs + glyph->height)) - { - if (font_info->flags & GRUB_FONT_FLAG_8BIT_AA) - { - if (*bitmap > 127) - line[line_pos++] = '#'; - else if (*bitmap > 64) - line[line_pos++] = '8'; - else if (*bitmap > 8) - line[line_pos++] = 'o'; - else if (*bitmap > 1) - line[line_pos++] = '-'; - else - line[line_pos++] = '_'; - - bitmap++; - } - else - { - line[line_pos++] = (*bitmap & mask) ? '#' : '_'; - mask >>= 1; - if (mask == 0) - { - mask = 0x80; - bitmap++; - } - } - } - else if ((x >= 0) && - (x < glyph->device_width) && - (y >= - font_info->desc) && - (y < font_info->asce)) - { - line[line_pos++] = ((x == 0) || (y == 0)) ? '+' : '.'; - } - else - line[line_pos++] = '*'; - } - line[line_pos] = 0; - printf ("%s\n", line); - } - } + line_pos = 0; + for (x = xmin; x < xmax; x++) + { + if ((x >= glyph->x_ofs) && + (x < glyph->x_ofs + glyph->width) && + (y >= glyph->y_ofs) && + (y < glyph->y_ofs + glyph->height)) + { + line[line_pos++] = (*bitmap & mask) ? '#' : '_'; + mask >>= 1; + if (mask == 0) + { + mask = 0x80; + bitmap++; + } + } + else if ((x >= 0) && + (x < glyph->device_width) && + (y >= - font_info->desc) && + (y < font_info->asce)) + { + line[line_pos++] = ((x == 0) || (y == 0)) ? '+' : '.'; + } + else + line[line_pos++] = '*'; + } + line[line_pos] = 0; + printf ("%s\n", line); + } + } } void @@ -396,22 +362,22 @@ if (glyph->width != 8 || glyph->height != 16) { /* printf ("Width or height from glyph U+%04x not supported, skipping.\n", glyph->char_code); */ - correct_size = 0; + correct_size = 0; } int row; for (row = 0; row < glyph->height; row++) { - if (correct_size) - fwrite (&glyph->bitmap[row], sizeof(glyph->bitmap[row]), 1, file); - else - fwrite (&correct_size, 1, 1, file); + if (correct_size) + fwrite (&glyph->bitmap[row], sizeof(glyph->bitmap[row]), 1, file); + else + fwrite (&correct_size, 1, 1, file); } } - fclose (file); + fclose (file); } void -write_font_pfN (struct grub_font_info *font_info, char *output_file) +write_font_pf2 (struct grub_font_info *font_info, char *output_file) { FILE *file; grub_uint32_t leng, data; @@ -428,11 +394,7 @@ leng = grub_cpu_to_be32 (4); grub_util_write_image ("FILE", 4, file); grub_util_write_image ((char *) &leng, 4, file); - if (font_info->flags & GRUB_FONT_FLAG_8BIT_AA) - grub_util_write_image ("PFF3", 4, file); - else - grub_util_write_image ("PFF2", 4, file); - + grub_util_write_image ("PFF2", 4, file); offset += 12; if (! font_info->name) @@ -562,7 +524,7 @@ int font_index = 0; int font_size = 0; char *output_file = NULL; - enum file_formats file_format = PFN; + enum file_formats file_format = PF2; memset (&font_info, 0, sizeof (font_info)); @@ -573,7 +535,7 @@ /* Check for options. */ while (1) { - int c = getopt_long (argc, argv, "bao:n:i:s:d:r:hVv3", options, 0); + int c = getopt_long (argc, argv, "bao:n:i:s:d:r:hVv", options, 0); if (c == -1) break; @@ -670,10 +632,6 @@ case 0x102: file_format = ASCII_BITMAPS; break; - - case '3': - font_info.flags |= GRUB_FONT_FLAG_8BIT_AA; - break; default: usage (1); @@ -739,8 +697,8 @@ FT_Done_FreeType (ft_lib); - if (file_format == PFN) - write_font_pfN (&font_info, output_file); + if (file_format == PF2) + write_font_pf2 (&font_info, output_file); else if (file_format == ASCII_BITMAPS) write_font_ascii_bitmap (&font_info, output_file); ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-01-22 11:46 ` Antialiased fonts patch Evgeny Kolesnikov @ 2010-01-22 12:53 ` BVK Chaitanya 2010-01-22 13:22 ` Evgeny Kolesnikov 2010-01-26 9:11 ` Vladimir 'φ-coder/phcoder' Serbinenko 1 sibling, 1 reply; 19+ messages in thread From: BVK Chaitanya @ 2010-01-22 12:53 UTC (permalink / raw) To: The development of GNU GRUB Can you send us a screenshot? :) -- bvk.chaitanya ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-01-22 12:53 ` BVK Chaitanya @ 2010-01-22 13:22 ` Evgeny Kolesnikov 0 siblings, 0 replies; 19+ messages in thread From: Evgeny Kolesnikov @ 2010-01-22 13:22 UTC (permalink / raw) To: The development of GNU GRUB [-- Attachment #1: Type: text/plain, Size: 70 bytes --] > Can you send us a screenshot? :) Here it is. DejaVu, no hinting. [-- Attachment #2: Screenshot-Karmic [Running] - VirtualBox OSE.png --] [-- Type: image/png, Size: 31520 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-01-22 11:46 ` Antialiased fonts patch Evgeny Kolesnikov 2010-01-22 12:53 ` BVK Chaitanya @ 2010-01-26 9:11 ` Vladimir 'φ-coder/phcoder' Serbinenko 2010-01-26 10:04 ` Evgeny Kolesnikov 1 sibling, 1 reply; 19+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2010-01-26 9:11 UTC (permalink / raw) To: The development of GNU GRUB [-- Attachment #1: Type: text/plain, Size: 2371 bytes --] Evgeny Kolesnikov wrote: > Here is the path for anti-aliased fonts. > > At first I was completely against antialiasing support because of performance impact. But it being optional decreases the later. However there is one problem: your patch relies on text_layer to be RGBA8888 which was a mistake. RGBA8888 for text layer is vastly inefficient especially on 16-bit framebuffer and CPUs with small cache. I had plans to switch it to indexed color. Do you really need 8bits and 4 aren't enough? If 4 are enough we could make text_layer IA44 (indexed-4 bits, alpha 4 bits) if you need 8 bits we can do IA88. I'm not sure which one is faster: firs one is more cache-efficient, second one requires less ALU. Are you interested in implementing this? > Everything my path does is: > > 1) Enriches grub-mkfont with ability to write (and debug with -vv) > pff3 (as I call it now) font format. There are 2 differences between > pff2 and pff3 formats: FILE magic (PFF2 becomes PFF3) and DATA block > entires size multiples by 8 (1bit -> 8bit). In other words PFF3 stores > 8-bit alpha channel instead of 1-bit. > And grub-mkfont will still be able to generate pff2, of course. > > And by default grub-mkfont should generate not antialiased font for performance reasons. But user or theme creator can choose to use antialiased fonts if they wish. > 2) Adds pff3 format parsing and drawing ability to font.c. > And of course pff2 still there; actually as you can understand 95% of > code is reused because of such a little differences in formats. > > Drawing itself implemented pretty straightforward: on each glyph > drawing A channel (from glyph) and foreground color are converted to > RGBA buffer and then blended in RGBA_8888 mode. > > As far as I understand writing custom blitter for now will not worth it > in terms of efficiency. > > > When I test it I was unable to see performance difference between 1-bit > fonts and my version. They both flickers a little. > > Files affected: /font/font.c and /util/grub-mkfont.c. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 293 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-01-26 9:11 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2010-01-26 10:04 ` Evgeny Kolesnikov 2010-01-26 11:59 ` Vladimir 'φ-coder/phcoder' Serbinenko ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Evgeny Kolesnikov @ 2010-01-26 10:04 UTC (permalink / raw) To: The development of GNU GRUB Hi, > At first I was completely against antialiasing support because of > performance impact. But it being optional decreases the later. However > there is one problem: your patch relies on text_layer to be RGBA8888 > which was a mistake. RGBA8888 for text layer is vastly inefficient > especially on 16-bit framebuffer and CPUs with small cache. I had plans > to switch it to indexed color. Do you really need 8bits and 4 aren't > enough? I use 8-bit in order to give GRUB ability to look and feel exactly as other parts of OS, so yes, 8 bits are required. If one can't allow this for his system - he can use 1-bit fonts. I don't really care about such situation just because other parts of desktop on such a system will be awful too. > If 4 are enough we could make text_layer IA44 (indexed-4 bits, > alpha 4 bits) if you need 8 bits we can do IA88. I'm not sure which one > is faster: firs one is more cache-efficient, second one requires less > ALU. Are you interested in implementing this? Actually I'm planning to add 32-bit AA (heh-heh). Sub-pixel AA for LCD monitors for complete match with xorg capabilities. And this just can't be done in indexed mode. So I can suggest to make division: 1-bit & indexed text layer vs 8(32)-bit & RGBA layer. First is for speed, second (and third) is for beauty (BURG project is already interested in - Bean, help me :)). Doing it half-way will be nor fast nor appealing. And yes, I'm interested in doing it in most effective way: blitter, optimizations etc., just give me the direction. > > Everything my path does is: > > > > 1) Enriches grub-mkfont with ability to write (and debug with -vv) > > pff3 (as I call it now) font format. There are 2 differences between > > pff2 and pff3 formats: FILE magic (PFF2 becomes PFF3) and DATA block > > entires size multiples by 8 (1bit -> 8bit). In other words PFF3 stores > > 8-bit alpha channel instead of 1-bit. > > And grub-mkfont will still be able to generate pff2, of course. > > > > > And by default grub-mkfont should generate not antialiased font for > performance reasons. But user or theme creator can choose to use > antialiased fonts if they wish. It's exactly the way my patch does it. AA is optional and used explicitly. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-01-26 10:04 ` Evgeny Kolesnikov @ 2010-01-26 11:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 2010-01-26 19:44 ` Carles Pina i Estany 2010-02-11 2:58 ` Vladimir 'φ-coder/phcoder' Serbinenko 2010-02-11 13:30 ` Michal Suchanek 2 siblings, 1 reply; 19+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2010-01-26 11:59 UTC (permalink / raw) To: The development of GNU GRUB [-- Attachment #1: Type: text/plain, Size: 3400 bytes --] Evgeny Kolesnikov wrote: > Hi, > > >> At first I was completely against antialiasing support because of >> performance impact. But it being optional decreases the later. However >> there is one problem: your patch relies on text_layer to be RGBA8888 >> which was a mistake. RGBA8888 for text layer is vastly inefficient >> especially on 16-bit framebuffer and CPUs with small cache. I had plans >> to switch it to indexed color. Do you really need 8bits and 4 aren't >> enough? >> > > I use 8-bit in order to give GRUB ability to look and feel exactly > as other parts of OS, so yes, 8 bits are required. If one can't allow > this for his system - he can use 1-bit fonts. I don't really care about > such situation just because other parts of desktop on such a system will > be awful too. > You forget that other parts of the system have access to video acceleration capabilities, grub doesn't. > >> If 4 are enough we could make text_layer IA44 (indexed-4 bits, >> alpha 4 bits) if you need 8 bits we can do IA88. I'm not sure which one >> is faster: firs one is more cache-efficient, second one requires less >> ALU. Are you interested in implementing this? >> > > Actually I'm planning to add 32-bit AA (heh-heh). Sub-pixel AA for LCD > monitors for complete match with xorg capabilities. And this just can't > be done in indexed mode. > > So I can suggest to make division: 1-bit & indexed text layer vs > 8(32)-bit & RGBA layer. First is for speed, second (and third) > is for beauty Splitting speed/niceness is ok as long as they share most of the code and "speed" is default. Perhaps we can have a variable: set i_want_to_waste_time_in_booter=yes But before we can go to such length for beauty we would need native drivers first. No matter how you antialias if VBE accepts only 1024x768 which is stretched to 1280x800, it won't have any effect. Hence you need to port native drivers to grub. > (BURG project is already interested in - Bean, help > me :)). He is of no authority here. If something is considered harmful it will be rejected no matter what burg does. > Doing it half-way will be nor fast nor appealing. > > And yes, I'm interested in doing it in most effective way: blitter, > optimizations etc., just give me the direction. > Then you would need to consider 16-bit modes too. E.g. use RGBA5658 if screen is RGB565. > >>> Everything my path does is: >>> >>> 1) Enriches grub-mkfont with ability to write (and debug with -vv) >>> pff3 (as I call it now) font format. There are 2 differences between >>> pff2 and pff3 formats: FILE magic (PFF2 becomes PFF3) and DATA block >>> entires size multiples by 8 (1bit -> 8bit). In other words PFF3 stores >>> 8-bit alpha channel instead of 1-bit. >>> And grub-mkfont will still be able to generate pff2, of course. >>> >>> >>> >> And by default grub-mkfont should generate not antialiased font for >> performance reasons. But user or theme creator can choose to use >> antialiased fonts if they wish. >> > > It's exactly the way my patch does it. AA is optional and used > explicitly. > > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 293 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-01-26 11:59 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2010-01-26 19:44 ` Carles Pina i Estany 0 siblings, 0 replies; 19+ messages in thread From: Carles Pina i Estany @ 2010-01-26 19:44 UTC (permalink / raw) To: The development of GNU GRUB Hi, On Jan/26/2010, Vladimir '??-coder/phcoder' Serbinenko wrote: > Evgeny Kolesnikov wrote: > > So I can suggest to make division: 1-bit & indexed text layer vs > > 8(32)-bit & RGBA layer. First is for speed, second (and third) > > is for beauty > Splitting speed/niceness is ok as long as they share most of the code > and "speed" is default. how much slower would be? (just for curiosity). 10 ms per screen or 20 seconds? > Perhaps we can have a variable: > set i_want_to_waste_time_in_booter=yes I suggest "set i_want_high_quality_fonts=yes" (well, withought i_want). I would say that mainly everybody knows that "high quality something" usually has some payback. > But before we can go to such length for beauty we would need native > drivers first. No matter how you antialias if VBE accepts only > 1024x768 which is stretched to 1280x800, it won't have any effect. > Hence you need to port native drivers to grub. I understand and agree. -- Carles Pina i Estany http://pinux.info ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-01-26 10:04 ` Evgeny Kolesnikov 2010-01-26 11:59 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2010-02-11 2:58 ` Vladimir 'φ-coder/phcoder' Serbinenko [not found] ` <1265957146.2292.11.camel@EK> 2010-02-11 13:30 ` Michal Suchanek 2 siblings, 1 reply; 19+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2010-02-11 2:58 UTC (permalink / raw) To: The development of GNU GRUB, Evgeny Kolesnikov [-- Attachment #1: Type: text/plain, Size: 1239 bytes --] Any news on this one? > So I can suggest to make division: 1-bit & indexed text layer vs > 8(32)-bit & RGBA layer. First is for speed, second (and third) > is for beauty. Doing it half-way will be nor fast nor appealing. > > And yes, I'm interested in doing it in most effective way: blitter, > optimizations etc., just give me the direction. > Basically the general idea is to make whatever is looped through is as fast as possible and to decrease the number of iterations. E.g: put conditions outside of the loops, use 32-bit accesses instead of 8-bit ones (don't forget to check that uint32_t is 4-byte aligned) and don't use higher quality buffer if you're going to blit it on lower quality. Last rule isn't respected in grub2 (unfortunately). Of course exceptions to rules can be discussed especially in eye-candy mode I would prefer to make new version magic PFF3 and add a flag field in version = 3 and GRUB_FONT_8_BIT would be the first flag. This allows further expandability by orthogonality. I started reviewing your patch but it turned out that it's a patch bewtween some kind of your local versions. Could you send a patch against trunk? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 293 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <1265957146.2292.11.camel@EK>]
* Re: Antialiased fonts patch. [not found] ` <1265957146.2292.11.camel@EK> @ 2010-02-12 9:50 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 0 replies; 19+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2010-02-12 9:50 UTC (permalink / raw) To: Evgeny Kolesnikov; +Cc: The development of GRUB 2 [-- Attachment #1: Type: text/plain, Size: 407 bytes --] Evgeny Kolesnikov wrote: >> I would prefer to make new version magic PFF3 and add a flag field in >> version = 3 and GRUB_FONT_8_BIT would be the first flag. This allows >> further expandability by orthogonality. >> > > I used PFF3 magic for 8-bit and PFF4 for 24-bit (sub-pixel). > > Please use PFF3 and feature bitfield -- Regards Vladimir 'φ-coder/phcoder' Serbinenko [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 293 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-01-26 10:04 ` Evgeny Kolesnikov 2010-01-26 11:59 ` Vladimir 'φ-coder/phcoder' Serbinenko 2010-02-11 2:58 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2010-02-11 13:30 ` Michal Suchanek 2010-02-12 6:21 ` richardvoigt 2010-02-12 7:08 ` Evgeny Kolesnikov 2 siblings, 2 replies; 19+ messages in thread From: Michal Suchanek @ 2010-02-11 13:30 UTC (permalink / raw) To: The development of GNU GRUB On 26 January 2010 11:04, Evgeny Kolesnikov <evgenyz@gmail.com> wrote: > Hi, > >> At first I was completely against antialiasing support because of >> performance impact. But it being optional decreases the later. However >> there is one problem: your patch relies on text_layer to be RGBA8888 >> which was a mistake. RGBA8888 for text layer is vastly inefficient >> especially on 16-bit framebuffer and CPUs with small cache. I had plans >> to switch it to indexed color. Do you really need 8bits and 4 aren't >> enough? > > I use 8-bit in order to give GRUB ability to look and feel exactly > as other parts of OS, so yes, 8 bits are required. If one can't allow Grub will never look and feel exactly as the OS unless you import GTK/QT, its themes, freetype, ... > this for his system - he can use 1-bit fonts. I don't really care about > such situation just because other parts of desktop on such a system will > be awful too. In fact I think that 4bit antialiasing should suffice. 16 tones of the same color should be more than enough for most cases. Still I am not sure that it will make the rendering really faster than 8bit AA. Only testing on various real hardware can possibly answer the question if and when one of the methods is faster. I would even expect that none is overall faster and that system exist where either is. Thanks Michal ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-02-11 13:30 ` Michal Suchanek @ 2010-02-12 6:21 ` richardvoigt 2010-02-12 6:48 ` Evgeny Kolesnikov 2010-02-12 7:08 ` Evgeny Kolesnikov 1 sibling, 1 reply; 19+ messages in thread From: richardvoigt @ 2010-02-12 6:21 UTC (permalink / raw) To: The development of GNU GRUB On Thu, Feb 11, 2010 at 7:30 AM, Michal Suchanek <hramrach@centrum.cz> wrote: > On 26 January 2010 11:04, Evgeny Kolesnikov <evgenyz@gmail.com> wrote: >> Hi, >> >>> At first I was completely against antialiasing support because of >>> performance impact. But it being optional decreases the later. However >>> there is one problem: your patch relies on text_layer to be RGBA8888 >>> which was a mistake. RGBA8888 for text layer is vastly inefficient >>> especially on 16-bit framebuffer and CPUs with small cache. I had plans >>> to switch it to indexed color. Do you really need 8bits and 4 aren't >>> enough? >> >> I use 8-bit in order to give GRUB ability to look and feel exactly >> as other parts of OS, so yes, 8 bits are required. If one can't allow > > Grub will never look and feel exactly as the OS unless you import > GTK/QT, its themes, freetype, ... > >> this for his system - he can use 1-bit fonts. I don't really care about >> such situation just because other parts of desktop on such a system will >> be awful too. > > In fact I think that 4bit antialiasing should suffice. 16 tones of the > same color should be more than enough for most cases. Still I am not > sure that it will make the rendering really faster than 8bit AA. By antialiasing it seems that you mean alpha channel. Has anyone considered instead supersampling in the x-direction? This also results in anti-aliased text but in addition yields more accurate kerning and on LCD displays can be used for sub-pixel rendering. I'd say 8x supersampling, but since LCD displays have three components (R,G,B) 6x might be better. > > Only testing on various real hardware can possibly answer the > question if and when one of the methods is faster. I would even expect > that none is overall faster and that system exist where either is. > > Thanks > > Michal > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-02-12 6:21 ` richardvoigt @ 2010-02-12 6:48 ` Evgeny Kolesnikov 0 siblings, 0 replies; 19+ messages in thread From: Evgeny Kolesnikov @ 2010-02-12 6:48 UTC (permalink / raw) To: The development of GNU GRUB On Fri, 2010-02-12 at 00:21 -0600, richardvoigt@gmail.com wrote: > On Thu, Feb 11, 2010 at 7:30 AM, Michal Suchanek <hramrach@centrum.cz> wrote: > > On 26 January 2010 11:04, Evgeny Kolesnikov <evgenyz@gmail.com> wrote: > >> Hi, > >> > >>> At first I was completely against antialiasing support because of > ... > > In fact I think that 4bit antialiasing should suffice. 16 tones of the > > same color should be more than enough for most cases. Still I am not > > sure that it will make the rendering really faster than 8bit AA. > > By antialiasing it seems that you mean alpha channel. > > Has anyone considered instead supersampling in the x-direction? This > also results in anti-aliased text but in addition yields more accurate > kerning and on LCD displays can be used for sub-pixel rendering. I'd > say 8x supersampling, but since LCD displays have three components > (R,G,B) 6x might be better. Sub-pixel AA is in progress. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-02-11 13:30 ` Michal Suchanek 2010-02-12 6:21 ` richardvoigt @ 2010-02-12 7:08 ` Evgeny Kolesnikov 2010-02-12 7:20 ` Bruce Dubbs 1 sibling, 1 reply; 19+ messages in thread From: Evgeny Kolesnikov @ 2010-02-12 7:08 UTC (permalink / raw) To: The development of GNU GRUB On Thu, 2010-02-11 at 14:30 +0100, Michal Suchanek wrote: > On 26 January 2010 11:04, Evgeny Kolesnikov <evgenyz@gmail.com> wrote: > > I use 8-bit in order to give GRUB ability to look and feel exactly > > as other parts of OS, so yes, 8 bits are required. If one can't allow > > Grub will never look and feel exactly as the OS unless you import > GTK/QT, its themes, freetype, ... GTK and QT uses FT for rendering fonts. Actually almost everything in linux desktop uses FT. grub-mkfont also uses FT to render common fonts formats into the PF2(3) format. So, GRUB2 will look and feel _exactly_ like GTK/QT in terms of _font_rendering_. Controls and other theming is out of scope of this patch and entire GRUB2 I suppose. Anyway - everything in QT/GTK is the bitmaps, drawn in some order. GRUB2 understands alpha channels in bitmaps, so everything is in the hands of GRUB2 theme designer. > > this for his system - he can use 1-bit fonts. I don't really care about > > such situation just because other parts of desktop on such a system will > > be awful too. > > In fact I think that 4bit antialiasing should suffice. 16 tones of the > same color should be more than enough for most cases. Still I am not > sure that it will make the rendering really faster than 8bit AA. > > Only testing on various real hardware can possibly answer the > question if and when one of the methods is faster. I would even expect > that none is overall faster and that system exist where either is. If we really care about speed we should use 1-bit fonts. Nothing can be faster. And 1-bit fonts will stay here. But if we care about eye-candy view, we should not throw away any bits from FT library result. This will not be fast enough to replace 1-bit fonts, and it will differ from other desktop apps. So, what the profit? You also may concern about font size itsef (15-30 Mb for sub-pixel AA), but who really care about it when 1 Tb HDD costs less than 100$? Also we can gzip entire font file later if it will really be the problem. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-02-12 7:08 ` Evgeny Kolesnikov @ 2010-02-12 7:20 ` Bruce Dubbs 2010-02-12 7:52 ` Evgeny Kolesnikov ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Bruce Dubbs @ 2010-02-12 7:20 UTC (permalink / raw) To: The development of GNU GRUB Evgeny Kolesnikov wrote: > If we really care about speed we should use 1-bit fonts. Nothing can be > faster. And 1-bit fonts will stay here. > > But if we care about eye-candy view, we should not throw away any bits > from FT library result. This will not be fast enough to replace 1-bit > fonts, and it will differ from other desktop apps. So, what the profit? > > You also may concern about font size itsef (15-30 Mb for sub-pixel AA), > but who really care about it when 1 Tb HDD costs less than 100$? Also we > can gzip entire font file later if it will really be the problem. Actually I don't understand why AA fonts are needed for a screen that most users will look at for about 3 seconds to select their OS and boot. I suspect most distros will set up grub to skip the GRUB screen completely. Is the effort worth the cost? I suppose doing it 'because you can' or because someone is 'scratching and itch' is OK, but I don't think it should be a major consideration. -- Bruce ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-02-12 7:20 ` Bruce Dubbs @ 2010-02-12 7:52 ` Evgeny Kolesnikov 2010-02-12 9:15 ` Michal Suchanek 2010-02-12 9:55 ` Vladimir 'φ-coder/phcoder' Serbinenko 2 siblings, 0 replies; 19+ messages in thread From: Evgeny Kolesnikov @ 2010-02-12 7:52 UTC (permalink / raw) To: The development of GNU GRUB On Fri, 2010-02-12 at 01:20 -0600, Bruce Dubbs wrote: > Evgeny Kolesnikov wrote: > > > If we really care about speed we should use 1-bit fonts. Nothing can be > > faster. And 1-bit fonts will stay here. > > > > But if we care about eye-candy view, we should not throw away any bits > > from FT library result. This will not be fast enough to replace 1-bit > > fonts, and it will differ from other desktop apps. So, what the profit? > > > > You also may concern about font size itsef (15-30 Mb for sub-pixel AA), > > but who really care about it when 1 Tb HDD costs less than 100$? Also we > > can gzip entire font file later if it will really be the problem. > > Actually I don't understand why AA fonts are needed for a screen that > most users will look at for about 3 seconds to select their OS and boot. > > I suspect most distros will set up grub to skip the GRUB screen completely. > > Is the effort worth the cost? I suppose doing it 'because you can' or > because someone is 'scratching and itch' is OK, but I don't think it > should be a major consideration. I can ask you only one thing: Bruce how your apartment's door is looks like? Is it a piece of rusted metal plate with number scratched out with screwdriver on it and wire soldered to use as handle? You use it only for reaching you home, 3-6 seconds (if you not drunk like a fish, of course :)... Anyway AA fonts completely optional. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-02-12 7:20 ` Bruce Dubbs 2010-02-12 7:52 ` Evgeny Kolesnikov @ 2010-02-12 9:15 ` Michal Suchanek 2010-02-12 9:55 ` Vladimir 'φ-coder/phcoder' Serbinenko 2 siblings, 0 replies; 19+ messages in thread From: Michal Suchanek @ 2010-02-12 9:15 UTC (permalink / raw) To: The development of GNU GRUB On 12 February 2010 08:20, Bruce Dubbs <bruce.dubbs@gmail.com> wrote: > Evgeny Kolesnikov wrote: > >> If we really care about speed we should use 1-bit fonts. Nothing can be >> faster. And 1-bit fonts will stay here. >> >> But if we care about eye-candy view, we should not throw away any bits >> from FT library result. This will not be fast enough to replace 1-bit >> fonts, and it will differ from other desktop apps. So, what the profit? I personally don't want antialiasing to make grub pixel equivalent of desktop applications but to get usable fonts at sizes different from 16px (or whatever unifont uses as it's the only fairly complete bitmap font we have). It turns out that rendering TrueType fonts into 1bit bitmaps yields glyphs that are ugly and in some cases quite unreadable. If 4bit bitmap improves this situation enough that we can get fonts of different sizes that don't cause people run away in horror then 4bits are good enough for me. >> >> You also may concern about font size itsef (15-30 Mb for sub-pixel AA), >> but who really care about it when 1 Tb HDD costs less than 100$? Also we >> can gzip entire font file later if it will really be the problem. > > Actually I don't understand why AA fonts are needed for a screen that most > users will look at for about 3 seconds to select their OS and boot. > > I suspect most distros will set up grub to skip the GRUB screen completely. > > Is the effort worth the cost? I suppose doing it 'because you can' or > because someone is 'scratching and itch' is OK, but I don't think it should > be a major consideration. > There are two reasons. First you cannot make a stylish boot screen with only single bitmap font. With grub legacy it turned out that some people would care enough that they would fork the bootloader just to get that so it is better if we can provide the feature in the main. The other reason is that in some cases you will see the grub menu for more than a few seconds. Some installation/live CDs would need to provide help texts and option selections before the system boots because selecting some options is vital for the system to booting at all on some hardware. Thanks Michal ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Antialiased fonts patch. 2010-02-12 7:20 ` Bruce Dubbs 2010-02-12 7:52 ` Evgeny Kolesnikov 2010-02-12 9:15 ` Michal Suchanek @ 2010-02-12 9:55 ` Vladimir 'φ-coder/phcoder' Serbinenko 2 siblings, 0 replies; 19+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2010-02-12 9:55 UTC (permalink / raw) To: The development of GNU GRUB [-- Attachment #1: Type: text/plain, Size: 1527 bytes --] Bruce Dubbs wrote: > Evgeny Kolesnikov wrote: > >> If we really care about speed we should use 1-bit fonts. Nothing can be >> faster. And 1-bit fonts will stay here. >> >> But if we care about eye-candy view, we should not throw away any bits >> from FT library result. This will not be fast enough to replace 1-bit >> fonts, and it will differ from other desktop apps. So, what the profit? >> >> You also may concern about font size itsef (15-30 Mb for sub-pixel AA), >> but who really care about it when 1 Tb HDD costs less than 100$? Also we >> can gzip entire font file later if it will really be the problem. > > Actually I don't understand why AA fonts are needed for a screen that > most users will look at for about 3 seconds to select their OS and boot. > > I suspect most distros will set up grub to skip the GRUB screen > completely. > > Is the effort worth the cost? I suppose doing it 'because you can' or > because someone is 'scratching and itch' is OK, but I don't think it > should be a major consideration. > I agree with you. Same is true for the whole gfxmenu. However for some esoteric reasons people care. But on the other hand anitaliasing may improve readability of complex rendered system e.g. diacritics, vowel marks and Indic scripts > -- Bruce > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 293 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2010-02-12 9:56 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-21 13:19 grub-mkfont and DejaVu font problems Evgeny K
2010-01-21 13:28 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-22 11:46 ` Antialiased fonts patch Evgeny Kolesnikov
2010-01-22 12:53 ` BVK Chaitanya
2010-01-22 13:22 ` Evgeny Kolesnikov
2010-01-26 9:11 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-26 10:04 ` Evgeny Kolesnikov
2010-01-26 11:59 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-26 19:44 ` Carles Pina i Estany
2010-02-11 2:58 ` Vladimir 'φ-coder/phcoder' Serbinenko
[not found] ` <1265957146.2292.11.camel@EK>
2010-02-12 9:50 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-02-11 13:30 ` Michal Suchanek
2010-02-12 6:21 ` richardvoigt
2010-02-12 6:48 ` Evgeny Kolesnikov
2010-02-12 7:08 ` Evgeny Kolesnikov
2010-02-12 7:20 ` Bruce Dubbs
2010-02-12 7:52 ` Evgeny Kolesnikov
2010-02-12 9:15 ` Michal Suchanek
2010-02-12 9:55 ` Vladimir 'φ-coder/phcoder' Serbinenko
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.