Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2015-07-03 05:03:30
|
Ethan,
Could you give a brief summary of the support of utf-8 symbols in the
terminals? {/Symbol xyz} wasn't working for me in Qt (probably missing
the symbol font, as others reported the symbols appeared in Qt plots).
So I tried utf-8 as described in the documentation and that works nicely
for Qt terminal. It seems to me that WXT and Qt work well with utf-8
symbols, while the rest of the terminals (x11, png, postscript) have a
better chance of working correctly with {/Symbol xyz} format. Does that
sound about right?
Thanks,
Dan
|
|
From: sfeam <sf...@us...> - 2015-07-03 05:44:10
|
On Friday, 03 July 2015 12:03:18 AM Daniel J Sebald wrote:
> Ethan,
>
> Could you give a brief summary of the support of utf-8 symbols in the
> terminals? {/Symbol xyz} wasn't working for me in Qt (probably missing
> the symbol font, as others reported the symbols appeared in Qt plots).
> So I tried utf-8 as described in the documentation and that works nicely
> for Qt terminal. It seems to me that WXT and Qt work well with utf-8
> symbols, while the rest of the terminals (x11, png, postscript) have a
> better chance of working correctly with {/Symbol xyz} format. Does that
> sound about right?
The Adobe Symbol font was designed for PostScript.
Using it for anything else is probably not optimal.
PostScript (the language) predates UTF-8 and basically cannot sanely
handle any character set larger that 255. Use PDF instead.
X11 handles UTF-8 just fine, but it is a little bit complicated to
select the fonts properly. This is described in the docs.
For an example, see the comments at the top of utf8.dem
Both libgd and cairo use utf-8 with no problem so you shouldn't have
any trouble with png.
SVG is natively UTF-8. If anything the difficultly would be
creating an svg file using some other encoding.
The latex terminals will pass through text without interpretation,
so on the gnuplot end the encoding shouldn't matter. But it is
still rare to have a LaTeX configuration that handles the full
range of UTF-8 characters.
Did I miss a terminal you were interested in?
Ethan
|
|
From: Daniel J S. <dan...@ie...> - 2015-07-03 08:46:39
|
On 07/03/2015 12:42 AM, sfeam wrote:
> On Friday, 03 July 2015 12:03:18 AM Daniel J Sebald wrote:
>> Ethan,
>>
>> Could you give a brief summary of the support of utf-8 symbols in the
>> terminals? {/Symbol xyz} wasn't working for me in Qt (probably missing
>> the symbol font, as others reported the symbols appeared in Qt plots).
>> So I tried utf-8 as described in the documentation and that works nicely
>> for Qt terminal. It seems to me that WXT and Qt work well with utf-8
>> symbols, while the rest of the terminals (x11, png, postscript) have a
>> better chance of working correctly with {/Symbol xyz} format. Does that
>> sound about right?
>
> The Adobe Symbol font was designed for PostScript.
> Using it for anything else is probably not optimal.
>
> PostScript (the language) predates UTF-8 and basically cannot sanely
> handle any character set larger that 255. Use PDF instead.
Ah, that explains PostScript.
> X11 handles UTF-8 just fine, but it is a little bit complicated to
> select the fonts properly. This is described in the docs.
> For an example, see the comments at the top of utf8.dem
OK. I've had problems with x11 terminal window crashing (i.e.,
disappearing) with the utf8.dem and enhanced_utf8.dem demos but I can't
reproduce this consistently.
> Both libgd and cairo use utf-8 with no problem so you shouldn't have
> any trouble with png.
This one I'm having trouble with, primarily. I'm surprised it's not
working.
> SVG is natively UTF-8. If anything the difficultly would be
> creating an svg file using some other encoding.
No problems here.
> The latex terminals will pass through text without interpretation,
> so on the gnuplot end the encoding shouldn't matter. But it is
> still rare to have a LaTeX configuration that handles the full
> range of UTF-8 characters.
>
> 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.
Note, I think there is an invalid ASCII character in the utf8.dem demo.
When I tried compiling the latex output, the program complained about
an unfound character. 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.
Thanks,
Dan
|
|
From: sfeam <sf...@us...> - 2015-07-03 17:36:09
|
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.
> 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.
Ethan
|
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2015-07-03 21:01:29
|
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.
>
>> 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.
Here are test results for utf8 and latex terminal.
When compiling the gnuplot-generated LaTeX file, any characters that act
as control-chars/tags in LaTeX cause a problem. E.g.,
! You can't use `macro parameter character #' in restricted horizontal mode.
<argument> !"##
\$\%\&'()*+,-./0123456789:;<=>?@
l.10 ...)[l]{!"#\$\%\&'()*+,-./0123456789:;<=>?@}}
I made the following substitutions to achieve the intended text:
# => \#
$ => \$
% => \%
& => \&
< => \textless
> => \textgreater
\ => \textbackslash
^ => \^
_ => \_
One question is should such translations be added to the latex terminal
when requesting a text string? We could make it an option to the latex
terminal, e.g., "textsubstitute". An alternative is to use one of the
LaTeX verbatim constructs but that risks the user typing in the exit
character from verbatim, causing more confusion.
After those changes, the \177 character produces the following error:
! Text line contains an invalid character.
l.12 ...(0,0)[l]{abcdefghijklmnopqrstuvwxyz{|}~^^?
}}
After removing that \177 character, LaTeX compiles the file correctly,
basically ignoring all the rest of the UTF-8 characters. All those
lines appear blank.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2015-07-03 21:21:19
|
On 07/03/2015 04:01 PM, Daniel J Sebald wrote: > I made the following substitutions to achieve the intended text: > > # => \# > $ => \$ > % => \% > & => \& > < => \textless >> => \textgreater > \ => \textbackslash > ^ => \^ > _ => \_ > > One question is should such translations be added to the latex terminal > when requesting a text string? We could make it an option to the latex > terminal, e.g., "textsubstitute". An alternative is to use one of the > LaTeX verbatim constructs but that risks the user typing in the exit > character from verbatim, causing more confusion. The problem with the above idea is that one can no longer enter LaTeX command words. Actually, when one thinks about it, this concept is essentially the same as saying "noenhanced", isn't it? I mean, LaTeX is inherently "enhanced", so an option "noenhanced" making the above substitutions would be pretty consistent with other terminals. Dan |
