Font Editor (preview #5)

13

Comments

  • jmgjmg Posts: 14,318
    edited 2012-08-22 - 16:26:46
    Rayman wrote: »
    Here's the latest version with many of the suggestions implemented:

    Looks cool.
    Found a weird context bug in Up/Down interaction.

    Down smears the font, but only if row 2 has black pixels.
  • RaymanRayman Posts: 10,869
    edited 2012-08-22 - 16:51:40
    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...
  • RaymanRayman Posts: 10,869
    edited 2012-08-23 - 13:37:12
    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).

    Latest Version: RaysFontEditor_23Aug12.zip
  • jmgjmg Posts: 14,318
    edited 2012-08-23 - 14:10:06
    Rayman wrote: »
    Also, I've added import for the Propeller text font used in the Rayslogic.com Adafruit RGB array driver.

    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 ?
  • RaymanRayman Posts: 10,869
    edited 2012-08-23 - 15:24:27
    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...
  • RaymanRayman Posts: 10,869
    edited 2012-08-23 - 16:23:50
    Here's the Adafruit 5x7 font imported as a RaysFontEditor document:

    Adafruit_5x7.zip

    And, here are the export settings to put it back into Spin:

    Adafruit_5x7_export.png
  • RaymanRayman Posts: 10,869
    edited 2012-08-24 - 08:42:23
    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.

    RaysFontEditor_24Aug12.zip
  • jmgjmg Posts: 14,318
    edited 2012-08-24 - 15:20:18
    Rayman wrote:
    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.

    Rayman wrote:
    { 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 ?
  • RaymanRayman Posts: 10,869
    edited 2012-11-25 - 14:45:18
    Haven't done any more work on this, but I did make a webpage for it:
    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...
  • RaymanRayman Posts: 10,869
    edited 2013-01-08 - 11:56:11
    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.

    Anyway, here's the latest version with this addition:
    RaysFontEditor_8Jan13.zip
  • jmgjmg Posts: 14,318
    edited 2014-01-19 - 12:28:00
    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
    
  • jmgjmg Posts: 14,318
    edited 2014-01-19 - 16:53:13
    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 )
  • RaymanRayman Posts: 10,869
    edited 2014-01-20 - 05:11:07
    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...
  • jmgjmg Posts: 14,318
    edited 2014-01-20 - 13:07:44
    Rayman wrote: »
    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.
  • RaymanRayman Posts: 10,869
    edited 2014-01-22 - 11:36:34
    Ok, I've made an attempt to fix the offsets for variable size character data.
    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 :(
  • jmgjmg Posts: 14,318
    edited 2014-01-22 - 13:50:19
    Rayman wrote: »
    Ok, I've made an attempt to fix the offsets for variable size character data.
    Also, I've included a gizmo that saves dialog settings to registry...

    RaysFontEditor_22Jan14.zip

    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.
  • RaymanRayman Posts: 10,869
    edited 2014-01-22 - 16:09:44
    Forgot about xor, I'll try to add that tomorrow. And, I'll see why the zipped exe doesn't work...
  • kuronekokuroneko Posts: 3,623
    edited 2014-01-22 - 16:14:32
    jmg wrote: »
    ... when I extract that, it says not a valid win32 pgm, and it is larger than the older ones ?
    Works for me: archive 3,581,957 bytes, executable 9,879,552 bytes, 64bit system.

    But doesn't under XP. Looks like a 32/64bit issue to me.
  • jmgjmg Posts: 14,318
    edited 2014-01-22 - 16:45:53
    kuroneko wrote: »
    Works for me: archive 3,581,957 bytes, executable 9,879,552 bytes, 64bit system.

    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.
  • RaymanRayman Posts: 10,869
    edited 2014-01-22 - 17:19:00
    Ok, this is probably due to me migrating the project to VS2013... I must have missed something regarding 64 vs. 32 bit compile...
  • jmgjmg Posts: 14,318
    edited 2014-01-23 - 15:30:06
    Another minor requests :

    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​
  • RaymanRayman Posts: 10,869
    edited 2014-01-24 - 11:25:46
    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?

    RaysFontEditor_24Jan14.zip
  • jmgjmg Posts: 14,318
    edited 2014-01-24 - 13:38:14
    Rayman wrote: »
    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...

    Great, will check it when I can run it...
    Rayman wrote: »
    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"

    Rayman wrote: »
    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
  • RaymanRayman Posts: 10,869
    edited 2014-01-24 - 13:47:38
    Can you please try this one?
    Maybe I found a place that you have to tell it to include Windows XP support...

    RaysFontEditor_24Jan14b.zip
  • jmgjmg Posts: 14,318
    edited 2014-01-24 - 15:14:57
    Rayman wrote: »
    Can you please try this one?

    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.
  • jmgjmg Posts: 14,318
    edited 2014-01-25 - 11:10:41
    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.
  • RaymanRayman Posts: 10,869
    edited 2014-01-27 - 12:08:43
    Ok, I think the offset bug is fixed.
    Also, I've tried to limit the length of text lines to ~200 chars.

    RaysFontEditor_27Jan14.zip
  • jmgjmg Posts: 14,318
    edited 2014-01-27 - 14:01:20
    Thanks. Offset looks better behaved.

    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.
  • RaymanRayman Posts: 10,869
    edited 2014-01-28 - 11:04:31
    Ok, I think I've fixed the line length.
    Also, I took a stab at implementing scroll bars.

    RaysFontEditor_28Jan14.zip
  • jmgjmg Posts: 14,318
    edited 2014-01-28 - 11:48:44
    Rayman wrote: »
    Ok, I think I've fixed the line length.
    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'
Sign In or Register to comment.