Jump to content











Photo
- - - - -

grub4dos 0.4.6a supports large fonts


  • Please log in to reply
60 replies to this topic

#1 steve6375

steve6375

    Platinum Member

  • Developer
  • 6350 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 03 March 2016 - 09:18 PM

Recent versions support larger fonts than the standard 8 pixel high fonts.

I have found two 24-pixel high hex font files on the grub4dos forum and added these to the latest version of Easy2Boot v1.78 Beta.

font --font-high=24 /sft.hex

The problem is that this only has ASCII characters 0020 to 007F, a few characters between 0080 and 00FF and then a large number of Chinese glyphs (sft.hex and yxt.hex).

 

So at the moment, it does not support European and other languages that use characters with accents, sedillas, etc. - we just get a space character instead!

 

I have Googled until my Fu has burst, but can't find a fuller set of 24 pixel height fonts in hex format (or binary) or any clue on how to easily make them - any help appreciated....



#2 tinybit

tinybit

    Gold Member

  • Developer
  • 1044 posts
  •  
    China

Posted 04 March 2016 - 01:48 AM

the standard 8 pixel high fonts

 

The normal font used by grub4dos is 16-pixel high and 8-pixel wide(for "narrow" ASCII chars). A "wide" character(e.g., a Chinese glyph) normally takes up 16x16 bits of room.

 

Yaya's 0.4.6a supports fonts upto 32x32.

 

or any clue on how to easily make them

 

I think those who created sft.hex or yxt.hex can do the job.


  • steve6375 likes this

#3 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 March 2016 - 10:07 AM

Are they still "unifont"?

http://reboot.pro/to...menu-font-type/

 

:duff:

Wonko



#4 tinybit

tinybit

    Gold Member

  • Developer
  • 1044 posts
  •  
    China

Posted 04 March 2016 - 01:29 PM

TrueType Unifont:

http://unifoundry.com/unifont.html

 

I think it is possible to create 24x24 or 32x32 hex unifont from the TTF, maybe, by using a utility or a converter.



#5 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 March 2016 - 03:51 PM

@Steve

I am not going to download latest version of Easy2Boot v1.78 Beta, can you post  link to the actual font file?

 

@tinybit

I provided a link to a suitable tool, used somewhat successfully in the past (TTF imported fonts usually look very ugly), but I have to understand what format the actual sft.hex and yxt.hex use (i.e. how grub4dos supports non 8x16 fonts), the previous versions used the .hex format, with a width of either 8 or 16:

https://en.wikipedia...hex_font_format

What is the new format that grub4dos uses for larger fonts?

 

:duff:

Wonko



#6 steve6375

steve6375

    Platinum Member

  • Developer
  • 6350 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 04 March 2016 - 03:59 PM

in grub4dos, type

 

help font

 

I found a bdf2hex.exe program, but no 24 pixel bdf files.

Not sure how to make a 24 pixel bdf file from a font file...

Attached Files

  • Attached File  sft.7z   278.71KB   130 downloads

Edited by steve6375, 04 March 2016 - 04:01 PM.


#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 March 2016 - 04:34 PM

in grub4dos, type

 

help font

Why should I?

Can't you post the output (if relevant)?

 

It seems like the good guys "extended" the .hex font format by adding more bytes, the sft.hex file entry for "A":

0041:00000000000000000000060006000E000B000B0013001180118011801F8020C020C020C020606060F0F0000000000000

compared to the file entry in "unifont.hex":

0041:0000000018242442427E424242420000

 

The unifont .hex original format has 1 byte (8 bit) for each line and 16 lines, hence the values are 16 bytes long.

 

This one has 48 bytes per character, if it uses 3 bytes for each line (i.e. 24 bits), for 24 lines the values should be 3*24=72 bytes long  :unsure:

Otherwise it can be either a 2 byte per line * 24 lines or a 3 byte per line * 16 lines.

Or am I missing something?  :dubbio:

 

:duff:

Wonko



#8 steve6375

steve6375

    Platinum Member

  • Developer
  • 6350 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 04 March 2016 - 04:46 PM

normal characters are 24 high by 16 wide, later characters are Chinese glyphs 24x24

??

Attached Thumbnails

  • Capturefont.JPG


#9 steve6375

steve6375

    Platinum Member

  • Developer
  • 6350 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 04 March 2016 - 05:19 PM

=  is 3D

