3d Printed Characters
Sanny Olafeso
I was downloading a compiler (I think it was MinGW but I'm not sure) on windows 2000 the other day (I'm generally a Mac user, but it wasn't my machine), and the downloader was a MS-DOS command line app that would display a progress bar for the download. Something like this...
except that it would continuously update on the same line. I assume the program accomplished this by deleting previously printed characters and reprinting different ones, but I can't seem to figure out how to do this.
I've tried to print a 'delete' character several different ways, like (char)8 and \b (even \r, which I heard backtracks to the beginning of the line in some languages), but none of those things worked.
The Win32 console does not support ANSI escape sequences at all. Software can manipulate the console with the ioctl-like Console API interlaced with the text output. Some software internally interprets ANSI escape sequences in text being printing and translates them to these calls [citation needed].
My question is, how do you erase characters already printed to the console? When I reach the 51st percentage, I have to erase this line from the console and insert a new line. In my current solution, this is what happens...
I am doing this in Linux using PHP(only I will use the app - so please excuse the language choice). So, the solution should work on the Linux platform - but if you have a solution that's cross platform, that would be preferable.
echo chr(8) . " "; echoes the back character, and will move the cursor back one place, and the space then overwrites the character. You can use chr(8) multiple times in a row to move back multiple characters.
For future reference, \b does not work in PHP in Linux. I was curious - so I did a couple of experiments in other languages as well(I did this in Linux - I don't know if the result will be the same in Windows/Mac)..
I'm not sure if it's the same in Linux but in Windows console apps you can print \r and the cursor will return to the first left position of the line allowing you to overwrite all the characters to the right.
Some of them can clearly be fully contained in the upper 7 or 8 lines. Why having so much space above then ?
Most of the chars of those two columns are still fully displayable on a 5x8 chars display. Some are just shortened, some are literaly cut.
It's for the 231, 234 and 249 that the problem is really important. 231 and 249 only have 8 used rows, so they can be easily pushed up to fit. So I don't understand why they are in such places. OK, I can use simple letters instead (y and g) and for the 234, I can use j. But then, why are they there ?
There is no way in .... that I am going to convert these decimal numbers into binary so I can find them on the ROM Code chart. Why did you express them in decimal when the chart in question uses binary?
The ASCII code is a seven-bit code. These codes cover all of the characters that appeared on a standard typewriter at the time the code was (excuse the pun) codified. When expressed as a 8-bit number these ASCII codes all have a zero for the most significant bit.
The designers of this controller wisely chose to populate the upper half of the ROM with characters that are not in the well defined ASCII character set instead of leaving it blank. Since the chip was designed in Japan the inclusion of Japanese characters, including the yen currency sign, was quite logical from their point of view.
You have 8 characters you can reprogram, if that is not enough then you will need to rethink what you want to display, dynamically reprogram the custom characters on the basis that all 8 will not be on the screen at one time, or select a different display.
@floresta : Yes, the "'it" was for the backslash. It should have been put in the 128+ range.
Why I have not expressed it in binary ? Just because I don't care about how it is written in the table, and because I haven't used this specific table but another one with decimal values.
And when I use this way to display chars (cast into char or byte), I use hexadecimal or decimal, not the B00110011 way. And when I use a simple loop to go through the table, I do not convert the value into binary before printing it...
Moreover, the yen is in the place of the backslash in the lower part, so it's not "ASCII standard complient". I know ASCII standard is the 7-bits part and the 8-bits is extended. But here, there is nothing between 128 and 160, there is enough space to have put the yen sign (and many other ones, or allow to use this range to define more "createChar" possibilities). And this should have been a better choice since all the other japanese chars are in this upper part.
@bodmer : You're right, history is the key. I didn't knew it. So thanx. I use the custom chars and yes, when they are not enough, I reprogram them dynamically. I just ask why having chosen to use the 2 "extra bottom lines" with adding white lines above the chars to define chars that only need less than 8 lines to be fully displayed.
Confusion occurs with some users because there are two font versions, your first post indicates you have the Japanese ROM version. There is another ROM version as shown in the datasheet on pages 17 and 18.
While recently helping someone with their i2c backpack lcd, I saw a module that was a disaster.
The ascii characters were in the font from 0x80 to 0xff
and the lower 0x80 glyphs were about half ascii glyphs and the few ascii glyphs that it did have were assigned to the ascii code points.
Even if remapping code points you couldn't get a full a-z set of characters from the lower code points.
Some were missing and they ones that were there were not even all the same case!
And even in the upper half where the "ascii" codes were, there were 3 or 4 characters missing that were replaced with odd symbols.
The funny part on that module was that because they made up their own lower 0x80 characters and replaced 0x20 with some funky arrow, the module would clear the display with these funky arrows instead of spaces.
i.e. the firmware assumed 0x20 was but that wasn't was in the font at that code point.
Do you see that their lowest part is actually lower than the base line ?
Your LCD, which is in many ways very similar to dot matrix printing, doesn't have that with the normal set.
The y is lifted up a bit, which looks a bit goofy, doesn't it ?
That's why someone came up with what (as i remember) was called true descend fonts.
Nowadays we're used to that, then that was something special to have in a printer.
Try OSS note 423806 - Import Chinese printer code page and device type if you use HPLJ printers. Better see OSS Note 423003 - Printers and Asian/Eastern European fonts/languages and for Chinese use CNSAPWIN.
Make a custom device type ZCNSAPWIN and printer to use that device type.
This works and you are not tied to a particular printer nor do you need firmware to the printer.
Hi Janz,
Is your problem solved? I was having the same problem. The print preview in sap show the chinese characters correctly, but when printed using frontend printing with device type CNSAPWIN, the printout does not appear correctly.
I have no problem printing chinese document with my printers.
Hope you could share your solution.
Thank you.
Is your printer connected directly to a server running the SAP spool
process
or do you have it connected to a print server? When working with barcode
labels, it was necessary to ensure that the font was installed on the
print
server (this was a server running MS Windows).
If you are printing directly to the printer from SAP and not via a print
server, you might try implementing and using the semi-new method type G
for
printing and printing via your workstation. This is similar to using
SAPLPD
but more reliable because it makes use of the front-end technology already
running. This would be a good test if you can print the same text from
MSWord.
Is your printer connected directly to a server running the SAP spool process
or do you have it connected to a print server? When working with barcode
labels, it was necessary to ensure that the font was installed on the print
server (this was a server running MS Windows).
If you are printing directly to the printer from SAP and not via a print
server, you might try implementing and using the semi-new method type G for
printing and printing via your workstation. This is similar to using SAPLPD
but more reliable because it makes use of the front-end technology already
running. This would be a good test if you can print the same text from
MSWord.
Confidentiality Notice: The information in this document and attachments is confidential and may also be legally privileged. It is intended only for the use of the named recipient.
Internet communications are not secure and therefore British American Tobacco does not accept legal responsibility for the contents of this message.
If you are not the intended recipient, please notify us immediately and then delete this document. Do not disclose the contents of this document to any other person, nor take any copies.
Violation of this notice may be unlawful.
ZHANWIN is a new SAP development which enables you to print cascading fonts in SAP output devices while using S method. You can download this in OSS website. This will help you in printing Chinese, Japanese, Taiwanese and Korean languages in your SAP printer.
I would like to cat file, but with limit to max length to each line. For example I a have file with 10 lines each have 10000 characters and I would like to print first 100 characters from each line. Is something like that possible with cat or some alternative? thx.
Here we take advantage of parameter expansion in form $parameter:start:offset to print from starting point till offset. Should be noted that this isn't specified by POSIX and doesn't work in dash ( the default /bin/sh on Ubuntu).
This takes advantage of shell's redirection for file's contents into python's stdin stream, then reads all lines into list from the stdin,. The map() function allows us to process that list via lambda x: x[:100], obtaining a new list, where each item is a slice of each corresponding line, 100 characters long. "\n".join() lets us combine the list of strings into one again with newline as separator.
4a15465005