Is there any way to change the size of the text in shell script ?
I mean dynamically during the execution .
For example I have an image drawn with ASCII code and i want to reduce the size of text .
Now when echo or cat the image it will be shown as the command prompt actual size (the actual font size) .
A couple of comments note that font size/style are under the control of the terminal emulator, and that xterm (and a few others) support escape sequences to change these.
However - almost all terminal emulators (all that you would be likely to encounter) rely upon keeping the characters in a nice row/column grid. All of the characters have the "same" size. If you change the size of the font in xterm, all of the characters on the screen change to the same size. So there is no way to (as OP asks) to reduce the font-size temporarily, e.g., while using ASCII graphics to draw a picture using aalib, etc.
If you want to do something like that, the easiest way to do it is to have the script run its graphics in a separate window, e.g., by splitting it up into one part that starts the window and another script to draw the graphics.
For an alternate via of terminals and fonts, there is always something like 9term (no rows, no columns, no vi).
Related
I have a PostScript file with image and text. I want to print it to a laser printer so that the images print in a halftone round pattern.
I am trying to print it from the command line. I would prefer a PDF output first and then I'll print to the laser printer.
I have an HP Laserjet P2015 printer installed in Windows 10.
gswin64c.exe -dQUIET -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=output.pdf test.ps -c "<< /HalftoneType 1 /Frequency 37 /Angle 45 /SpotFunction {180 mul cos exch 180 mul cos add 2 div} >> sethalftone"
The PDF file is generated. However, the images does not appear to be in Round Halftone format. I see no change in the image.
This is the original Image
I want the printout to look like this: Required output
For some reason the output is the same as the original.
pdfwrite doesn't create monochrome output, so no, the output won't be halftoned. The whole point of the pdfwrite device is to maintain the output as close in quality as possible to the input.
There is no way to get monochrome output from pdfwrite unless the monochrome is in the input.
If you instead use a monochrome output device (e.g., tiffg3 or tiffg4) you should see a difference, unless the input file (which you haven't supplied) also sets a screen, in which case the last one encountered will take effect. That is, if the PostScript input file specifies a halftone screen, that's the one that will get used.
What you are asking for is what I might generally describe as a hard problem, probably much harder than you expect.
Your best bet is to send the PostScript directly to the printer, since it supports PostScript.
Problem 1; your PostScript file may already contain a halftone in it which overrides the one you want to use. You can usually prevent that by redefining the sethalftone and setscreen operators:
/sethalftone {pop} bind def
/setscreen {pop pop pop} bind def
You do that after you'[ve defined your own halftone, obviously. Or you can just edit the PostScript file and remove the halftone definition, its usually not that hard to find.
Problem 2 is that printer manufacturers sometimes 'tweak' the interpreter to always use their preferred halftone and prevent you overriding it in PostScript. The only way to find out if that's happening is to try a quick test; print a simple image with the default screen, then set a really coarse screen, say 10 lpi and print the same image. If there's no difference then you know that's not a viable option. If there is, then you can just set the screen you want.
Now, if the printer won't let you change the halftone then the only solution is to render the PostScript to an image using Ghostscript (which will let you change the halftone) and then send the resulting image to the printer. You will need to use a 1 bpp device, something like tiffg3 or tiffg4 should work fine.
The problem here is that you need to ensure that the image fits on the media of the printer, because if it doesn't then the likelihood is that the printer will slightly scale down the image so that it does fit, thereby squashing the halftone cells.
Even more subtly, the printable area of the media in the printer may not be the same as the size of the media. Paper handling can mean that there are some areas of the paper that can't be printed on, and the variability in the feeding of the paper can mean that the printer will refuse to print right to the edges anyway. Because if it did, and there was, say, a 1 mm deviation in the paper handling, then 1 mm of the edge would 'fall off' and there would be a 1 mm white gap at the other edge...
Correct display of Unicode in a terminal would appear to benefit from the displaying app knowing the number of character cells used to display text. Functions like wcwidth() are a reasonable start, but there can be a lot of variation, for example what a terminal displays for invalid characters, ambiguous width Asian characters, combining characters out of context, etc.
Would it be reasonable to extend terminal apps with a new control sequence to measure with display width of a string, which display apps could use to characterize the terminal? If so, what details are worth considering, e.g. what sequence to use, whether to specify UTF-8, also how to handle terminals that do not know this hypothetical new control sequence? Would it have any likelihood of wide adoption?
If not, what is the flaw in the idea? Is perhaps reading the cursor position after display a better (and already supported) option? Or is there a good different approach?
There's no need, because the existing cursor position report (which can be used to get the position before and after printing a string) gives the length.
Adding a new control sequence to get the attributes of a character (width, combining, controls such as tab) wouldn't help much because the application still has to work with the system's locale information for performance reasons: it would drastically slow down an application if it had to ask after each character where the cursor really was.
iTerm2 has a feature that can be used to display images in the terminal, see https://iterm2.com/documentation-images.html for documentation on the protocol.
I have been able to produce an image in the terminal by using the correct ASCII characters and encoding; this string (starts with ESC and ends with ^G)
]1337;File=inline=1:iVBORw0KGgoAAAANSUhEUgAAABwAAAAcCAYAAAByDd+UAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAABQtJREFUeNrsVktoXVUUXefc7/vmpUmaNonWSsFYtBZEWhRKERxI60QF6UhBOhAVEXEmzjrVQbXgTBRFB4oTlSq1FEGEiggWlKpVjG0wn9fXvE/u75zjOucmaVIrWhBB6IX9eO9+9tpr7bX3fcIYg//yENcB/33As+PX9oStr8GPvsClJ0dG1AXviIiKSYyJ1+SucFEI3KqXknFZHxpH7n0sW9Xj8UPjEA0Jk2j41wBU5+ejaOnH0NChansLmMjugB+MeDs0REsclGEC4ZHFuEAxPwOVNYfjA5PH5UgAfSnnhX/KUOFZNPWLjFZxxkd6OoKeq0COePCaPkTsQZKaKgCtDALSyM9eBG65+WLlwelZ9Usn5A0xM7X9v5VPYD8m1Ut6VmD5/RrUuRpkVEFwk4RsSRbDsgvhqi9yTVCF0LOPSohMDZtePkyw1YxTPmR+ZVft3SGKMEOEOzFanEw/D5B+2oTwa4h3kVGF/cgJVjDIzDbG1hZ7BkZJELY8f9mQbcZeRubPZY2N6hkPkTGjm0Y7J1AV04N3qshPDyHcWYE/YRvvwRSk4Et4nge9klMbjbzQ8KQpi4ZYn3aYcR/jmP9Jd3KVmtPQaIV+rfnEnu789O435hfUr63Ryt0VWJ1MSiA2SHgEFhLLJBJaYD5qpUyJXvM9mwXrZFxN/irjqB/IjaYxYfyAbuoXsjeX5nC+IaJ9MaSxmnlQTOZZQMnvKwWSEiU08HhLg8gqZ4uMWIezdhxjvEdz1VFGlW0OH1/YfO9bO0/UsGfu583FvuqYVAGWEoEBAYM4RGYkUiaUBK/XAgQBGdl+ybKfQogVHLHOee44xfiMd1nT5BA6fbk7Wj+8+dv58/d8dRrYvQlKhTBkE0ZlYsGkmRbIGT4l7nKQ+xmHmeCSEs4spjynqLq8muffZfTXxqKIw0T01I37Tr4+FGxPkcQTkLS8Zq+qse8YMTea1cAx0dqacEVWUfJoWcYUW+niaoBzjC8doGCzl4Yrvds/PLt1S95HOjUBn89IslIETHODPFeoVUO62NCgJYNGxXPWL2gYwxytGn8XBkl21f18yEpqAR/JqsFv9Zn+/TvPsYgdQxxNgX5hZ0pjqBGUgBouuUfp+knuxqFe8Z073Xmy7A0K5FmOZmyXk7nSOEcYJ32+Lp7rN6O7bvvivGqpZaRDY24XWFdra3eCxmRaZxRORzt0Tk9Y5TxXh3bFkSacZ9cGfgNTO/h7pfLlN1E7w7bZRQ9bIyCBq74SCtQj4QC5ILHUzVg96y4KWCUbvC6UQq+fIUncEnWbxp7XtiD9J1mfsXR9ynl40/cdjA36UDfUWKmhJ4wDEsatdyY2iKxRCu12pKGKqbK95HgovcbEskzygm62U7oBkJscH9ldKgfV8FS8nCDUuZPQVtfp8TtNYte/pG5JkqHTTZicTPLMbmmolIyTFFUm5+Llqyh392v2VOelvG6fXl5tPzBm2HWzf9tPS0eNNE8hZPPZg0bAyr3CDbOdL9uvZcrXFNyVXjkSlbgkVth+uZk3rndxZLePRiapUOQtilpwDgsmWnk9dcSPbx/A9u/ajV7S+VqExQ52plz0q6LYfAQNCJQpg7/+R7JygTdwkvjCzWDioVeqD08/LbfEMINyNv3ts33o0WrX/J4/X1xoHyRMzmrW0ppyrt0rT7On7rcwV+xls3ECjHsuxuLgg/xMG/HUVLn+bDHX/yb+7wH/EGAARjZ2jNWjuZgAAAAASUVORK5CYII=
will produce this output:
however, when I attempt to display another image along side, this happens; string
]1337;File=inline=1:iVBORw0KGgoAAAANSUhEUgAAABwAAAAcCAYAAAByDd+UAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAABQtJREFUeNrsVktoXVUUXefc7/vmpUmaNonWSsFYtBZEWhRKERxI60QF6UhBOhAVEXEmzjrVQbXgTBRFB4oTlSq1FEGEiggWlKpVjG0wn9fXvE/u75zjOucmaVIrWhBB6IX9eO9+9tpr7bX3fcIYg//yENcB/33As+PX9oStr8GPvsClJ0dG1AXviIiKSYyJ1+SucFEI3KqXknFZHxpH7n0sW9Xj8UPjEA0Jk2j41wBU5+ejaOnH0NChansLmMjugB+MeDs0REsclGEC4ZHFuEAxPwOVNYfjA5PH5UgAfSnnhX/KUOFZNPWLjFZxxkd6OoKeq0COePCaPkTsQZKaKgCtDALSyM9eBG65+WLlwelZ9Usn5A0xM7X9v5VPYD8m1Ut6VmD5/RrUuRpkVEFwk4RsSRbDsgvhqi9yTVCF0LOPSohMDZtePkyw1YxTPmR+ZVft3SGKMEOEOzFanEw/D5B+2oTwa4h3kVGF/cgJVjDIzDbG1hZ7BkZJELY8f9mQbcZeRubPZY2N6hkPkTGjm0Y7J1AV04N3qshPDyHcWYE/YRvvwRSk4Et4nge9klMbjbzQ8KQpi4ZYn3aYcR/jmP9Jd3KVmtPQaIV+rfnEnu789O435hfUr63Ryt0VWJ1MSiA2SHgEFhLLJBJaYD5qpUyJXvM9mwXrZFxN/irjqB/IjaYxYfyAbuoXsjeX5nC+IaJ9MaSxmnlQTOZZQMnvKwWSEiU08HhLg8gqZ4uMWIezdhxjvEdz1VFGlW0OH1/YfO9bO0/UsGfu583FvuqYVAGWEoEBAYM4RGYkUiaUBK/XAgQBGdl+ybKfQogVHLHOee44xfiMd1nT5BA6fbk7Wj+8+dv58/d8dRrYvQlKhTBkE0ZlYsGkmRbIGT4l7nKQ+xmHmeCSEs4spjynqLq8muffZfTXxqKIw0T01I37Tr4+FGxPkcQTkLS8Zq+qse8YMTea1cAx0dqacEVWUfJoWcYUW+niaoBzjC8doGCzl4Yrvds/PLt1S95HOjUBn89IslIETHODPFeoVUO62NCgJYNGxXPWL2gYwxytGn8XBkl21f18yEpqAR/JqsFv9Zn+/TvPsYgdQxxNgX5hZ0pjqBGUgBouuUfp+knuxqFe8Z073Xmy7A0K5FmOZmyXk7nSOEcYJ32+Lp7rN6O7bvvivGqpZaRDY24XWFdra3eCxmRaZxRORzt0Tk9Y5TxXh3bFkSacZ9cGfgNTO/h7pfLlN1E7w7bZRQ9bIyCBq74SCtQj4QC5ILHUzVg96y4KWCUbvC6UQq+fIUncEnWbxp7XtiD9J1mfsXR9ynl40/cdjA36UDfUWKmhJ4wDEsatdyY2iKxRCu12pKGKqbK95HgovcbEskzygm62U7oBkJscH9ldKgfV8FS8nCDUuZPQVtfp8TtNYte/pG5JkqHTTZicTPLMbmmolIyTFFUm5+Llqyh392v2VOelvG6fXl5tPzBm2HWzf9tPS0eNNE8hZPPZg0bAyr3CDbOdL9uvZcrXFNyVXjkSlbgkVth+uZk3rndxZLePRiapUOQtilpwDgsmWnk9dcSPbx/A9u/ajV7S+VqExQ52plz0q6LYfAQNCJQpg7/+R7JygTdwkvjCzWDioVeqD08/LbfEMINyNv3ts33o0WrX/J4/X1xoHyRMzmrW0ppyrt0rT7On7rcwV+xls3ECjHsuxuLgg/xMG/HUVLn+bDHX/yb+7wH/EGAARjZ2jNWjuZgAAAAASUVORK5CYII=]1337;File=inline=1:iVBORw0KGgoAAAANSUhEUgAAABwAAAAcCAYAAAByDd+UAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAARRJREFUeNpi/P//PwM9AeOohUPfwt83oiOANCcQ/6GxXSxA/B1k4SMgQxCI/9LYQmYgfg+yVZaOIcoDslAV6t1/NLaMCRRtIIvu0DPRgCz8Bk001ATvgFgA6itk8B1kYSgQs1Mp0fwEYikgngvEV4C4AYh/QD0GSjQ/QamUFiH3CYgXAXEOtnwIchUblA8qBR4AsRAQ89PAIb9AXt0NxLxA/BuIVYBYERq8B6E0EykFCTQI30CDUQyq/z+U/gwS9EHTBLI4BIg30iqVTgJibmhqheXJCUDsCXUxExXz4VdQHP7HkqSFaJkPGemd8ZWgND0Kb3DRdpfePrwMzXP0KLw/giwsgmZ8elj4a7QRNWohyQAgwAAQhlmNWgQOSgAAAABJRU5ErkJggg==]1337;File=inline=1:iVBORw0KGgoAAAANSUhEUgAAABwAAAAcCAYAAAByDd+UAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAABTZJREFUeNrsVkuIXEUUPVX1fv2ZmZ6ZTMcxISZBowYJQYkGhYCKShARQRA/uJEgiuLClagbFy514QeXERRUVLIQV2oSiAt1wEQDTiAfY8xnJpnJTH/fr6o89bqTmU5A4iag2DO3q9+rV3XuPffcW09Ya3E1PxJX+fPfB/TyQ09BRBK2aRB/MQOz0HkAvt5uWoszcjiaYYp/M7+k4zhrn7WJd1Jdq18deW9uDhXmvikA8Q8B3ZftGshxH8GDo+h89OcTyms8Hd4wApvEsBowt/OZBYv8cA7Us0d1Yg+oVXoFlEyxIHdyiw8J3LoSQJFNP3mA4xiMjdXaWtr9cnoSh46O+htGkXF/qQQU3TIM1cYaupHDzGnIehfhlgTeLXyoIRdob0Dh7SuJcFMvmwK2lQGphmVqhZXIUhBMcR93Te8izpBKUzLIf6+g81kXaqqN0v3dmlyl38IZ9TMX7/k7mp1o1tI20OaLO64uhQBJRrnkI4p8WBei53zzgdwnqI9wM+c2VWH+GEfrg1Ek+zg/me9GgNu4mDunARQ9ltmAuV2O056njS5jmqFRSIwyp0mPJuQFIqA1Wci5q9KItgjkp4YR7/KhTy6i/FhnCh07PX+udm8ixCkl9GWU6svKw+1KACEUklwg4ihJrWbwXQIFdEAoQ0EpCiuHqmuUamUkU0zLeXtu/yMTN/1gJp6rtBuvC6l6AcBepPQ+2vsD0fVHS2qHyn6RRyP5qFJ98+gAqfU9WFItrVf8Du+MgKNDNv0knDXDY6/50fqHfLkSvqyjN64sAL+j7e2B2CVQ9y+KL7olC3DfV6gyfy7axAqkpNuPAjKo0IgFpPaRbytP3DF7rL7x2wrO1e/5WCJ4Rogyt6kW5gDbtE8vVZNP2posgxNzCfEENaPQTg3vGXiBQmYISBN0xjkShBQX6dM6ADaP4a6pn1D/9ezJ5orqDmESlgtFQ3OA39BmLwXUxiLkRjVGZPtBOwFbRmaol6GSh2HSnfF3KfKoaA+GeZeMOo5G4a9rYNvunWtES6/JoyBeXhYP0x6/FDCnQiqhJCDzR3BNsVQjRSBVZNnRremBopobXY0kY40yWo9OepRhsrqOa7J2+cbvj0w2RkstYexFlb5Ju3tQMJYJBs6zEfhkqFQOik6T57oQUKubF0IuB8wtN8q0A7OIuGixmcFtXiYTuH4EG4/O4tiJVdvTYX+PH+erXYSv0LYuxWb79e/6DfmylD+BJEcWAUzOVmZcg3VlQeM4XvUKMM3rQmP9KkhGSqjpLtYdnNnaHg73CWtflv2wXhrgkx4abjQUsAaVLQDiOEernUKw6N19MktHcrY/jUYzLZ5xgNWQc5wvGHSZmwxx3ek5Fc6n0J7c7wBX076mnV+qRJczgrCoXXS8YFKpMI46zdDtJDBstLZ/PxSmcKQAZa4dsFOYo1uPlTDRaWPs+CLSsr/D5fDE4PkhChoN5Ve87kjXygQC8qQoim6cFd77zJ97QHLvhU5eRBa4qB07BG3w3lBIH4gQmAxRN0anHOx1gD/Sau54EhU/EaFab6UZD0suMi523ote12E8CINeU3Cl4bqWE1NXZ6jywh1lmseK5JqhKhXsjpiAkVJQ1x1pvHtkq33RnYe9wMqsozP04vPpd0S8+IIcCVygvYgHFIzLCAkI5JTqyqffpIq0FHXr/lLvcDWq3Xrs5rGmd2GVYGfJDs6z43d28YipiFYeL6uSZaBLr5WuCThAF5WxvRkhBsTHGeGryZGvzIpyc93pNs/V/99L/+2AfwkwAIpSa6LlmvuQAAAAAElFTkSuQmCC
produces
The images are not inline.
How can I ensure consecutive images remain inline? I am able to repeat the result in zsh, and bash. I am on iTerm 2 Build 3.0.4.
Thanks!
There are two solutions:
1> Insert \b\33[1A at the beginning of the second and third image, change the count of \33[1A according to the height of image (in your case, it appears once). The meaning of escape sequences can be referenced here.
\e]1337;File=inline=1:iVBORw0KGgoAAAANSUhEUgAAABwAAAAcCAYAAAByDd+UAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAABQtJREFUeNrsVktoXVUUXefc7/vmpUmaNonWSsFYtBZEWhRKERxI60QF6UhBOhAVEXEmzjrVQbXgTBRFB4oTlSq1FEGEiggWlKpVjG0wn9fXvE/u75zjOucmaVIrWhBB6IX9eO9+9tpr7bX3fcIYg//yENcB/33As+PX9oStr8GPvsClJ0dG1AXviIiKSYyJ1+SucFEI3KqXknFZHxpH7n0sW9Xj8UPjEA0Jk2j41wBU5+ejaOnH0NChansLmMjugB+MeDs0REsclGEC4ZHFuEAxPwOVNYfjA5PH5UgAfSnnhX/KUOFZNPWLjFZxxkd6OoKeq0COePCaPkTsQZKaKgCtDALSyM9eBG65+WLlwelZ9Usn5A0xM7X9v5VPYD8m1Ut6VmD5/RrUuRpkVEFwk4RsSRbDsgvhqi9yTVCF0LOPSohMDZtePkyw1YxTPmR+ZVft3SGKMEOEOzFanEw/D5B+2oTwa4h3kVGF/cgJVjDIzDbG1hZ7BkZJELY8f9mQbcZeRubPZY2N6hkPkTGjm0Y7J1AV04N3qshPDyHcWYE/YRvvwRSk4Et4nge9klMbjbzQ8KQpi4ZYn3aYcR/jmP9Jd3KVmtPQaIV+rfnEnu789O435hfUr63Ryt0VWJ1MSiA2SHgEFhLLJBJaYD5qpUyJXvM9mwXrZFxN/irjqB/IjaYxYfyAbuoXsjeX5nC+IaJ9MaSxmnlQTOZZQMnvKwWSEiU08HhLg8gqZ4uMWIezdhxjvEdz1VFGlW0OH1/YfO9bO0/UsGfu583FvuqYVAGWEoEBAYM4RGYkUiaUBK/XAgQBGdl+ybKfQogVHLHOee44xfiMd1nT5BA6fbk7Wj+8+dv58/d8dRrYvQlKhTBkE0ZlYsGkmRbIGT4l7nKQ+xmHmeCSEs4spjynqLq8muffZfTXxqKIw0T01I37Tr4+FGxPkcQTkLS8Zq+qse8YMTea1cAx0dqacEVWUfJoWcYUW+niaoBzjC8doGCzl4Yrvds/PLt1S95HOjUBn89IslIETHODPFeoVUO62NCgJYNGxXPWL2gYwxytGn8XBkl21f18yEpqAR/JqsFv9Zn+/TvPsYgdQxxNgX5hZ0pjqBGUgBouuUfp+knuxqFe8Z073Xmy7A0K5FmOZmyXk7nSOEcYJ32+Lp7rN6O7bvvivGqpZaRDY24XWFdra3eCxmRaZxRORzt0Tk9Y5TxXh3bFkSacZ9cGfgNTO/h7pfLlN1E7w7bZRQ9bIyCBq74SCtQj4QC5ILHUzVg96y4KWCUbvC6UQq+fIUncEnWbxp7XtiD9J1mfsXR9ynl40/cdjA36UDfUWKmhJ4wDEsatdyY2iKxRCu12pKGKqbK95HgovcbEskzygm62U7oBkJscH9ldKgfV8FS8nCDUuZPQVtfp8TtNYte/pG5JkqHTTZicTPLMbmmolIyTFFUm5+Llqyh392v2VOelvG6fXl5tPzBm2HWzf9tPS0eNNE8hZPPZg0bAyr3CDbOdL9uvZcrXFNyVXjkSlbgkVth+uZk3rndxZLePRiapUOQtilpwDgsmWnk9dcSPbx/A9u/ajV7S+VqExQ52plz0q6LYfAQNCJQpg7/+R7JygTdwkvjCzWDioVeqD08/LbfEMINyNv3ts33o0WrX/J4/X1xoHyRMzmrW0ppyrt0rT7On7rcwV+xls3ECjHsuxuLgg/xMG/HUVLn+bDHX/yb+7wH/EGAARjZ2jNWjuZgAAAAASUVORK5CYII=\a\b\33[1A\e]1337;File=inline=1:iVBORw0KGgoAAAANSUhEUgAAABwAAAAcCAYAAAByDd+UAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAARRJREFUeNpi/P//PwM9AeOohUPfwt83oiOANCcQ/6GxXSxA/B1k4SMgQxCI/9LYQmYgfg+yVZaOIcoDslAV6t1/NLaMCRRtIIvu0DPRgCz8Bk001ATvgFgA6itk8B1kYSgQs1Mp0fwEYikgngvEV4C4AYh/QD0GSjQ/QamUFiH3CYgXAXEOtnwIchUblA8qBR4AsRAQ89PAIb9AXt0NxLxA/BuIVYBYERq8B6E0EykFCTQI30CDUQyq/z+U/gwS9EHTBLI4BIg30iqVTgJibmhqheXJCUDsCXUxExXz4VdQHP7HkqSFaJkPGemd8ZWgND0Kb3DRdpfePrwMzXP0KLw/giwsgmZ8elj4a7QRNWohyQAgwAAQhlmNWgQOSgAAAABJRU5ErkJggg==\a\b\33[1A\e]1337;File=inline=1:iVBORw0KGgoAAAANSUhEUgAAABwAAAAcCAYAAAByDd+UAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAABTZJREFUeNrsVkuIXEUUPVX1fv2ZmZ6ZTMcxISZBowYJQYkGhYCKShARQRA/uJEgiuLClagbFy514QeXERRUVLIQV2oSiAt1wEQDTiAfY8xnJpnJTH/fr6o89bqTmU5A4iag2DO3q9+rV3XuPffcW09Ya3E1PxJX+fPfB/TyQ09BRBK2aRB/MQOz0HkAvt5uWoszcjiaYYp/M7+k4zhrn7WJd1Jdq18deW9uDhXmvikA8Q8B3ZftGshxH8GDo+h89OcTyms8Hd4wApvEsBowt/OZBYv8cA7Us0d1Yg+oVXoFlEyxIHdyiw8J3LoSQJFNP3mA4xiMjdXaWtr9cnoSh46O+htGkXF/qQQU3TIM1cYaupHDzGnIehfhlgTeLXyoIRdob0Dh7SuJcFMvmwK2lQGphmVqhZXIUhBMcR93Te8izpBKUzLIf6+g81kXaqqN0v3dmlyl38IZ9TMX7/k7mp1o1tI20OaLO64uhQBJRrnkI4p8WBei53zzgdwnqI9wM+c2VWH+GEfrg1Ek+zg/me9GgNu4mDunARQ9ltmAuV2O056njS5jmqFRSIwyp0mPJuQFIqA1Wci5q9KItgjkp4YR7/KhTy6i/FhnCh07PX+udm8ixCkl9GWU6svKw+1KACEUklwg4ihJrWbwXQIFdEAoQ0EpCiuHqmuUamUkU0zLeXtu/yMTN/1gJp6rtBuvC6l6AcBepPQ+2vsD0fVHS2qHyn6RRyP5qFJ98+gAqfU9WFItrVf8Du+MgKNDNv0knDXDY6/50fqHfLkSvqyjN64sAL+j7e2B2CVQ9y+KL7olC3DfV6gyfy7axAqkpNuPAjKo0IgFpPaRbytP3DF7rL7x2wrO1e/5WCJ4Rogyt6kW5gDbtE8vVZNP2posgxNzCfEENaPQTg3vGXiBQmYISBN0xjkShBQX6dM6ADaP4a6pn1D/9ezJ5orqDmESlgtFQ3OA39BmLwXUxiLkRjVGZPtBOwFbRmaol6GSh2HSnfF3KfKoaA+GeZeMOo5G4a9rYNvunWtES6/JoyBeXhYP0x6/FDCnQiqhJCDzR3BNsVQjRSBVZNnRremBopobXY0kY40yWo9OepRhsrqOa7J2+cbvj0w2RkstYexFlb5Ju3tQMJYJBs6zEfhkqFQOik6T57oQUKubF0IuB8wtN8q0A7OIuGixmcFtXiYTuH4EG4/O4tiJVdvTYX+PH+erXYSv0LYuxWb79e/6DfmylD+BJEcWAUzOVmZcg3VlQeM4XvUKMM3rQmP9KkhGSqjpLtYdnNnaHg73CWtflv2wXhrgkx4abjQUsAaVLQDiOEernUKw6N19MktHcrY/jUYzLZ5xgNWQc5wvGHSZmwxx3ek5Fc6n0J7c7wBX076mnV+qRJczgrCoXXS8YFKpMI46zdDtJDBstLZ/PxSmcKQAZa4dsFOYo1uPlTDRaWPs+CLSsr/D5fDE4PkhChoN5Ve87kjXygQC8qQoim6cFd77zJ97QHLvhU5eRBa4qB07BG3w3lBIH4gQmAxRN0anHOx1gD/Sau54EhU/EaFab6UZD0suMi523ote12E8CINeU3Cl4bqWE1NXZ6jywh1lmseK5JqhKhXsjpiAkVJQ1x1pvHtkq33RnYe9wMqsozP04vPpd0S8+IIcCVygvYgHFIzLCAkI5JTqyqffpIq0FHXr/lLvcDWq3Xrs5rGmd2GVYGfJDs6z43d28YipiFYeL6uSZaBLr5WuCThAF5WxvRkhBsTHGeGryZGvzIpyc93pNs/V/99L/+2AfwkwAIpSa6LlmvuQAAAAAElFTkSuQmCC\a
The text I pasted above is the content of file /tmp/three
2> Merge the images use ImageMagick, which you can reference here.
Please let me know if these two solutions can't solve your problem properly.
I have been playing with color schemes for terminal VIM and have found something annoyingly frustrating that I have been unable to solve thus far.
I expect the 16 system colors to change. They are obviously configurable. For that reason, I attempted to use the 256-color palette to construct a VIM color scheme that would be the same regardless of the terminal's 16 (configurable) system color palette.
I used only colors from the 256 color palette for everything, including background. However, I noticed that if I open terminals with different background and text colors specified for the terminals, the VIM color schemes appear quite different in the two terminals.
I do not see similar behavior on Ubuntu even when the terminals have different background, foreground, AND system color palettes.
I will happily accept an answer that explains why this happens.
I will be ecstatic if someone can tell me a way around this beyond setting up a specific terminal for each set of color settings I want to use.
By default, ANSI terminals are 16 color devices and the Vim color schemes that work in gvim will not work properly in a terminal.
Some terminals are capable of 88 or 256 colors. You can tell Vim about this by setting t_Co. Of course, 256 colors is still less than full RGB that you have in gvim.
There is a package for vim called CSApprox developed by Matt Wozniski. It lets you use the gvim color schemes with approximate colors.
This is what I use myself.
CSApprox includes a documentation file which explains everything better than I can here.
URL: http://www.vim.org/scripts/script.php?script_id=2390
Good luck.
P.S. about your question However, I noticed that if I open terminals with different background and text colors specified for the terminals, the VIM color schemes appear quite different in the two terminals.
That sounds like the OSX terminal does not separate the color definition from the 256 color xterm palette; i.e. that by manipulating its settings you're messing with the palette or something like that.
Terminals should probably be keeping the 16 color user-configurable stuff separate from the 256 color palette.
Terminal dynamically adjusts some color values to ensure a minimum amount of contrast with the background color. Perhaps that’s what you’re seeing.
Please attach a screenshot showing the two different color schemes. A good script for viewing the available colors is 256colors2.pl.
Please, post screenshots so that we see what you see. It's hard to talk about colors without seeing them or comparing their numerical values.
Well, I'm still on 10.6.8 so I've never enjoyed Terminal.app's ability to display 256 colors.
But, AFAIK, its default 16 colors are not taken from the X11 palette. They are probably hardcoded somewhere and their values are user-configurable anyway. Because of that, I have no idea why changing the default Red value to anything would change the looks of your Vim colorscheme.
However, Terminal.app (like most other terminal emulators) allows you to change the values of Background, Text, Bold, Selection and Cursor. Depending on how your colorschemes are written some of these settings may override parts of your colorscheme, Background, most notably.
I've had my Terminal.app background matching my Vim colorscheme's background for a long while with great results. Well, at least for a 16 color terminal emulator.
The 256 colour mode is still just an indexed palette, the same as the 8 and 16 colour modes. The application simply selects a colour by index from a palette, and it's up to the terminal to decide which colour that will actually be.
That two different terminals happen to pick the same colours for these indexes may just be the fact that within the 216-colour RGB cube there's 6 levels of each component, so the "obvious" natural way to assign those colours would be to pick each from the list (0, 0x33, 0x66, 0x99, 0xcc, 0xff). I'd imagine most terminals will do this, and therefore give the same colours at the same indices.
If two terminals differ it's simply an indication they're using some other method of selecting their actual colours.
If you are using iTerm2 then you may need to change what type of terminal it is reporting.
In your iTerm2 Preferences > Profile > Terminal > Report Terminal Type, set to xterm-256color
In Terminal.app aka Apple Terminal, the colours will change if the background colour is not explicitly set as well.
So with your colour scheme you must set up the default background colour using the Normal colour group, e.g.:
hi Normal ctermfg=188 ctermbg=234
and then you should not see any further changes to colours.
Note: I have only noticed the foreground being affected presumably so that you do not miss any important output ;)
I am writing a small CNC G-Code editor. I would like to load the code file into a rich text box (or other?) and color highlight the X,Y,Z,Rand F as it loads.
I've tried loading the file and parsing it afterwords by running through a character at a time to determine what it is and then coloring it but this is impossibly slow. some of my G-Code programs run to thousands of lines.
I know it can be done..... but in VB6??
The richText controls can have RTF data "streamed" into it, or you can append text and set the colours as you go.
If it needs to be done "live" then do it when the cursor's line changes and recolour just the previous line.