Ascii Generator dotNET 0.9.1 released 12


Bug fix (which has literally been there forever), plus a whole new way of choosing how to save the files.

Download it here

Changes:
Added toolstrip with buttons to rotate and flip the input image
Replaced the different save menu items with a dialog
Set Accept (enter) and Cancel (escape) buttons for edit settings and text magnification forms
Fixed ctrl codes being enabled/disabled when they shouldn't be if the menu hasn't been opened

Translation file changes are here.


Leave a comment

Your email address will not be published. Required fields are marked *

12 thoughts on “Ascii Generator dotNET 0.9.1 released

  • ghsax64

    Just to let you know that when saving as colour .rtf 24bit, 2 characters are included in the first line “.5” (they should not be there…)

    I have only tested for the above settings but it could also happen on other settings.

    I remember about a year ago this problem was there and the same two characters were always included (no matter what the picture was). I cannot remember if it was “.5”

    (I posted a few months ago with other possible bugs, I must have forgotten about this one)

    Really like this program 🙂
    Keep up the good work.

  • ghsax64

    Version summary (regarding “.5” bug)

    0.7.0 same “.5”
    0.7.1a “.5” has been removed! (wow I never noticed the black border…)

    0.7.2 same as 0.7.1a but with no border!

    0.7.3, 0.8.0, 0.8.1, 0.8.2b, 0.9.0 no change

    0.9.1 “.5” appears again…

    Ok I’m assuming you got rid of it but it somehow made its way back in. So i’m sure you’ll be able to fix it again 🙂

  • ghsax64

    Ok this is just getting plain weird, I just tested using another picture and the “.5” is back. v0.8.2b and v0.9.1

    Also, until now, the “.rtf” extension was not being automatically included when saving (all tested versions). Now since I’ve restarted it’s changed…

    Ok, I have no idea what is going on… they are not major problems thankfully.

    Switching between two different .jpg’s alters whether the filename has “.rtf” included or not.

    Changing font size to something other than the default 9 makes the “.5” bug happen. Have not tested fonts styles other than the default.

    So to summarise, the two possible trends are:

    -file name missing “.rtf” affected by the picture used
    -font size affects the “.5” bug

    What the heck is going on…?

  • Jonathan

    Thanks, I never really bother to save as rtf.

    Something must have gotten screwed up when the save code was merged together. I can reproduce it, so I should be able to work out what is going wrong.

  • Jonathan

    Ok, I screwed up when it manually creates the colour rtf. The font size is supposed to be in whole numbers but I left the decimal point (8pt is actually 8.25 in the program, *2 to get the size in half points and that gives the extra .5).

  • ghsax64

    I can see the true font sizes in “Edit>Edit Settings…”

    Why must they be like that? Something about division by 3 to 2 decimal places? (Just a guess).

    Is the above a possible source of error?
    (regarding the final shape of the output)

    Changing the font size in Word after it has been generated does not seem to affect the width/height ratio. Which basically comes down to the way font sizes are defined right?

    However, zooming once the image has been created does seem to have an affect on the ratio. At least in Firefox. Have not tested Word.

    Perhaps we could have a “Known issues” or “Advanced users” page?

  • Jonathan

    It won’t affect the output, the program gets the actual physical dimensions of the characters.

    Firefox doesn’t really zoom in, it just makes everything bigger and increases the font size.

    Changing the font size even a little bit (or using bold etc) will almost always screw up the ratio. You should always convert the image into the right font and settings in the program.