60 replies to this topic

[tinybit]

NO, he introduced a complication of the concept

 

Consider this: how would you recommend yaya to do with 10x20 ASCII fonts? For the 10-dot row of a char, you must use a byte and half a nibble.

 

And yaya decided to use hexa digits in the font file. I would rather believe that the decision was an effort to conform to the original concept.

 

 

As said this is perfectly OK, it is not a problem at all as long as a "same extension" is NOT used.

 

It might be also OK and also "not a problem" even if the same extension is used, considering the world is diversified, not monophyletic. There is no absoluteness in anything. Compare with this:

 

MS uses EXE for DOS executable. But in Windows, it still use the same extension.

 

It is just not wrong doing such a thing.

[steve6375]

Good job! I tried this with E2B and all seems OK even Russian.

I like the bold one the best.

Can you explain how you made these please?

 

Attached Thumbnails

• 
• 

[Wonko the Sane]

@tinybit

I won' t start with you another Billy Bob discussion, names are there to distinguish things one from the other, the .hex extension is also used for some HUGO games:

http://filext.com/file-extension/HEX

What gives?

 

In the context of fonts, the .hex extension is linked to the original format used by Roman Czyborra, BTW already used in grub4dos for the "normal" 8x16 fonts.

 

If you are happy with this approach, as said you are very welcome to be happy and also proud about it, but don't try convincing me that the used approach is in any way "smart" or "simple".

 

 

@Steve

WHAT is "this"? 

 

Wonko

[tinybit]

If you are happy with this approach

I am not happy with it, and not unhappy with it.

proud about it

I am not proud about it, and not unproud about it.

I simply feel that it is acceptable, no good, no bad. Besides, I think I can accept almost every thing, including any possible counterviews.

don't try convincing me

I had never tried that, just like you'd never. And I will never try that.

I only tried to share my opinion, although I don't know whether or not I had successfully shared my opinion.

And I know that you have helped others greatly, including helped me very very much. Yes, you were helping others, not convincing them. And I want to do the same thing(I mean "to help others"), but now I am in doubt if I am able to do it.

[Wonko the Sane]

I only tried to share my opinion, although I don't know whether or not I had successfully shared my opinion.

 
Sure you have shared your opinion alright , and it has been duly recorded.
 
I consider it as a lucid, intelligent, well thought-out objection.
http://www.imdb.com/...?item=qt0404534

 
Back to randomly parsing .bdf files and recklessly converting them in .shex files , another set of fonts from:
http://gnu.mirrors.p...onts-1.2-split/
http://gnu.mirrors.p...European.tar.gz

lt1-24-etl
lt1-24b-etl
lt1-24bi-etl
lt1-24i-etl

And from the X11 (an Apple version):
https://opensource.a...fonts/bdf/misc/
https://opensource.a.../misc/12x24.bdf

X11_12x24
 

Wonko

EDIT: attachment removed, new version a few posts below:
http://reboot.pro/to...e-2#entry198301

[tinybit]

@Wonko

 

Yes, your opinion is very important and helpful to me. I remember that last time I wanted to add an option to makeactive. With reference to your opinion, I finally changed my mind. Now, I am no longer a maintainer, even not a developer any more. So I will not make any decision about grub4dos.

[steve6375]

ETLx11.zip .shex files not working. X11 almost works but some bad characters e.g.  0031 hex '1'

ETL ones all not working at all?

[Wonko the Sane]

ETLx11.zip .shex files not working. X11 almost works but some bad characters e.g.  0031 hex '1'

ETL ones all not working at all?

Well, they were made with the same approach, the files - ultimately - are n lines in the form of:

<char code: 2 bytes textual representation>:<Char binary: 48 hex bytes textual representation>

They do work with the same showchar batch, what do you mean "wrong character"?

D:\Font_bitmap\New_version>Showchar12x24.cmd X11_12x24.shex 31
0031:0000000006000e001e007e00060006000600060006000600060006000600060006000600060
0060006003fc000000000
Narrow
............ 0x000
............ 0x000
.....@@..... 0x060
....@@@..... 0x0e0
...@@@@..... 0x1e0
.@@@@@@..... 0x7e0
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
.....@@..... 0x060
..@@@@@@@@.. 0x3fc
............ 0x000
............ 0x000

Maybe there is some "non-printable" character in the X11_12x24.bdf  that *somehow* creates issues in the grub4dos font parser?

 

I had to change the parsing mechanism because some of the .bdf files have not last nibble (in a four nibble set) at 0.

As an example in lt1-24bi-etl.bdf there is a 1ff8 in the "dollar sign" 0x24, and two 1ff8's in lt1-24i-etl.bdf in the character "Macron" 0xAF, but they are still "narrow" characters.

 

 

 

Spoiler

D:\Font_bitmap\New_version>Showchar12x24.cmd lt1-24bi-etl.shex 24
0024:0000000000000000000003800fe01ff8777077003f001fc00fc00ee00ee0eee0ff80ff001c0
000000000000000000000
Narrow
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
......@@@... 0x038
....@@@@@@@. 0x0fe
...@@@@@@@@@ 0x1ff
.@@@.@@@.@@@ 0x777
.@@@.@@@.... 0x770
..@@@@@@.... 0x3f0
...@@@@@@@.. 0x1fc
....@@@@@@.. 0x0fc
....@@@.@@@. 0x0ee
....@@@.@@@. 0x0ee
@@@.@@@.@@@. 0xeee
@@@@@@@@@... 0xff8
@@@@@@@@.... 0xff0
...@@@...... 0x1c0
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000