003D:00000000000000000000000000000000000000007FE000000000000000007FE000000000000000000000000000000000

 

This produces a glyph with 5 horizontal lines

003D:7FE000000000000000000000000000007FE07FE000000000000000007FE000000000000000000000000000007FE00000

 

so it is 4 nibbles per row but it ignores 4th nibble?

 

must be 12 pixels across for thin characters?

S



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 March 2016 - 07:39 PM

Yep, the original idea of unifont was that a character was either a single cell one or a double cell one:
http://czyborra.com/unifont/
 

Do you intend to squeeze my favorite ideograph into an 8x16 pixel cell?

I did not say constant width! If we wanted the character cell to be big enough to also draw any ideograph with more than 4 vertical strokes in it, we would end up with cells at least 14 or 16 pixel wide. Such a huge cell would be way oversized for Latin letters and the usual row of 80 cells would no longer fit in a 640 pixel screen width.

Instead, I would like to follow the example of traditional CJK terminals like kterm or cxterm and distinguish halfwidth (ASCII) characters occupying one cell each from fullwidth (CJK) characters occupying exactly two consecutive cells. This makes the font somehow proportional (more complex characters get more space) and fixed-pitch (the cell grid is respected) at the same time. Markus Kuhn calls this a "bi-width" font and suggests to register a SPACING "b" label for this.

The question whether a given character must be halfwidth or fullwidth becomes a bit harder to decide than it was with the EUC codes where each character encoded in two bytes also occupied two cells even if that looked crummy. The Draft Unicode Technical Report 11 on East Asian Character Width does not do much more than to acknowledge the ambiguity for many characters.

8x16 appears to be the best choice for the character cell size since 8 and 16 are round numbers in the binary world and we can resort to existing 8x16 halfwidth and 16x16 fullwidth fonts, height 16 is tall enough to allow even stacked diacritics, and width 8 is just small enough to fit 80 halfwidth characters in one 640 pixel screen width.
Do we really need yet another font format?

I think that this little unifont project will benefit from a simple non-standard font description. My criticism of the standard BDF (Adobe's famous Bitmap Distribution Format) is that it is neither as human-readable and -editable as it said it would be (BDF fonts simply contain too many cryptic numbers which prompted the design of BDF editors like xfed, xfedor, xmbdfed in the first place) nor as fast and compressed as the Hanzi Bitmap Format HBF nor so handy that you can easily merge glyphs from various sources. I do not care to fetch mails through my modem containing 5 megabytes of unifont.bdf every time anybody has updated a couple of glyphs, nor to have diff -c patches fail because the context has changed in the meantime. HBF is not suited either because it swaps its bitmaps into external binary files that cannot be split, joined or edited with a plain text editor, and it requires special software installations.

My unifont file merely consists of lines each of which defines a glyph in the most trivial way: A hexadecimal number announces the Unicode character to be covered. And a colon separates it from the joined hexadecimal representation of the glyph's bitmap's horizontal scan lines:

0040:000000001C224A565252524E201E0000
0041:0000000018242442427E424242420000
4E21:000000007FFC010001003FF8210829282928292829282FE82828200820180000

Note that the final fullwidth glyph is easily distinguished from the halfwidth glyphs as its bit pattern is twice as long (64 hexdigits).

The original unifont which is 8x16 thus has each character coded as one byte per line (8 bit per line) * 16 lines or double that amount.
In the sfz.hex characters are either 48 bytes or 72 bytes (should be 96) which should mean that it deviates from the original concept (besides not being anymore 8x16).

:duff:
Wonko

#11 steve6375

steve6375

    Platinum Member

  • Developer
  • 6350 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 04 March 2016 - 09:36 PM

yeah, the 1xxx+ lines are weird. I tried one as 003D and it did not 'take', so grub4dos does not seem to like it as a <0100 character.

And also it should be longer than it is.

Still, I luckily don't need to worry about those, it is mainly the extended Latin1 character set that is needed...



#12 tinybit

tinybit

    Gold Member

  • Developer
  • 1044 posts
  •  
    China

Posted 05 March 2016 - 12:55 AM

yeah, the 1xxx+ lines are weird. I tried one as 003D and it did not 'take', so grub4dos does not seem to like it as a <0100 character.


It should be a bug. I think you may report it.

In 0.4.5c, the ASCIIes (00-7F) are all narrow chars. Grub4dos will refuse a font line that tries to set an ASCII char as wide(if you do it, the font line will be simply ignored, thus it will not function). But Others(80-FFFF) can be narrow or wide, according to the font line(not according to the unicode value). Each unicode char >= 0x80 can be set as narrow by using a "narrow" line, and can also be set as wide by using a "wide" line for it. All chars are defaulted to be narrow, including chars >= 0x80. A font line can be used to (at will, freely) change a char(>= 0x80) from narrow to wide, or from wide to narrow.

I guess in yaya's 0.4.6a, he might treat all the 80-FFFF chars as wide, and refuse a "narrow" font line. That is wrong(in my opinion).

 

The original unifont which is 8x16 thus has each character coded as one byte per line (8 bit per line) * 16 lines or double that amount.
In the sfz.hex characters are either 48 bytes or 72 bytes (should be 96) which should mean that it deviates from the original concept (besides not being anymore 8x16).

 

Obviously yaya extended/broke the original concept. Yes, it is a deviate behavior. But one might also think it as a must.

 

As Steve explained, for narrow chars, he uses 4 nibbles for a row and ignore the last nibble. So the dot array of the char occupies 2 bytes * 24 rows = 48 bytes of room. For wide chars, he uses 6 nibbles(=3 bytes) for a row. So this will occupy 3*24=72 bytes, meaning 144 hex digits.

 

Besides 24x24 font, yaya also supported 20x20 font.



#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 March 2016 - 09:16 AM

Well, with all due respect to all the people involved :), the original concept by Roman Czyborra is simple and linear, this is insanely made complex for no real reason if not to save what a bunch of bytes?

 

