Bug: Buggy implementation of Ponysay for TTY's
login in a TTY (in this example TTY1)
run ponysay lol
info: agetty, x86_64, Archlinux, version ponysay 0.6-1
suggestion how to fix:
opt1: makin a "fallback pony in assci for shoy in a TTY's for see if runing in tty you can use the command [ ! -s $DISPLAY ]
opt2: Making the ponys showables in TTY's
opt3: Restrict the use only in a X11, Wayland environment
opt4: Patch Linux VT to support \e[38;5;Xm and \e[48;5;Xm colouring (256 colours) and add support for Block Elements characters.
I would do it myself, but I do not have the time.
opt5: now, remplacing aggety w/ getty and set TERM-with-256-colors may in teory work too
opt6: Use framebuffer in Virtuals terminals (TTY) and a minimum of 800x600 and 24bit deph (thank Gigantic Luna) [not tested yet]
You can check for 256 color support on any term with tput color. The ponyfiles should work if that prints 256 (or possibly 88.) However, there is an interesting terminal emulator that runs on the framebuffer called fbterm that uses a different control sequence. The pregenerated files should only work on a term where tput setaf 89 outputs something like \e[38;5;89m.
tput setaf 89
Linux VT: 8
I would not relay on "tput colors" as only urxvt and Linux VT prints the correct value.
Yikes. Those are some pretty bad results. I suppose I shouldn't be surprised because I've had code in my .bashrc for a while that just sets TERM=xterm-256color for xterm-like terminals.
Yeah, this is a frequent problem. (not for just TTY and for many other consoles) Many people are unable to get MOTD ponies because of this. But unfortunately I doubt I can do much about it. If nopony can do opt4 or opt2, we need to go for opt3.
I'm for opt4 … it would be awesome.
But till then it I think the best solution would be to make scripts that make the ponies as good as possible for the problematic terminals; such as converting to 8 colours and/or ASCII.
That would be awesome. After all, there's no reason a Linux terminal running on top of a framebuffer shouldn't be able to do 256 colours. You may run into the same problem that fbterm did, however. Apparently the escape sequence conflicts with one that Linux uses for something else.
I wonder what the ponies would look like with 8 colours. I'm afraid they'd look dark and muddy, since there's no support for high intensity background colours. Either way, I could definitely patch img2xterm for 8 color output.
Patching img2xterm for 8 colour output and with blankspaces instead of block elements should be better that cowsay, so that's a good start.
I voted for the spaces instead of bocks
I noticed that a couple of fonts not "render/fit/match/making a correct display" of the bock moving pixels to the left or to the right deppending the font
but thi is fo a certains part of the block-line
Examples: ttf-celestia, monspace, currier new, consolas (have the minimum movement of bocks) in xfce4-terminal, are major noticeable if compares on the fly (changin see changing see and then)
If there is any way to get user overriden colours in Linux VT (definied by \e]Pnrrggbb),
\e]P can be used (in Linux VT) to get 24-bit colours instead of 8 colours, but the colours
will be changed with the TTY is switched.
I have begun working on the Linux VT (can be pixelperfect without changes) to make it ponysay compatible after which I will be working on adding more features.
But work will be very slow as I currently have too much other stuff to do. If anyone is willing to help [with maandree/linux] it would be greatly appreciated.
P.S. maandree/unisay can be of interest if you want to use non-ASCII characters, or, even better, want the ponies to quoted them self from MLP:FiM. (or other improvements to cowsay).
Idea: Make ponies out of jp2a. (it generates ASCII art in colour that renders well on tty) And make a fallback option for certain terminals and print those ponies instead.
I'm working on a program to convert the .pony files to Linux VT suitable files.
The ponies will have twice (in two directions, so quadruple) the size of the original .pony files.
To really big ponies, will probably be too big for most users however no cannot be added.
The pony files will use OSI P instead of CSI m for colouring, in effect 24-bit colours will be possible.
The text (white) colour (OSI P 8) will be overridden and then reset to Linux VT default (#aaaaaa).
Should the ponies by but in another catalogue than ponies/ or use another file name extension than .pony?
And should by ttyponies/ or .ttypony, or is something else preferred?
if size in KB ar so big maybe the mane6 and Celestia and Luna the only for TTy;
if size is for big in screen, Who in the 21 century not have a 1024x600 capable monitor/display for set tty to this size?
I wanna try these "fix", wath is the git for cloning and testing :) ?
I'm not done yet, but soon. I pose as soon as it is up.
600 height fits 37,5 lines, but I think the default height is 400 and
multimonitor can cause problems if the screens are not identical.
Linux TTY can [apparently] use the used block drawing elements. It is only the colouring that is problematic, so the screen size while not be a problem.
However, it is not 100 % pixel perfect.
I am almost done, the only thing missing know, is a tool to converting the ANSI sequences,
so the $thought:s do not need to be fixed for every converted pony. And naturally a script
that does everything needed for all pony files.
The problems you get with TTY is:
gpm (mouse) will modify the colours on the pony when the cursor is moved over the pony.
switching TTY make the pony lose its colours.
screen most be clears so the pony does not because monochrome.
pressing enter or otherwise cause a new line to appear in the terminal will cause partial colour lose on the pony.
The tools that exists is available at:
ASCII ponies may be better at the current state of Linux VT, but this is soon complete.
I will complete it when I get back from school.
at this momment: work perfect
Exept if you have $TERM diferent to 'linux' in the therminal/tty
but this in my opinion can by surpar using a if in X11/wayland or not instead of use wath is Term
and finaly, Swatebell change my PS1 colors, and the pony reset the tty (like clean/clear command) but I can live With them
ask: wath is the command or the resollution that you use for converting images into *.ponys??
To support 256 colours (and actually any 24-bit colour), the problem have to use two spaces on the colour palette,
so, for change colour change \e]P7 (white) and \e]PF (bright white) by be modified. Currently, to my knowledge,
the is not way for a program to read the palette so to pony files do the next best thing: reset the two white colours
to Linux defaults. As written in README, you may want to edit your .bashrc to reset the palette aftar you ran ponysay.
You can also add it the ponysay script, if you prefer.
ponysay needs to clear the screen when printing in TTY, otherwise it is probable that ponies will scroll the screen while
being printed, which results in some blocks becoming white.
And for the question:
I use util-say, which you find on my github-account: https://github.com/maandree/util-say
img2ponysay can create both normal 256-colours ponies and OSI P (tty) ponies.
ponysay2ttyponysay can be used to convert 256-colours ponies to OSI P (tty) ponies, which will keep all $thought.
Stuff I will add to util-say:
A pony editor (started, but not so complete)
Better colour selection with chroma weighting
ASCII and low colours support with dithering
I think we'll close this thread, we have done everything a (sane) pony can do (in reasonable amount of time).
Yes. It has been reported to work well on PuTTY.
It works on PuTTY, but it could be better.
Here's a PuTTY screenshot: http://dev.kuroyama.us/~kfiresun/pics/derpy_putty.png
I asked someone to try it. It looks pretty well actually.
I installed PuTTY and tried it earlier today, and it look like this:
Installed on Arch from the 'extra' repository.
@maandree Did you enable 256 colours option?
No, ut it looks like it is no, it is the block elements that does not work.
@maandree Did you enable... UTF-8? It's not default in PuTTy.
And btw, the ttyponies works as long you have KMS, say intel/nouveau drivers. But it breaks horribly if you have the nvidia-blob driver since it don't support KMS.
How does it look without KMS?
Why the hay is UTF-8 not default?
By locale says UTF-8, and ”Override with UTF-8 if locale says so” is default.
I tested setting UTF-8, but it gives the same result.
I can provide a photo tomorrow when I have access to that computer. I only run free stuff at home.
@maandree Putty... is like that, at least in windows. Might be font-issue in your PuTTy?
Yepp, it was a font-issue, works pixel perfectly with unifont as the font.
Sad pony in my tty at work: http://i.imgur.com/VlCV6.jpg
Using the nvidia-blob driver.
Ahh, same problem as when switch between TTY:s.
I am planning to "solve" this with a program called
tty2colourfultty in maandree/util-say.
It will select be nearest CSI m colour when change the palette.
My guess is that I will have it done by 15:00 (it's now c:a 08:30), if I'm not hold at school.
Reopening this then. But I'm using the proprietary nvidia drivers and it works flawlessly on tty (both mingetty and agetty) for me.
I forgot, this was TTY2, can test TTY1 tomorrow.
@erkin Can you try TTY2 and see if you get the same?
I think it is time for a wiki for issue encountered in this thread.
Some improvements is still required to make the ponies look as good as possible, now they look like zebras.
You'll need to download maandree/utilsay. Only Colour.java and tty2colourfultty.java is required. I have not yet
provided a script to build executables, but assuming you make a tty2colourfultty executeable; in tty, do not follow
the instructions in tty, rather, run:
fortune | ponysay -f cheerilee | tty2colourfultty -p command to set palette
command to set palette
Skip -p ... if you do not have a custom palette.
tty2colourfultty -e -p command to set palette < ttyponies/tty.pony > myponies/my.pony
Will make a pony using this feature.
I guess I'll work on making it print prettier ponies, and then I'll replace the current tty ponies.
I'll also write a script of creating double sized (spaces only) ponies with 8 or 16 colours.
And use characters on block to blend an approximate colour. I guess that is actually the
best alternative if the (current) ponies look like http://i.imgur.com/VlCV6.jpg when printed.
There are problems with resetting colours in tty. After the pony is printed, the last used colour becomes the new default colour.
What command are you running?
I also have this issue, it works at least with the following commands:
ponysay -f pony bla
fortune | ponysay -f pony
where pony is either fluttershy or twilight (maybe even more)
Actualy the program have many changes, I imagine that a version bump mayble?
I think...is possible detect if you change tty's? if yes: why not store the las ponysay command used if change and if swithced again to the pony-tty-related relaunch these "stored" pony again, this can "fix" the tty-change probles bya rerun the program, this is possible if exist a form to detect if change from tty's...
I begin to imvastigate the exactly var store the tty-nº
I'm not quite following what you are saying.
ok I try to explain in parts
1- Actualy the code comppared w 0.8 have changes (like the naightmare bugg and tty display), I ask if is possible bunp fRom 0.8 to a 0.9 version?
2- When you swithch to a tty exist a variable that say in wath tty are you?
if 2 = yes then
2.1- If you switch to to another tty if possible to atore the las "ponysay "message" or fortune | ponysay" used?
2.1.1- can store the message and if return to the tty that display the pony can "rerun" automagicaly the "stored" command, this can (in theory) fix the zebra-pony bug (relaunching the command)
underestandable now??? (stupid translators)
I think v0.9 has those updates, but that nobody has updated the package
in the Arch Linux repository.
OK, now I understand the second part.
But i don't think there is a variable for that. /dev/tty and /dev/tty0 are
linked to the current TTY, but they are not symbolic links. If they are
hard link then it should possible to get the current TTY.
But to restore the pony we must have a daemon (if you can't create
threads in shell) that does so, but it must also know whether the pony
is still visible, and how much of it, otherwise, it will restore ponies
all the time when there is something else there.
And I don't think it is possible, unless we monitor the /dev/vcs* files,
which requires superuser permission.
unzebra -e < ponies/file.pony | ponysay2ttyponysay | tty2colourfultty -e > ttyponies/file.pony
Should now fix the major issue, but the contours might still be less nice when switching TTY.
If you have a custom palette, then tty2colourfultty should also have the arguments
I test now the ponysay XD
1- Append to my .bashrc for run in the begin "exec ponysay $(uname -a)" make display for 1 sec and autologin-out from my session (in tty)
2- Celestia why U no display correctly, Run Celestia in a tty w lees "blocks/spaces/lines" than they stature making them roll dawn and them make them become Pink completly (in a 640x480 tty w/font lat9w-12)
It may be best to truncate the ponies on the height in TTY, just as we (always) do with the width.
e'yup, buth the "text/think" maybe become inreadable, but can by fixed oving thi to the botom instead the upper for the thuncation (?) in de height.
Reproduce the other problem: apend in .bashrc in the first line after the PS1
exec ponysay $(command in my case uname -a)
So far, they are reported to work on PuTTY, agetty and mingetty. Where does the problem persist?
KMS is required in TTY for good colours, and it is and the ponies looses quality when ponies position on the screen changes, or when the TTY is reopened.
I think we should close this issue and make it as partially unsolvable.
Alright. I'm closing it as wontfix.