|
From: Daniel J S. <dan...@ie...> - 2015-07-03 18:02:57
|
On 07/03/2015 12:32 PM, sfeam wrote: > On Friday, 03 July 2015 03:46:28 AM Daniel J Sebald wrote: >> On 07/03/2015 12:42 AM, sfeam wrote: > >>> Did I miss a terminal you were interested in? >> >> JPEG works... >> >> I think I will just treat all working under utf8, except PostScript and >> try to resolve the libgd issue separately. > > If JPEG works then PNG must work also. > It is the same driver. > >> Note, I think there is an invalid ASCII character in the utf8.dem demo. > > Umm. It is a demo of UTF-8, not ASCII. ASCII is the first code book of utf8, if I understand correctly. The eighth bit in the first utf8 byte is an indication of longer than one byte code. Most references group U+007F in with control codes: https://en.wikipedia.org/wiki/UTF-8 http://www.utf8-chartable.de/ >> When I tried compiling the latex output, the program complained about >> an unfound character. > > I already noted that most latex installations do not handle the full > range of characters. Even if it handled \0177 is would almost certainly > fail on the subsequent test lines. > >> I looked at the output in gvim and saw >> >> ...z{|}~}} >> >> the third last character which appears as ^? in gvim but may be another >> glyph in your mail viewer. That line in the demo is labeled 0061 - >> 007E, but 7E is 126 and octal \177 is 127. ASCII 127 is the [DEL], >> which I'm guessing is not assigned a glyph. I suggest removing \177 >> from utf8.dem. > > IMHO one goal of the demos is to provide a set of unit tests. > The idea is to exercise everything and find out what may not be working > on the system where the test is run. It's kind of pointless to remove > a test just because it succeeds in indicating a point of failure. We've found that LaTeX and gvim don't like control characters in UTF-8 format. If gnuplot isn't processing control codes in some way, what is being tested? If the U+007F is intentional, why not label the line 0061 - 007F rather than 7E? Dan |