In the original format 1 byte=8 bit=8 "dots positions"=1 line

 

How the heck one can in 4 nibbles=2 bytes=16 bits express 24 dots positions is totally unclear to me :unsure: and I also ccould not understand the "last nibble" excluded  :w00t:

The character is maybe then really 12 "dots" wide 

 

The same goes for the "wide" characters, original format had 1 "grid" wide character OR a 2 grids wide one, wide thus being the double of the narrow, this one has seemingly wide character 1.5 the size of the narrow.

 

The narrow character is maybe then really 12 "dots" wide so that 3 nibbles = 1.5 bytes = 12 bits = 12 "dots" and the double one is 24 "dots" wide so that 6 nibbles=3 bytes = 24 bits = 24 "dots".

Then the "narrow" character should be 1.5*24=36 bytes long.

 

In other words the original format could be easily rendered by binary notation, this one needs a special rule to ignore every fourth nibble, but only on narrow characters, if I get this right.

 

 

But it is alright, as this is none of my business, being a clear example of SEP:

https://en.wikipedia..._Else's_Problem

 

However everything is good and fine :thumbsup: if the scope is to design (senselessly) a "own format", incompatible with anything designed till now :frusty:, and requiring new code to create/adapt fonts, but at least a different extension should be given to it, not the .hex as this will likely trick many people.

 

:duff:

Wonko



#14 steve6375

steve6375

    Platinum Member

  • Developer
  • 6350 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 05 March 2016 - 09:31 AM

yeah, the 1xxx+ lines are weird. I tried one as 003D and it did not 'take', so grub4dos does not seem to like it as a <0100 character.

And also it should be longer than it is.

Still, I luckily don't need to worry about those, it is mainly the extended Latin1 character set that is needed...

 

What I mean is I tried

 

003D:000000000000000000004200004200004200004200004200004200004200004200004200004200004200004200004200004200004200004200004200004200004200004200000000

 

and it did not change the = character. So if <0080 is thin characters, this is expected behaviour.



#15 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 March 2016 - 01:27 PM

For NO apparent reason, attached are a couple half-@§§ed batches and a "translation" (maybe) with the .shex extension, of this font here:

https://github.com/i...er/font-12x24.c



D:\Font_bitmap\New_version>Showchar12x24.cmd font12x24c.shex
no Char was specified assuming Char 0041 "A"
0041:000000000000030003000780078007800CC00CC00CC00CC0186018601FE0186030303030303
030300000000000000000
Narrow
............ 0x000
............ 0x000
............ 0x000
......@@.... 0x030
......@@.... 0x030
.....@@@@... 0x078
.....@@@@... 0x078
.....@@@@... 0x078
....@@..@@.. 0x0CC
....@@..@@.. 0x0CC
....@@..@@.. 0x0CC
....@@..@@.. 0x0CC
...@@....@@. 0x186
...@@....@@. 0x186
...@@@@@@@@. 0x1FE
...@@....@@. 0x186
..@@......@@ 0x303
..@@......@@ 0x303
..@@......@@ 0x303
..@@......@@ 0x303
............ 0x000
............ 0x000
............ 0x000
............ 0x000

