Re: Feature request: configurable \times/\cdot and a bit about %h

[Mojca M. <moj...@gm...>]

On Thu, Oct 10, 2013 at 5:28 PM, sfeam wrote:
> On Thursday, October 10, 2013 02:19:12 PM Mojca Miklavec wrote:
>
>> It's not just about simplicity, but also about configurability. Let's
>> say that a user would want
>>     3×10<sup>6</sup>
>> rather than
>>     3x10<sup>6</sup>
>> even if UTF-8 isn't recognized.
>
> Huh?  How can you select a UTF-8 character if UTF-8 isn't recognized?

1. The character exists in many iso-8859-x encoding, also in
cp1250/cp1252 for example (I didn't try to do extensive checks to see
where else), but it is encoded differently (it's still D7, but it
consists of a single byte rather than two bytes like in UTF-8). So you
actually just reminded me of an additional case where the user might
want to change the sign: to use multiplication sign under a different
encoding (of course the code could also be improved to recognize
different encodings and print the proper character for them).

2. I don't have a clean overview of different terminals, but LaTeX,
ConTeXt & related terminals don't need to set the UTF-8 or any other
encoding for that matter to be usable. Imagine for a while a terminal
that outputs plain text (like LaTeX does), but doesn't set
TERM_IS_LATEX that would substitute the character for "\times". I
often created *.plt scripts in cp1250, I used cp1250-encoded strings
in "set title" and I used "\usepackage[cp1250]{inputenc}" in the main
LaTeX document which included the plot. That created perfectly usable
files with all the non-ascii characters properly encoded, without
setting an explicit encoding in gnuplot. Gnuplot was just piping the
characters through and everything worked. I believe in such a mode
(without explicitly setting some encoding) there is currently no way
to get the proper multiplication sign.

>> > A related question:
>> >
>> > At the moment the new code checks for TERM_IS_LATEX and if so
>> > replaces the default format "%h" with "$%h$".   I.e. it uses the same
>> > format but wraps it in $...$ so that LaTeX uses numerical mode.
>> > Would it be a good idea to _always_ do this?   Or maybe always do
>> > it if the format does not already contain $ signs?
>>
>> What exactly do you mean with "always"? If I use "set title 'some
>> text'" I don't want it to be enclosed in dollar signs for example.
>
> Only for "set format"
>
>> Which cases exactly fall under "alway wrap it in $...$"?
>>
>> In my old scripts I was often using something like (please excuse me
>> if I used the wrong format specifiers here):
>>     set format y "\\m{%t}{%T}"
>> where the master document defined
>>     \def\m#1#2{$#1\cdot10^{#2}$}
>
> That example is way over my head.
> I don't recognize the syntax at all.

I basically achieved the same output as the new code. It is just that
I asked gnuplot to print
    \m{3}{5}
or maybe
    3\E{5}
into the label and LaTeX ended up typesetting
    $3\cdot10^{5}$

Gnuplot saw 6 or 8 characters instead of 14 which made the labels
considerably smaller. (Before LaTeX had its own way of counting
characters which is still not perfect.)

>> I guess this would fail then?
>
> Yes it would.  So maybe it it wasn't a good idea.
> I can revert it to only wrap the default format, not user-defined formats.

The main question is whether it can be reverted easily be the user
(whether user can turn it of it becomes annoying). Another flaw of
always putting the dollar signs around the labels (other than users
putting TeX commands there which add dollar signs themselves - like my
example above) is the use of comma as a decimal separator which
introduces extra space when in text mode (unless instructed
differently). So "$3,5$" basically becomes "3, 5" when typeset.

Now again, gnuplot could try to be "smart enough" to replace "$3,5$"
by "$3{,}5$", the only question is when this all ends and when it
starts interfering with users who know exactly what they are doing. I
need to check what happens with a combination of %h and decimal comma
right now.

Mojca