Thanks jmg, I appreciate your help with this... I do see the smearing... Definitely a bug...
Sounds like you want the insert/copy row/column feature at the character level...
I can see about a right-click popup menu to insert blank/instert copy row/column...
Ok, I think I've fixed that smearing and also made steps for being compatible with 24-bit color.
Also, I've added import for the Propeller text font used in the Rayslogic.com Adafruit RGB array driver.
It could already export in a compatible format (at least I think, haven't actually tried it).
I think it works if you paste the 255 lines, each starting with the word "byte" and then hit OK.
Hmm... Somehow matrix import got sent to position #2 and xml to position #3 and that gives matrix import a ".lcd" default and xml a ".txt" default... Have to fix that...
Ok, here's the latest version. Fixed problems from last time and added some row/column functions in the editor.
To use them, check "enable" and then click to the right or bottom of the character in edit mode.
Also, I've added a Propeller ROM font compatible export option for 16x32 pixel fonts.
Ok, here's the latest version. Fixed problems from last time and added some row/column functions in the editor.
To use them, check "enable" and then click to the right or bottom of the character in edit mode.
Wow - Works very nicely !! I can 'fit' any imported font, very quickly now.
The operation method is a little hidden, and needs more visual hints.
If the mouse-active area could toggle with the Enable tick, casual users would not need to read the manual ?
If adding that sort of visual hint is too much effort, an alternative could be to borrow the Right/left mouse actions, and change the hint message when Row/Col ops are Enabled.
Choice then would be
LMB=row, RMB=Col, toggle on Clone/Cut
or
LMB=Clone, RMB=Cut, toggle on Row/Col
The second one is closer to the standard edit model, where LMB 'adds', and RMB 'removes' ?, and gives a more live 'undo' ?
I'd also expect more clone.clone.cut.clone type steps, than Row/Col so having both live is less mouse work.
{ import for the Propeller text font used in the Rayslogic.com Adafruit RGB array}
I think it works if you paste the 255 lines, each starting with the word "byte" and then hit OK.
I may have misunderstood this. I thought you meant it was inbuilt/pre-compiled, but I think I needed the font file to import ?
I've been thinking a bit about how to handle variable pitch fonts with variable sized character data and also 4, 8, or 24 bit fonts...
The deeper bit depths will probably have to be on SD or Flash...
Think I've decided that the easiest way to handle these things is to have a 32-bit table with entry for each character.
The table will have 8 bits for character width and 24 bits for offset to character data from beginning of file.
This is a bit wasteful for fixed-pitch fonts stored in HUB RAM though. So, I think I'm going to require in my drivers that
fonts include this 12-byte header that will also now say if this table is included.
A friend using this has reported a small bug : wrong offset calculated with "export with variable size character data"
- and a request that it remember the Export Settings ?
I would also suggest reporting the settings use, in the created ASM header as comments, so that anyone editing in 2 years times, knows the Version and settings used to generate the ASM file.
;[8088 assembler, Top Left Horiz, Byte Monochrome, variable width,Chars 0..255]
; Ray's Font Editor generated font text
; Source: RaysFontEditor1
; Font Name: New
; 12-byte info header:
DB 'R','F','D','1'
DB 0,255,16,8 ; start char, end char, height, max. width
DB 1,1,1,1 ; #bytes aligned to, 1 if variable width data else 0, bpp, 1 if 32-bit table included otherwise 0
; 32-bit table of 8-bit width and 24-bit offset to used characters
DB 0,0,4,12 ; Char# 0
DB 8,0,4,28 ; Char# 1
DB 8,0,4,44 ; Char# 2
DB 8,0,4,60 ; Char# 3
; Font Name: New
; 12-byte info header:
DB 'R','F','D','1'
DB 0,255,16,8 ; start char, end char, height, max. width
DB 1,1,1,1 ; #bytes aligned to, 1 if variable width data else 0, bpp, 1 if 32-bit table included otherwise 0
; 32-bit table of 8-bit width and 24-bit offset to used characters
DB 0,0,4,12 ; Char# 0
DB 8,0,4,28 ; Char# 1
DB 8,0,4,44 ; Char# 2
DB 8,0,4,60 ; Char# 3
DB 8,0,4,76 ; Char# 4
DB 8,0,4,92 ; Char# 5
DB 8,0,4,108 ; Char# 6
DB 8,0,4,124 ; Char# 7
DB 8,0,4,140 ; Char# 8
I'll add a feature request, for another type of Font-export : XOR Encoded.
In Monochrome case, instead of FG=1 on all bits, use XOR export, so the first pixel is FG=1/BG=0 and thereafter, all other pixels are XOR = Change.
Pixel count is the same as a more conventional font.
In systems with wider pixels, and more overhead in loading new pixel values, (such as SPI, or latched expanders) it can be faster to simply clock until a change is needed, whence the larger/slower code branch does a XOR and update to flip BG:FG
The user will need to select which is the 'lead' seed pixel. (MSB or LSB, of first, or last byte )
Thanks for reporting the bug and the feature requests.
Is the bug maybe that the 24-bit offset doesn't include the size of the table of offsets?
If that table is always 256*4 bytes, maybe that's an easy fix...
Actually, isn't it correct? The table of offsets is 24-bits. So the first value is 4*256+12. It looks like that should be correct for offset to first character from start of file...
Actually, isn't it correct? The table of offsets is 24-bits. So the first value is 4*256+12. It looks like that should be correct for offset to first character from start of file...
I think I can see one issue in the file, of where some chars have null fields, (#0, #129, #131), but their offsets seem to increment as tho there was information stored there ? A empty char should give two offsets the same ? (Width=0 says nothing there)
The more general case, seems to be variable width is not applying to the offsets (including w=0)
; 32-bit table of 8-bit width and 24-bit offset to used characters
DB 4,0,0,28 ; Char# 32 ;<- this offset is good
DB 4,0,0,44 ; Char# 33 ;<- correct offset: 0,0,36
DB 5,0,0,60 ; Char# 34 ;<- correct offset: 0,0,44
DB 8,0,0,76 ; Char# 35 ;<- corred offset: 0,0,54
ie - Offset as generated INCs by 16, but should INC by actual bytes stored for that char.
Thanks. - when I extract that, it says not a valid win32 pgm, and it is larger than the older ones ?
Did you manage to include XOR pixel export ?
Besides serial cases, I've just now struck a PLD case that fits better using XOR.
Simple Rule: First pixel sets FG/BG, thereafter pixels are a XOR(flip) command
I think that then needs some way to set what the first pixel is ( MSB or LSB of first byte)
Reverse scan can be useful for DJNZ opcodes, in which case a DJNZ export would have first pixel in the last byte.
a) Long lines can give issues on some Assemblers, so can the generated ASM avoid > 256 char lines ?
b) For reading the Address, can a choice of Endian be given ?
Currently
DB 0,0,4,12 ; Char# 0 <- Now MSB the first byte in char address
New option for LSB first (just the 24b address swaps byte order)
DB 0,12,4,0 ; Char# 0 <- LSB as first byte
Ok, I've added an XOR option and a reverse endian option for the table.
Didn't really have time to thoroughly test this new stuff though...
I'm puzzled as to why the previous version wouldn't run on a 32-bit machine.
I don't see any settings that are wrong.
But maybe, it's because it included debug information.
This one was compiled in release mode, so hopefully, it will work for you.
I'm not exactly sure how to limit the line length for ASM.
It's been a long time since I've used Intel ASM...
How would I end a truncated line? How to start new line with remainder?
I'm puzzled as to why the previous version wouldn't run on a 32-bit machine.
I don't see any settings that are wrong.
But maybe, it's because it included debug information.
This one was compiled in release mode, so hopefully, it will work for you.
It is smaller, but still says "not a valid Win32 applicaiton"
I'm not exactly sure how to limit the line length for ASM.
It's been a long time since I've used Intel ASM...
How would I end a truncated line? How to start new line with remainder?
It's as simple as you might hope.
ASM lines start with DB and comma,delimit,Byte,Lists
so to limit length just add CrLf and start again with DB
32 byte lines come in just under 200 chars
Meanwhile I had borrowed a Win8,1 laptop, and tried the earlier 64bit XOR.
I grabbed a quick font, and made Char 1 & 2 simple staircase tests (one change per H line)
Arial_XOR_test_TLSH.txt
Arial_XOR_test_TLSV.txt
My Pencil test has XOR looking OK for those 2 cases on the test chars.
- but it seems to have only MSB first as an option, within a Byte ?
having a LSB-first or MSB first covers all the bases. (MSB is easiest to read, but sometimes HW forces your hand)
In XOR, the corner pixel is always first-out, but it may be that the HW delivers bytes LSB-first, in which case reversal within each byte is needed in the Font Table.
I think a DJNZ scan, is covered already by your BottomRight Scan V/H options.?
Adit: The MSB/LSB (bit order) choice within a byte should be on all export modes, not just XOR, in case that was unclear.
Checking some more, I'm not sure the offsets are right ?
Zero is OK, but the widths-added do not seem to match the byte-counts ?
DB 8,0,7,172 ; Char# 30
DB 8,0,7,204 ; Char# 31
DB 4,0,7,236 ; Char# 32 << adds 32, but font is 8x16 ?
DB 3,0,7,252 ; Char# 33 << adds 16
DB 5,0,8,8 ; Char# 34
DB 7,0,8,28 ; Char# 35 << adds 20
DB 7,0,8,56 ; Char# 36
DB 8,0,8,84 ; Char# 37
DB 0,56,0,0 ; Char# 0
DB 8,56,0,0 ; Char# 1
DB 8,88,0,0 ; Char# 2 +32, but has correct 16b in table below
; Character #0
; Character #1
DB 080H, 0c0H, 0e0H, 0f0H, 0f8H, 0fcH, 0feH, 0ffH, 0feH, 0fcH, 0f8H, 0f0H, 0e0H, 0c0H, 080H, 000H
; Character #2
DB 000H, 080H, 0c0H, 0e0H, 0f0H, 0f8H, 0fcH, 0feH, 0ffH, 0ffH, 0ffH, 0ffH, 0ffH, 0ffH, 0ffH, 0ffH
; Character #3
Also :
I think the fixed-size export also has similar error of [offset change <> actual bytes in field.], when exported in width mode.
( fixed fonts may want to export this way, to mix with variable width fonts )
Another issue: ASM lines should never have a trailing comma.
The comma is a between-bytes separator.
On this build, sometimes they can have trailing comma.
Line length is now saying 203, so that's sweet.
Scroll bars work fine in my test case, I can now reach all chars.
The scroll bars are also nice to have for more-normal sizes, as now even with ZOOM, you can reach all chars.
Seems to interact with Zoom as expected.
Looking good
Only control feature missing, is bit order within bytes choice, but that covers rare cases.
Another comment (minor) The ASM header comments, do not include all settings.
Its a nice idea if the file-header shows a user exactly how that file was generated.
Then they can 'get another copy in 18 months time'
Comments
Looks cool.
Found a weird context bug in Up/Down interaction.
Down smears the font, but only if row 2 has black pixels.
Sounds like you want the insert/copy row/column feature at the character level...
I can see about a right-click popup menu to insert blank/instert copy row/column...
Also, I've added import for the Propeller text font used in the Rayslogic.com Adafruit RGB array driver.
It could already export in a compatible format (at least I think, haven't actually tried it).
Latest Version: RaysFontEditor_23Aug12.zip
If I try import of that, into a default sheet, I get an improper width error message ?
I also see the file filter change to .LCD on XML has been lost, now is back to .txt ?
Hmm... Somehow matrix import got sent to position #2 and xml to position #3 and that gives matrix import a ".lcd" default and xml a ".txt" default... Have to fix that...
Adafruit_5x7.zip
And, here are the export settings to put it back into Spin:
To use them, check "enable" and then click to the right or bottom of the character in edit mode.
Also, I've added a Propeller ROM font compatible export option for 16x32 pixel fonts.
RaysFontEditor_24Aug12.zip
Wow - Works very nicely !! I can 'fit' any imported font, very quickly now.
The operation method is a little hidden, and needs more visual hints.
If the mouse-active area could toggle with the Enable tick, casual users would not need to read the manual ?
If adding that sort of visual hint is too much effort, an alternative could be to borrow the Right/left mouse actions, and change the hint message when Row/Col ops are Enabled.
Choice then would be
LMB=row, RMB=Col, toggle on Clone/Cut
or
LMB=Clone, RMB=Cut, toggle on Row/Col
The second one is closer to the standard edit model, where LMB 'adds', and RMB 'removes' ?, and gives a more live 'undo' ?
I'd also expect more clone.clone.cut.clone type steps, than Row/Col so having both live is less mouse work.
I may have misunderstood this. I thought you meant it was inbuilt/pre-compiled, but I think I needed the font file to import ?
http://www.rayslogic.com/Software/RaysFontEditor/RaysFontEditor.htm
Just got an exported font working with the DVI Graphics Shield today too, so I think it's going to work nicely...
The deeper bit depths will probably have to be on SD or Flash...
Think I've decided that the easiest way to handle these things is to have a 32-bit table with entry for each character.
The table will have 8 bits for character width and 24 bits for offset to character data from beginning of file.
This is a bit wasteful for fixed-pitch fonts stored in HUB RAM though. So, I think I'm going to require in my drivers that
fonts include this 12-byte header that will also now say if this table is included.
Anyway, here's the latest version with this addition:
RaysFontEditor_8Jan13.zip
- and a request that it remember the Export Settings ?
I would also suggest reporting the settings use, in the created ASM header as comments, so that anyone editing in 2 years times, knows the Version and settings used to generate the ASM file.
;[8088 assembler, Top Left Horiz, Byte Monochrome, variable width,Chars 0..255]
; Ray's Font Editor generated font text
; Source: RaysFontEditor1
; Font Name: New
; 12-byte info header:
DB 'R','F','D','1'
DB 0,255,16,8 ; start char, end char, height, max. width
DB 1,1,1,1 ; #bytes aligned to, 1 if variable width data else 0, bpp, 1 if 32-bit table included otherwise 0
; 32-bit table of 8-bit width and 24-bit offset to used characters
DB 0,0,4,12 ; Char# 0
DB 8,0,4,28 ; Char# 1
DB 8,0,4,44 ; Char# 2
DB 8,0,4,60 ; Char# 3
In Monochrome case, instead of FG=1 on all bits, use XOR export, so the first pixel is FG=1/BG=0 and thereafter, all other pixels are XOR = Change.
Pixel count is the same as a more conventional font.
In systems with wider pixels, and more overhead in loading new pixel values, (such as SPI, or latched expanders) it can be faster to simply clock until a change is needed, whence the larger/slower code branch does a XOR and update to flip BG:FG
The user will need to select which is the 'lead' seed pixel. (MSB or LSB, of first, or last byte )
Is the bug maybe that the 24-bit offset doesn't include the size of the table of offsets?
If that table is always 256*4 bytes, maybe that's an easy fix...
Actually, isn't it correct? The table of offsets is 24-bits. So the first value is 4*256+12. It looks like that should be correct for offset to first character from start of file...
I think I can see one issue in the file, of where some chars have null fields, (#0, #129, #131), but their offsets seem to increment as tho there was information stored there ? A empty char should give two offsets the same ? (Width=0 says nothing there)
The more general case, seems to be variable width is not applying to the offsets (including w=0)
; 32-bit table of 8-bit width and 24-bit offset to used characters
DB 4,0,0,28 ; Char# 32 ;<- this offset is good
DB 4,0,0,44 ; Char# 33 ;<- correct offset: 0,0,36
DB 5,0,0,60 ; Char# 34 ;<- correct offset: 0,0,44
DB 8,0,0,76 ; Char# 35 ;<- corred offset: 0,0,54
ie - Offset as generated INCs by 16, but should INC by actual bytes stored for that char.
Also, I've included a gizmo that saves dialog settings to registry...
RaysFontEditor_22Jan14.zip
It's been a long time since I looked at this...
Now that I do, I wish I had time to redo the whole thing
Thanks. - when I extract that, it says not a valid win32 pgm, and it is larger than the older ones ?
Did you manage to include XOR pixel export ?
Besides serial cases, I've just now struck a PLD case that fits better using XOR.
Simple Rule: First pixel sets FG/BG, thereafter pixels are a XOR(flip) command
I think that then needs some way to set what the first pixel is ( MSB or LSB of first byte)
Reverse scan can be useful for DJNZ opcodes, in which case a DJNZ export would have first pixel in the last byte.
But doesn't under XP. Looks like a 32/64bit issue to me.
Yes, I forgot to mention this was on Win XP 32 bit.
a) Long lines can give issues on some Assemblers, so can the generated ASM avoid > 256 char lines ?
b) For reading the Address, can a choice of Endian be given ?
Currently
DB 0,0,4,12 ; Char# 0 <- Now MSB the first byte in char address
New option for LSB first (just the 24b address swaps byte order)
DB 0,12,4,0 ; Char# 0 <- LSB as first byte
Didn't really have time to thoroughly test this new stuff though...
I'm puzzled as to why the previous version wouldn't run on a 32-bit machine.
I don't see any settings that are wrong.
But maybe, it's because it included debug information.
This one was compiled in release mode, so hopefully, it will work for you.
I'm not exactly sure how to limit the line length for ASM.
It's been a long time since I've used Intel ASM...
How would I end a truncated line? How to start new line with remainder?
RaysFontEditor_24Jan14.zip
Great, will check it when I can run it...
It is smaller, but still says "not a valid Win32 applicaiton"
It's as simple as you might hope.
ASM lines start with DB and comma,delimit,Byte,Lists
so to limit length just add CrLf and start again with DB
32 byte lines come in just under 200 chars
Maybe I found a place that you have to tell it to include Windows XP support...
RaysFontEditor_24Jan14b.zip
Nailed it - that one works like a charm on XP..
Meanwhile I had borrowed a Win8,1 laptop, and tried the earlier 64bit XOR.
I grabbed a quick font, and made Char 1 & 2 simple staircase tests (one change per H line)
Arial_XOR_test_TLSH.txt
Arial_XOR_test_TLSV.txt
My Pencil test has XOR looking OK for those 2 cases on the test chars.
- but it seems to have only MSB first as an option, within a Byte ?
having a LSB-first or MSB first covers all the bases. (MSB is easiest to read, but sometimes HW forces your hand)
In XOR, the corner pixel is always first-out, but it may be that the HW delivers bytes LSB-first, in which case reversal within each byte is needed in the Font Table.
I think a DJNZ scan, is covered already by your BottomRight Scan V/H options.?
Adit: The MSB/LSB (bit order) choice within a byte should be on all export modes, not just XOR, in case that was unclear.
Zero is OK, but the widths-added do not seem to match the byte-counts ?
Also :
I think the fixed-size export also has similar error of [offset change <> actual bytes in field.], when exported in width mode.
( fixed fonts may want to export this way, to mix with variable width fonts )
Another issue: ASM lines should never have a trailing comma.
The comma is a between-bytes separator.
On this build, sometimes they can have trailing comma.
Also, I've tried to limit the length of text lines to ~200 chars.
RaysFontEditor_27Jan14.zip
Line length in my editor is 299 ?
I did a 60 pixel high capture, to ensure long lines, and it seems to do multiple lines, it's just they trim at 299 ?
I also notice the font-view, has no scroll choices when the font is large, so I cannot 'see' or get to, all chars ?
With flash memory so cheap, and LCD pixel counts climbing, high pixel count fonts are going to be more common.
Also, I took a stab at implementing scroll bars.
RaysFontEditor_28Jan14.zip
Line length is now saying 203, so that's sweet.
Scroll bars work fine in my test case, I can now reach all chars.
The scroll bars are also nice to have for more-normal sizes, as now even with ZOOM, you can reach all chars.
Seems to interact with Zoom as expected.
Looking good
Only control feature missing, is bit order within bytes choice, but that covers rare cases.
Another comment (minor) The ASM header comments, do not include all settings.
Its a nice idea if the file-header shows a user exactly how that file was generated.
Then they can 'get another copy in 18 months time'