:duff:

Wonko

Attached Files



#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 March 2016 - 02:17 PM

And another one, this time it is the Developer Bold from:

https://powerman.name/config/font.html

https://powerman.name/download/font/

https://powerman.nam...er-font-1.6.tgz









D:\Font_bitmap\New_version>Showchar12x24.cmd devbold.shex 42
0042:000000000000FF80FFC060E060606060606060607FC07FC0606060606060606060E0FFC0FF8
000000000000000000000
Narrow
............ 0x000
............ 0x000
............ 0x000
@@@@@@@@@... 0xFF8
@@@@@@@@@@.. 0xFFC
.@@.....@@@. 0x60E
.@@......@@. 0x606
.@@......@@. 0x606
.@@......@@. 0x606
.@@......@@. 0x606
.@@@@@@@@@.. 0x7FC
.@@@@@@@@@.. 0x7FC
.@@......@@. 0x606
.@@......@@. 0x606
.@@......@@. 0x606
.@@......@@. 0x606
.@@.....@@@. 0x60E
@@@@@@@@@@.. 0xFFC
@@@@@@@@@... 0xFF8
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000

:duff:

Wonko


Edited by Wonko the Sane, 05 March 2016 - 04:03 PM.
Removed attachment, see a few posts below


#17 tinybit

tinybit

    Gold Member

  • Developer
  • 1044 posts
  •  
    China

Posted 05 March 2016 - 02:31 PM

duplicate post. deleted.

#18 tinybit

tinybit

    Gold Member

  • Developer
  • 1044 posts
  •  
    China

Posted 05 March 2016 - 02:33 PM

@Wonko
'things about font format' is not equal to 'things about the memory layout in grub4dos'.

the former is external format, the latter is internal format.

grub4dos can convert font lines to internal char patterns.

So don't worry about the issue of memory occupancy factor.

and don't worry about how to determine the actual number of dots used.

it defaults to 16 dots, meaning 8x16 for narrow, and 16x16 for wide chars.

otherwise, the user must specify it in the menu.lst with DotSize=?

I believe yaya had done his best on the font format issue.

he just aligned/rounded the 1.5 bytes to 2 bytes.

he kept the simplicity of concept.

#19 steve6375

steve6375

    Platinum Member

  • Developer
  • 6350 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 05 March 2016 - 02:35 PM

Thanks for the fonts, but something is not working.

Characters 80-FF don't seem correct.

 

Maybe it is a bug in grub4dos?

Attached Thumbnails

  • CaptureWonkofont.PNG


#20 steve6375

steve6375

    Platinum Member

  • Developer
  • 6350 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 05 March 2016 - 02:51 PM

lowercase umlaut u  in UTF-8 is C3BC =   252.  ü  (in  Windows ALT+0252)

 

You have 252 00FC: as superscript n in your font file.

 

http://www.theasciic...i-code-129.html

Attached Thumbnails

  • CaptureC3BC.PNG


#21 tinybit

tinybit

    Gold Member

  • Developer
  • 1044 posts
  •  
    China

Posted 05 March 2016 - 03:01 PM

Thanks for the fonts, but something is not working.
Characters 80-FF don't seem correct.

Maybe it is a bug in grub4dos?

Are you sure you have used the correct utf-8 encoding for the menu.lst?

Each Unicode > 0x7F will be multibyte in utf-8, no longer a single byte.

Edit ---- no problem, after seeing your post.

#22 steve6375

steve6375

    Platinum Member

  • Developer
  • 6350 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 05 March 2016 - 03:04 PM

Here is same file with unifont.hex.gz loaded

 

Attached Thumbnails

  • CaptureC3BCUNIFONT.PNG


#23 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 March 2016 - 03:12 PM

@Wonko
'things about font format' is not equal to 'things about the memory layout in grub4dos'.

the former is external format, the latter is internal format.

grub4dos can convert font lines to internal char patterns.

So don't worry about the issue of memory occupancy factor.

and don't worry about how to determine the actual number of dots used.