D:\Font_bitmap\New_version>Showchar12x24.cmd lt1-24i-etl.shex AF
00AF:1ff81ff80000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000
Narrow
...@@@@@@@@@ 0x1ff
...@@@@@@@@@ 0x1ff
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000
............ 0x000

 

Wonko

[steve6375]

I think the non-printable nibble is being printed - it needs to be 0?

[Wonko the Sane]

I think the non-printable nibble is being printed - it needs to be 0?

Well, my half-@§§ed showchar batch simply ignores last nibble every 4, it is well possible that the grub4dos font parser uses another mechanism.

If you compare my previous parseBDF12x24.cmd against the parseBDF12x24new.cmd you will notice how originally I used the last nibble to determine if the line was part character definition (as last nibble should always be 0) and I had to change approach because of those few 1ff8's.

 

Wonko

[steve6375]

0031:0000000006000e001e007e000600060006000600060006000600060006000600060006000600060006003fc000000000

is from x11 font and does not work (just a few dots in the character)

 

if i replace the 6 with 0

0031:0000000000000e001e007e000600060006000600060006000600060006000600060006000600060006003fc000000000

 

this does display correctly (but the top pixel is missing)

 

so maybe the first three top rows need to be 0000 ??

[steve6375]

Found the problem - you need to use uppercase!!!

[Wonko the Sane]

0031:0000000006000e001e007e000600060006000600060006000600060006000600060006000600060006003fc000000000

is from x11 font and does not work (just a few dots in the character)

 

if i replace the 6 with 0

0031:0000000000000e001e007e000600060006000600060006000600060006000600060006000600060006003fc000000000

 

this does display correctly (but the top pixel is missing)

 

so maybe the first three top rows need to be 0000 ??

Well, then that is a bug in the grub4dos font parser, if the first three rows must be 0, it is not anymore a 24 tall font but a "shifted down 21 tall font" , the "relevant" nibbles are:

0031:0000000006000e001e007e00060 ...

as the showchar shows.

BTW a number of characters have "1's" in the top three rows

 

Found the problem - you need to use uppercase!!!

Uppercase in what? The hex representation?

 

Wonko

[steve6375]

yes, works fine then! You had uppercase in previous version.

[steve6375]

Test with 0.4.6a  2016-03-04

 

due to bug, you need to switch to 16 high font so new 24 high font will load (I use unifont.hex.gz)

graphicsmode -1 1024
pager off

title font font12x24c
font
font --font-high=16 /_ISO/e2b/grub/unifont.hex.gz
font --font-high=24 /font12x24c.shex
errorcheck off
boot
title font lt1-24b-etl.shex
font
font --font-high=16 /_ISO/e2b/grub/unifont.hex.gz
font --font-high=24 /lt1-24b-etl.shex
errorcheck off
boot
title font lt1-24bi-etl
font
font --font-high=16 /_ISO/e2b/grub/unifont.hex.gz
font --font-high=24 /lt1-24bi-etl.shex
errorcheck off
boot
title font lt1-24-etl
font
font --font-high=16 /_ISO/e2b/grub/unifont.hex.gz
font --font-high=24 /lt1-24-etl.shex
errorcheck off
boot
title font lt1-24i-etl
font
font --font-high=16 /_ISO/e2b/grub/unifont.hex.gz
font --font-high=24 /lt1-24i-etl.shex
errorcheck off
boot

title font X11_12x24
font
font --font-high=16 /_ISO/e2b/grub/unifont.hex.gz
font --font-high=24 /X11_12x24.shex
errorcheck off
boot

[Wonko the Sane]

yes, works fine then! You had uppercase in previous version.

Well, it's the result of GIGO, I didn't change the CaSe of hex value representation, "in previous version" they were already capital letters.
I could use cmd /c and Exitcode to convert to uppercase but the batch will become as slow as molasses (not that it is particularly fast "as is").
I'll do a couple of tests for a faster CAPITALIZATION routine (without using third party tools such as gsar).


Wonko

[steve6375]

OK, I have reported it as an issue but I guess it depends on what format was specified for it....

[Wonko the Sane]

Yep, and of course we would need to enter the domain on the actual .bdf specifications too.
Anyway I am attaching a new ETLX11 archive with newly generated (ALL CAPITALS) .shex files and an updated parsing batch, this one additionally sets 4th nibble to 0, regardless what the source has (just in case).


Wonko

Attached Files

•  ETLX11_2.zip   44.95KB   432 downloads

[steve6375]

Many thanks Wonko for your batch files and work. Great work!

I have slightly modified them and uploaded them here.

I have called the hex file .f24 (just to be different!) and added then to Easy2Boot.

The small changes I made are just to allow upper or lower case when specifying a character number - e.g. 00fc, and add some Usage messages.

Thanks again!

Steve

P.S. Latest version of grub4dos accepts lower case in hex files now too!

Edited by steve6375, 09 March 2016 - 10:07 PM.

[paraglider]

With this new version do you expect existing menus to work? I find that splashimage no longer displays the image.

[steve6375]

There are still bugs. Try latest version.

http://grub4dos.chen....6a-2016-03-10/

 

See Issues list

https://github.com/c...grub4dos/issues

[paraglider]

Already tried that version. Here is 2 different versions of grldr (grub4dos-0.4.6a-2015-12-31.7z and e:\Zip\grub4dos-0.4.6a-2016-03-10.7z)

 

 

 

 

 

[steve6375]

What is at the top of your menu.lst ??

What is the exact pixel size of the background?

[steve6375]

In Issue 104 there is my download https://github.com/c...95-104_DEMO.zip

Inside is a version of grldr that should work now with your menu.

It will be fixed in next version of grub4dos (and hopefully a bunch of other bugs too!)

[paraglider]

Thanks. That fixed it.