it defaults to 16 dots, meaning 8x16 for narrow, and 16x16 for wide chars.

otherwise, the user must specify it in the menu.lst.()

I believe yaya had done his best on the font format issue.

he just aligned/rounded the 1.5 bytes to 2 bytes.

he kept the simplicity of concept.

NO, he introduced a complication of the concept, the original format always considers a byte as a binary number, both for "narrow" and "wide" characters, the "new format" uses 3 nibbles for the narrow but writes them down as 4 nibbles of which one is to be ignored, and 6 nibbles (of which none is to be ignored) for the "wide" characters.
As said this is perfectly OK, it is not a problem at all as long as a "same extension" is NOT used.
The sheer moment the same .hex extension is used the approach is "wrong".

@Steve
Or more probably my small batches are more @§§ed than expected :w00t: :ph34r: or maybe the source font has issues :unsure:

The half-@§§ed batches were just quickly put together to allow some playing with them.

It is interesting how I posted tentatively two fonts, one called  font12x24c.shex and one called devbold.shex and you reported about a "Wonko24 font", I guess we are at the same level of simplicity.

The font12x24c.shex seems looking fine in Showchar12x24.cmd maybe there are some of the usual issues with codepage / character encoding (besides possible issues with the batches) in non ASCII 7 bit 0-127 characters. 

I did not check what the original fonts use nor what grub4dos expects.

The font12x24c.shex uses seemingly this table:

http://www.asciitable.com/



D:\Font_bitmap\New_version>Showchar12x24.cmd font12x24c.shex FC
00FC:0000000000003F0039803180318031803180000000000000000000000000000000000000000
000000000000000000000
Narrow
............ 0x000
............ 0x000
............ 0x000
..@@@@@@.... 0x3F0
..@@@..@@... 0x398
..@@...@@... 0x318
..@@...@@... 0x318
..@@...@@... 0x318
..@@...@@... 0x318
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000

The devbold seemingly uses this one:

http://www.theasciic...i-code-252.html

D:\Font_bitmap\New_version>Showchar12x24.cmd devbold.shex FC
00FC:0000000000003F807FC0E0E0C060C06000600C600FE00FE00C600060C060C060E0E07FC03F8
000000000000000000000
Narrow
............ 0x000
............ 0x000
............ 0x000
..@@@@@@@... 0x3F8
.@@@@@@@@@.. 0x7FC
@@@.....@@@. 0xE0E
@@.......@@. 0xC06
@@.......@@. 0xC06
.........@@. 0x006
....@@...@@. 0x0C6
....@@@@@@@. 0x0FE
....@@@@@@@. 0x0FE
....@@...@@. 0x0C6
.........@@. 0x006
@@.......@@. 0xC06
@@.......@@. 0xC06
@@@.....@@@. 0xE0E
.@@@@@@@@@.. 0x7FC
..@@@@@@@... 0x3F8
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000

or maybe a completely different one.

:duff:

Wonko



#24 tinybit

tinybit

    Gold Member

  • Developer
  • 1044 posts
  •  
    China

Posted 05 March 2016 - 03:53 PM

What grub4dos expects is here: http://www.unicode.org/charts/


Basic Latin (ASCII): http://www.unicode.o...s/PDF/U0000.pdf
Latin-1 Supplement: http://www.unicode.o...s/PDF/U0080.pdf

#25 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 March 2016 - 04:01 PM

Ok, I checked, I wrongly parsed the koi8 (whatever it is) version of the developer bold, I am attaching now the "u" version.

Still a number of codes are missing. :unsure:







D:\Font_bitmap\New_version>Showchar12x24.cmd dev-u24n.shex FC
00FC:0000000000000000110011001100000040404040404040404040404040404040404020401FC
000000000000000000000
Narrow
............ 0x000
............ 0x000
............ 0x000
............ 0x000
...@...@.... 0x110
...@...@.... 0x110
...@...@.... 0x110
............ 0x000
.@.......@.. 0x404
.@.......@.. 0x404
.@.......@.. 0x404
.@.......@.. 0x404
.@.......@.. 0x404
.@.......@.. 0x404
.@.......@.. 0x404
.@.......@.. 0x404
.@.......@.. 0x404
..@......@.. 0x204
...@@@@@@@.. 0x1FC
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000

I am attaching also a test with the Terminus font:

https://sourceforge..../terminus-font/

 

:duff:

Wonko

 

 

Attached Files






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users